画質を落とさずに軽い画像を配信する方法

画像は通常、ページの中で最も重いものです。だからこそ、パフォーマンス改善において最大かつ最も手軽な効果を得られる部分でもあります。目標は「とにかく小さく」ではなく、表示される画面上でまだきちんと見える最小のファイルを作ることです。ここでは、書き出すたびに目視確認しなくても済むワークフローを紹介します。

圧縮する前にリサイズする

最大の節約は通常、コーデックではなく<b>寸法</b>にあります。800pxのスロットに4000pxのヒーロー画像を表示すると、圧縮が始まる前からピクセルの約96%が無駄になります。実際の表示サイズを決め、高DPR画面を考慮したうえで（ほとんどの写真では2倍で十分です）、まずそのサイズにダウンスケールしましょう。適切なサイズの画像を圧縮すれば、その後の各ステップの負担も減ります。

用途に合ったフォーマットを選ぶ

写真の場合：AVIFまたはWebP、必要ならJPEGフォールバックを添えて。フラットなUI、ロゴ、スクリーンショットの場合：ロスレスPNGまたはWebP。写真をPNGで、スクリーンショットをJPEGで配信してはいけません — どちらも不適切な選択であり、バイト数<i>と</i>画質の両方を犠牲にします。迷ったら両方でエンコードして、勝った方を採用しましょう。

知覚的な画質目標を設定する

「クオリティ80」が意味するものはエンコーダーによって異なるため、魔法の数字ではなく<b>知覚的</b>な結果を目標にしましょう。SSIMULACRA2スコアが80〜90前後であれば、ほとんどの写真で視覚的にロスレスと言えます。約70を下回るとグラデーションや肌の質感に劣化が見え始めます。下限を決めてエンコーダーにそれを達成させれば、ファイルごとに勘で判断する代わりに、ライブラリ全体で一貫した画質が得られます。

# 表示サイズにリサイズしてから、品質下限を指定して変換
imageforge hero.png --resize 1600 --convert avif --quality 82
imageforge ./gallery/*.jpg --convert webp --quality 80 --recursive

自動化する

ワークフローが定着するのは、実行するのが退屈なものである場合だけです。フォルダ全体をバッチ処理し、オリジナルには手を加えず、ツールに節約量を報告させることで結果を信頼できるようにしましょう。ポイントは「軽量化」をデフォルトの道筋にすることです — リリース前に誰かが忘れる手作業にしないことです。

配信すべきは「まだきちんと見える最小のファイル」であって、単なる「最小のファイル」ではありません。その違いこそが仕事のすべてです。

推測せず、計測する

ファイルサイズだけでなく、実際の節約量と実際の画質の両方を確認してループを閉じましょう。90%小さくなっても劣化して見えるファイルは勝利ではありません。60%小さくても見た目がまったく変わらないファイルこそが勝利です。両方を追跡すれば、安全策に頼らず自信を持って設定を攻められます。