Core Web Vitalsのための画像最適化方法
サイトの表示が遅い。Lighthouseテストを実行してみる。レポートは画像が原因だと言っている。
あの赤い「Largest Contentful Paint」スコア?ほぼ間違いなく最適化されていない画像が原因だ。そしてGoogleはそのスコアを使ってサイトをランク付けしている。
Core Web VitalsはGoogleが最も重視する指標だ。画像は最も重要な指標に影響する。画像を最適化すればスコアは上がる。その方法を具体的に解説する。
Core Web Vitalsとは何か?なぜ画像が重要なのか?
Core Web VitalsはGoogleがすべてのページで測定する3つのパフォーマンス指標だ:
- Largest Contentful Paint (LCP): 最大の可視要素がどれだけ速く読み込まれるか。2.5秒以下が目標。
- Interaction to Next Paint (INP): クリックやタップした時のページの応答速度。200ミリ秒以下が目標。
- Cumulative Layout Shift (CLS): 読み込み中にページレイアウトがどれだけずれるか。0.1以下が目標。
画像はこの3つの指標のうち2つに直接影響する。重いヒーロー画像はLCPスコアを台無しにする。サイズ指定のない画像はレイアウトのずれを引き起こし、CLSを悪化させる。
これがビジネスにとって重要な理由。GoogleはCore Web Vitalsがランキング要因であると確認している。良いスコアのページはより多くのオーガニックトラフィックを獲得する。悪いスコアのページは検索結果で順位が下がる。
データもこれを裏付けている。LCPを2秒以上改善したサイトは、測定可能なランキング向上を実現した。競争の激しいキーワードでは、この速度差が1ページ目と3ページ目の違いになりうる。
そして画像は通常、ページ上で最も重い要素だ。平均的なウェブページは1MB以上の画像を読み込む。これはスクリプト、フォント、HTMLの合計よりも多い。画像を最適化すれば、パフォーマンス問題の大部分が解決する。
画像最適化でLargest Contentful Paintを改善する方法
LCPは最大の可視要素のレンダリング完了時間を測定する。ほとんどのページでは、ヒーロー画像、商品写真、またはバナーがそれにあたる。
その画像の読み込みに4秒かかるなら、LCPは4秒だ。Googleは2.5秒以下を求めている。そのギャップを埋める方法がこれだ。
画像を圧縮する。 2MBのヒーロー画像は大きすぎる。150-200KBに圧縮すれば読み込み時間は劇的に短縮される。写真には75-85%の品質設定を使おう。見た目の差はほぼわからないが、ファイルサイズは80-90%削減される。
モダンフォーマットを使う。 WebPファイルはJPEGより25-35%小さい(同じ品質で)。AVIFならさらに節約できる。すべてのモダンブラウザがWebPに対応している。フォーマット切り替えは最も簡単なLCP改善の一つだ。
表示サイズにリサイズする。 ページが800pxで表示するのに4000pxの画像を配信するのはやめよう。まずリサイズしてから圧縮する。これだけでファイルサイズを70-80%削減できる。
LCP画像をプリロードする。 HTMLにプリロードヒントを追加して、ブラウザがヒーロー画像をすぐに取得するようにしよう。これがないと、ブラウザはCSSを解析するまで画像を発見できない。その遅延は数百ミリ秒追加される。
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
LCP画像にfetchpriority="high"を設定する。 これはブラウザにこの画像を他のリソースより優先するよう指示する。小さな変更だが、LCPの実際の時間短縮になる。
LCP画像にlazy loadを使わない。 これはよくある間違いだ。lazy loadingは画像がビューポートに入るまで読み込みを遅延させる。ヒーロー画像はページ読み込み時にすでに表示されている。lazy loadを設定すると不要な遅延が追加され、LCPスコアが悪化する。
lazy loadingはCore Web Vitalsに効果があるのか?
lazy loadingはファーストビュー以下の画像には最適だ。ファーストビュー内の画像には最悪だ。
画像にloading="lazy"を追加すると、ブラウザはユーザーがスクロールして近づくまでダウンロードを待つ。これはユーザーが見ないかもしれない画像の帯域を節約する。初期ページの重さを減らし、最初の読み込みを速くする。
しかし、ヒーロー画像や最初の画面に表示される画像にlazy loadを設定すると、ページで最も重要な視覚要素の読み込みを遅らせることになる。これは直接LCPを増加させる。
ルールはシンプルだ。ファーストビュー以下のすべての画像にlazy load。ファーストビュー内の画像には絶対にlazy loadを使わない。ヒーロー画像、ヘッダーロゴ、スクロールなしで見えるコンテンツはすぐに読み込むべきだ。
ほとんどのページでは、1-3枚の画像がすぐに読み込まれる。残りはすべてlazy loading。このバランスが最高のLCPスコアを実現しながら帯域も節約する。
lazy load画像によるレイアウトシフトにも注意しよう。lazy画像が読み込まれてコンテンツを押し下げると、それはCLSの問題だ。画像には必ず明示的なwidthとheight属性を設定しよう。ブラウザは画像が読み込まれる前にスペースを確保し、レイアウトのジャンプを防ぐ。
どの画像フォーマットがCore Web Vitalsに最適か?
選ぶフォーマットはファイルサイズに直接影響する。小さいファイルは速く読み込まれる。速い読み込みはLCPの向上を意味する。
WebPは現在のウェブ画像に最適なデフォルト選択肢だ。JPEGより25-35%効率よく圧縮でき、目に見える品質低下がない。ブラウザサポートは97%以上。非常に古いブラウザをサポートする必要がなければ、WebPを標準フォーマットにすべきだ。
AVIFはWebPよりさらに高い圧縮率を実現する。JPEGの最大50%小さい。ただしエンコードが遅く、ブラウザサポートはまだ追いついている途中だ。ビルドパイプラインが対応しており、フォールバックを提供できるなら使おう。
JPEGは写真にはまだ問題なく使える。適切に圧縮すれば(品質75-85)、堅実な選択肢だ。ただしWebPはほぼ常に同じ視覚品質でより小さいファイルを提供する。
PNGはロゴ、アイコン、透明度が必要な画像に適している。ただしPNGファイルは大きい。透明度が不要なら、WebPかJPEGに変換しよう。
<picture>要素を使えば、各ブラウザに最適なフォーマットを配信できる:
<picture>
<source srcset="/hero.avif" type="image/avif">
<source srcset="/hero.webp" type="image/webp">
<img src="/hero.jpg" alt="ヒーロー画像" width="1200" height="600">
</picture>
これはAVIF対応ブラウザにはAVIFを、次のグループにはWebPを、フォールバックとしてJPEGを配信する。すべての訪問者がブラウザで処理できる最小のファイルを受け取る。
画像によるレイアウトシフトを防ぐ方法
レイアウトシフトは画像が読み込まれて他のコンテンツを押しやるときに発生する。読んでいたテキストが突然下にジャンプする。クリックしようとしたボタンが移動する。ユーザーにとってフラストレーションで、CLSスコアにも悪影響だ。
解決策はシンプルだ。画像が読み込まれる前に、常にブラウザに画像のサイズを伝えよう。
すべての画像にwidthとheightを設定する。 ブラウザはこれらの値を使ってアスペクト比を計算し、適切なスペースを確保する。画像がまだ読み込まれていなくても、レイアウトは安定したままだ。
<img src="/photo.webp" alt="商品写真" width="800" height="600">
レスポンシブ画像にはCSSのaspect-ratioを使う。 画像がビューポートに合わせてスケールする場合、CSSでアスペクト比を設定しよう。ブラウザはどの画面サイズでも正しい比率のスペースを確保する。
img {
aspect-ratio: 4 / 3;
width: 100%;
height: auto;
}
既存コンテンツの上に画像を動的に挿入しない。 JavaScriptがページ上部に広告バナーやカルーセルを読み込むと、その下のすべてがずれる。動的コンテンツ用にスペースを確保するか、ファーストビュー以下で読み込もう。
フォント依存のレイアウトにも注意。 レイアウトシフトが画像以外から発生することもある。遅れて読み込まれるウェブフォントがテキストを再配置し、画像を移動させることがある。font-display: swapを使い、主要フォントをプリロードしよう。
Core Web Vitalsのための画像最適化チェックリスト
ページごとに使えるステップバイステップのチェックリスト:
アップロード前:
- 画像を表示サイズにリサイズする(Retinaスクリーンは2倍)。
- 画像を圧縮する。写真は75-85%を使う。
- 可能ならWebPまたはAVIFに変換する。
- メタデータを削除する(EXIFデータ、GPS座標、カメラ情報)。
HTMLで:
- すべての
<img>タグにwidthとheightを設定する。 - ファーストビュー以下のすべての画像に
loading="lazy"を追加する。 - LCP画像に
fetchpriority="high"を追加する。 <link rel="preload">でLCP画像をプリロードする。<picture>要素でモダンフォーマットとフォールバックを配信する。
デプロイ後:
- LighthouseまたはPageSpeed Insightsを実行する。LCPとCLSのスコアを確認する。
- 「改善の余地」セクションを確認する。小さくできる画像が表示される。
- モバイルでテストする。モバイル接続は遅いので、画像最適化の重要性はさらに高まる。
このチェックリストを一貫して実行すれば、Core Web Vitalsはグリーンを維持できる。ほとんどのサイトが画像最適化だけでLCPを1-3秒短縮している。
画像パフォーマンスのテストとモニタリング方法
一度最適化するだけでは足りない。新しい画像が追加される。コンテンツが変わる。継続的にパフォーマンスを監視する必要がある。
Google PageSpeed Insightsで素早く確認できる。任意のURLを貼り付けて、モバイルとデスクトップのLCP、INP、CLSスコアを取得しよう。利用可能な場合はChromeユーザーの実測データも表示される。
Lighthouse(Chrome DevToolsに内蔵)で完全な監査を実行する。大きすぎる画像、lazy loadの欠如、サイズ指定のない画像、古いフォーマットの画像を検出する。拡張機能の干渉を避けるため、シークレットウィンドウで実行しよう。
Google Search Consoleはサイト全体のCore Web Vitalsデータを表示する。URLをステータス別(良好、改善が必要、不良)にグループ化する。月次でチェックして退行を早期に発見しよう。
WebPageTestはページ読み込みのフィルムストリップビューを提供する。各画像がいつ表示され、レンダリングタイムラインにどう影響するか正確に確認できる。
人気の圧縮ツール比較は、ワークフローに合った適切なツール選びに役立つ。一度に1枚ずつ圧縮するにしろ、数百枚をバッチ処理するにしろ、適切なツールが最適化の維持を容易にする。
Core Web Vitalsを改善する準備はできた?
画像はほとんどのウェブページで最も重い要素だ。画像の最適化はCore Web Vitalsに対して最もインパクトの大きい変更だ。
画像を圧縮する。モダンフォーマットを使う。適切なサイズを指定する。重要なものをプリロードする。重要でないものをlazy loadする。
CompressIMGが圧縮ステップを担当する。画像をアップロードし、品質を選んで、数秒で最適化されたファイルをダウンロードしよう。アカウント不要。ヒーロー画像から始めて、そこから進めよう。
LCPスコアが改善されるはずだ。