SVG を AVIF に変換

AVIF は写真やスクリーンショット、商品写真には非常に効率のよい形式です。しかしその理屈は図形の描画には当てはまりません。SVG はすでに形を数式として記述しているため、可能な限り小さく、レイアウトに合わせて自由な大きさで表示でき、追加のファイルも必要ありません。

容量を理由にこの変換をしようとしているなら、多くの場合、目的と逆の結果になります。SVG のロゴファイルの多くはもともと数キロバイト程度で、それを1024ピクセル幅でラスタライズした AVIF は、それより大きくなることがよくあります。

実際にはベクターと呼べない SVG——写真をトレースしたものや、内部に Base64 の画像を埋め込んだもの——は、ラスタライズしたほうが小さくなります。ぼかしやブレンドモード、複雑なクリッピングなどのフィルターを多用した図形も、ブラウザーごとの描画差を避けるために一度ラスタライズしておく価値があります。

CDN や画像プロキシ、CMS が SVG を扱えず拒否する場合や、ユーザーが投稿した SVG をそのまま受け付けるとスクリプトや外部参照を埋め込まれる恐れがある場合も、ラスタライズが正しい選択になります。「もう全部 AVIF にする」という理由だけでは、この変換は正当化されません。

1つの SVG は、スマートフォンの高密度画面でも外部モニターでも印刷でも、同じバイト列のまま鮮明に表示されます。AVIF に変換した瞬間、その中のどれか1つの密度にしか正しく対応しなくなります。

すべての密度に対応させようとすると、複数の幅でレンダリングして srcset を書くことになり、1つのファイルで済んでいたものが複数のファイルとそれなりのマークアップに変わります。この複雑さの増加は、容量の比較よりも実質的なコストです。

既定は幅1024ピクセルで、高さは元の図形の縦横比に従います。範囲は0.1倍から10倍まで指定できます。

実際に画面に表示される最大のCSS幅を確認し、その2倍の幅で書き出すのが実務的な目安です。180ピクセルで表示するロゴであれば、1024ピクセルではなく360ピクセルで十分です。それでも、同じ密度をすべてカバーしていたSVGのほうが元々小さかったという事実は変わりません。

AVIF は動画コーデックの1フレーム分の技術をもとにしており、周囲のブロックから予測して、目に見えにくい残差を捨てる仕組みです。写真ではこの残差は質感ですが、図形では文字や図形の輪郭そのものです。

既定の画質設定では、硬いはずの輪郭がわずかに柔らかくなり、単色の塗りの中に薄い斑が出ることがあります。フラットな図版であれば画質を95程度まで上げると、この影響はほとんど気にならなくなります。

AVIF はアルファチャンネルを持ち、SVG の透明な部分はそのまま透明として書き出されます。切り抜かれたロゴは、どんな背景色の上に置いても正しく表示されます。

この透明度は色の情報とは別の符号化されたプレーンとして保存されます。写真であればその分は誤差の範囲に埋もれますが、数キロバイトしかない単純な図形では、この分がファイルサイズの目立つ割合を占めます。

現行の主要ブラウザーはどれも AVIF を表示できますが、それは比較的最近のことです。SVG はそれよりずっと前から、ブラウザーだけでなくデザインツールや業務システム、メールクライアントを含む広い範囲で読み込めます。

ベクターを AVIF に置き換えることは、表示できる範囲を狭めることを意味します。フォールバックを用意する対応は、SVG だけなら1つのファイルで済んでいた場面で、2つのファイルを送ることになります。

resvg による描画と、AV1 の符号化はどちらもこのブラウザーのタブの中で WebAssembly として動作します。未公開の素材がどこかへ送られることはありません。

まとめて処理する場合、フォルダー全体を一度に置くと同じ倍率・同じ画質で書き出され、ZIP として受け取れます。ただし元の SVG の viewBox が揃っていない限り、書き出された画像の縦横比も揃いません。SVG は正本として残しておき、AVIF はいつでも作り直せる書き出しとして扱ってください。