よくある質問
SVGO は実際に何を除去しますか？
既定のプラグインセットが除去するものは、XML コメント、エディタ固有の名前空間(`sodipodi:`・`inkscape:`・`adobe-`)、空の `<defs>` / `<g>`、未使用の ID、重複した `<filter>` / `<gradient>` 定義、冗長な属性(行き先のない `xmlns:xlink` など)、そして `viewBox` が設定されている場合の `width` / `height` です。書き換えとしては、数値を N 桁(既定 3)に丸める、`M...M` を連鎖した `M` コマンドにまとめる、絶対パスコマンドを短くなる場合に相対に変換、パスデータをミニファイなどがあります。完全な一覧は SVGO の `default-preset`(`preset-default` という名前)にあり、約 30 プラグインで個別に設定可能です。
最適化された SVG がブラウザと Figma で違って見えるのはなぜですか？
原因はいくつかあります。**Figma は追加要素を描画**します — ガイド・非表示レイヤー・キャンバス背景など、エクスポート後の SVG には存在しないものです。そのため「Figma での見え方」と「エクスポート後の見え方」は元の SVG でも違っていることがあります。**CSS からの継承** — ブラウザはインライン SVG に `currentColor`・`fill: var(...)`・外部フォントファミリーをカスケードしますが、Figma は SVG 内に焼き込まれた値を使います。最適化後、Figma 内では冗長だがブラウザでは必要だった `fill` 属性が削除されると、アイコンが黒で表示されることがあります。塗りを戻すか、色相を継承するアイコンには `currentColor` を使ってください。
インライン SVG・`<img src="...">`・スプライト — どれを使うべきですか？
**インライン**(HTML / JSX に SVG を直接貼る)は、CSS でスタイリングしたりアニメーションさせたい場合に向きます — `currentColor` で色制御、ホバーでの変形、テーマ切り替えなどです。**`<img src="icon.svg">`** は、動的スタイリングのない静的画像として扱う場合に向きます — シンプルで、ブラウザがページをまたいでファイルをキャッシュし、現代の画像読み込み最適化(遅延・デコード)が適用されます。**スプライト**(`<symbol id="x">` + `<use href="#x">`)は、Lucide や Heroicons のような大きなアイコンライブラリで 30 個の個別ファイルを読むより、1 つにまとめたほうが速い場合に向きます — ネットワークリクエストが 1 回で、定義は重複排除されます。Vite・Webpack・Next.js にはビルド時にスプライトを組み立てるプラグインがあります。
SVGO は通常どれだけファイルを縮めますか？
ソースに大きく依存します。**Figma・Sketch・Illustrator のエクスポート**: 60〜80% 削減が典型的です — これらのツールは冗長な属性とフル編集メタデータを出力します。**手書きの SVG**: 10〜30% — すでに簡潔です。**クリップアートコレクション由来の古い XML 的 SVG**: 70〜90% — 何十年分も積み上がったゴミがついていることが多いためです。5 KB のアイコンが 1 KB に縮むのは現実的、500 KB のイラストが 100 KB になるのも現実的です。サーバの gzip がさらに伝送バイトを半分にするため、最適化と HTTP 圧縮はうまく重なります。
SVGO は何かを壊すことがありますか？
はい、3 つのパターンがあります。**要素間の ID 参照**(`<use href="#foo">` や CSS の `#foo` セレクタ)は、SVGO が ID を改名・削除すると壊れます。原因は通常 `cleanupIds` プラグインで、外部参照に関わる SVG では無効化してください。**アニメーション**(`<animate>` や SMIL)で特定要素をセレクタで指定している場合、SVGO が要素を統合・再構成すると失敗します。**SVG への外部 CSS / JS フック**(`<path data-name="logo">` を探すスクリプトなど)は、`data-*` 属性が削除されると壊れます。そうしたケースでは `removeUnknownsAndDefaults` を無効化してください。最適化は既定では保守的ですが、コミット前に必ず結果をプレビューしてください。
アイコンには SVG・PNG・WebP のどれが良い？
**SVG** はシンプルな形状のアイコンに向きます — 任意のサイズで鮮明、CSS でテーマ化可能、PNG より小さいことが多いです。**PNG** は複雑なテクスチャ(スキューモーフィック、写真クロップなど)のアイコンに向きます。ベクター表現ではファイルが肥大化するためです。**WebP** はアイコンではあまり使われません — PNG はアイコンサイズで十分小さく、WebP のアルファチャンネルの癖(古い Safari など)を管理する価値がないからです。現代のアイコン中心のデザインシステム(Lucide・Heroicons・Material Symbols・Phosphor など)は SVG 専用です。ベクターのワークフローに踏み切るとファイルサイズ論争は決定的に SVG に有利になります。
関連する概念
SVG(Scalable Vector Graphics、1999 年以来の W3C 標準で、現行は 2.0 候補勧告)は XML ベースのベクター画像形式で、ピクセルグリッドではなく数学的プリミティブ(パス・円・矩形など)で形状を記述します。ラスターに対する利点は解像度独立性で、同じ SVG を 16 ピクセルでも 256 ピクセルでもレンダリングでき、どのサイズでもシャープに保たれます。代償はファイルの複雑さで、写真を SVG で表現すると(各ピクセルを小さな `<rect>` として)膨大になるため、SVG はシンプルなグラフィック用途(ロゴ・アイコン・チャート)を支配し、写真的用途には踏み込みません。
**SVGO(SVG Optimizer)** は SVG を縮小する事実上の JavaScript ツールチェーンで、2012 年に Kir Belevich が書き、現在は npm の `svgo` として保守されています。プラグインパイプラインとして動作し、各プラグインが SVG AST(`xml-parser` 流のトラバーサルでパース)を変換し再出力します。注目すべきプラグインは `removeComments`・`removeMetadata`・`cleanupIds`・`mergePaths`・`convertColors`(`#FFFFFF` を `#FFF` や `white` に)・`removeUselessStrokeAndFill` などです。既定プリセットでは約 30 個が有効で、プロジェクトごとにカスタマイズできます。SVGO はビルドツールに統合されたステップとしても動作し、`vite-plugin-svgr`・`@svgr/webpack`・アイコンコンポーネント用の `next/dynamic` などを通じて、コミットごとに自動的に最適化が走ります。
SVG ワークフローを形作る隣接概念が 3 つあります。**`viewBox` と `width`/`height`**: `viewBox` は SVG 内部の座標系を定め、`width`/`height` は表示サイズを定めます。`viewBox` のみの SVG はコンテナに合わせてスケールし、両方ある SVG は固定されます。多くのアイコンライブラリは `viewBox` を設定して `width`/`height` を省くため、CSS の所有者がアイコンのサイズを決められます。**`currentColor`**: `fill="currentColor"` を設定すると SVG が周囲のテキスト色を継承し、テーマ化可能なアイコンが実現します。**SMIL アニメーション** は SVG ネイティブ(`<animate>`・`<animateTransform>` など)ですが、2015 年に Chrome が deprecation を進めたため CSS アニメーションや Lottie へ移行する流れができ、現在の主要ブラウザでも動きますが書かれることはまれです。複雑なアニメーション付きイラストには Lottie(JSON ベースで、After Effects から Bodymovin エクスポート)が主流で、SVG は静的および CSS アニメーションのケースを担います。
