表示速度改善は「画像の圧縮」だけでは終わらない：Core Web Vitalsの現実
「画像は軽くしたのに、PageSpeed Insightsの点数が上がらない」
Webサイトの表示速度改善の相談を受ける際、よく聞く言葉だ。確かに、重い画像をWebPなどの軽量フォーマットに変換し、適切にリサイズすることは基本中の基本だ。しかし、現代のWebパフォーマンス指標である「Core Web Vitals」は、単なる「ファイルの軽さ」だけを評価しているわけではない。
Googleは、ユーザーがページを開いてから操作できるようになるまでの「体験の質」を数値化しようとしている。画像を軽くしただけで満足していては、本質的な改善には届かない。
Core Web Vitalsの3つの指標を正しく理解する
1. LCP（Largest Contentful Paint）：最大の要素が描画されるまでの時間
ユーザーがページを開いたとき、ファーストビューの中で「一番大きな要素（メインビジュアルの画像や見出しテキスト）」が表示されるまでの時間だ。これが2.5秒以内であることが求められる。
対策の勘所： 画像の圧縮だけでなく、「ブラウザにいかに早くその画像を読み込ませるか」が鍵になる。<link rel="preload">を使ってメイン画像を優先的に読み込ませたり、サーバーの応答速度（TTFB）自体を改善（CDNの導入やキャッシュの活用）したりするアプローチが必要だ。
2. INP（Interaction to Next Paint）：操作に対する反応の速さ
2024年3月からFIDに代わって導入された指標。ユーザーがボタンをクリックしたり、キーボードを入力したりした際、ブラウザが視覚的な反応（メニューが開く、色が変わるなど）を返すまでの遅延時間を測る。200ミリ秒以内が理想だ。
対策の勘所： 原因のほとんどは「重いJavaScriptの実行」にある。メインスレッドをブロックしている不要なJS（使っていないサードパーティのタグや重いアニメーションライブラリ）を削除・遅延読み込みさせることが最大の対策になる。
3. CLS（Cumulative Layout Shift）：レイアウトのズレ
ページを読んでいる途中で、遅れて読み込まれた画像や広告がガクッと割り込んできて、テキストが下に押し下げられる現象。誤クリックを誘発する最悪のユーザー体験だ。このズレの総量を0.1以下に抑える必要がある。
対策の勘所： 画像や広告枠、埋め込み要素（YouTubeなど）に対して、あらかじめHTMLやCSSでwidthとheight（またはアスペクト比）を指定し、表示領域を確保しておく。これだけでCLSの大部分は解決する。
パフォーマンス改善は「引き算」の技術
表示速度の低下は、多くの場合「足し算」の結果として起こる。マーケティングのための計測タグ、リッチに見せるためのアニメーション、便利なチャットウィジェット。これらを無自覚に足し続けた結果、サイトは重くなる。
パフォーマンス改善の本質は、画像の圧縮ではなく「不要なものを捨てる（引き算する）」決断にある。ビジネス要件とパフォーマンスのトレードオフを、チーム全体で議論できるかどうかが問われている。