画像が原因の遅い LCP を改善する方法

遅い LCP (Largest Contentful Paint) 画像を改善する4つのステップ：表示サイズに合わせてリサイズする、WebPまたはAVIFに変換する、プリロードする、そしてfetchpriorityをhighに設定する。 最初の2つのステップで改善の大部分を達成でき、ページのマークアップを変更する必要もありません。

ほとんどのページにおいて、最大視覚コンテンツの描画（LCP）要素は1つのヒーロー画像です。つまり、LCPはサイト全体の問題というよりも、実際には1つのファイルに関する問題です。その1つのファイルを修正することは、通常、利用可能な他のどの最適化よりも測定数値を大きく改善します。

LCPが測定するもの

LCPは、ページの読み込み開始から、最も大きい表示要素がレンダリングされるまでの時間を記録します。 Googleは、2.5秒以下を「良好」、2.5秒から4秒を「改善が必要」、4秒超を「不良」として扱います。

測定対象となる要素は通常は画像であり、時には見出しテキストのブロックであることもありますが、常にスクロールせずに表示される（ファーストビューの）要素です。デスクトップのレイアウトで主役となるヒーロー画像が、スマートフォンではスクロールしなければ見えない位置にある場合など、デバイスによって測定対象の要素が変わることがあります。

原因となっている要素の特定

Lighthouseを実行し、「Largest Contentful Paint の要素」の項目を確認して、測定されている正確な要素を特定します。 推測で進めると時間を無駄にします。なぜなら、測定されている要素が、人々が想定しているものとは異なることが頻繁にあるからです。

レイアウトが異なれば結果も異なるため、デスクトップだけでなくモバイルでも確認してください。実際の訪問者からのフィールドデータは、単一のラボテストよりも信頼性が高くなります。なぜなら、実際のネットワーク環境はテスト環境よりもはるかに多様だからです。2つのデータが矛盾する場合は、フィールドデータを信頼し、ラボテストは診断用として使用してください。

影響度の高い順に画像を修正する

画像のLCPを改善するには、以下の6つのステップに順番に取り組んでください。

1. 画像を表示される最大サイズにリサイズする（高画素密度ディスプレイ用に2倍のサイズにする）。
2. WebPに変換する。画像が大きく写真である場合はAVIFに変換する。
3. ヒーロー画像の場合、200 KB未満を目標に圧縮する。これはほとんどのデザインにおいてフル幅でも達成可能です。
4. widthとheight属性を追加して、ブラウザが領域を確保し、レイアウトシフト（CLS）が発生しないようにする。
5. ページのhead内で画像をプリロードし、ブラウザがすぐにフェッチを開始できるようにする。
6. 画像要素にfetchpriority="high"を設定し、このファイルが最も重要であることをブラウザに伝える。

ステップ1と2で通常は改善の大部分を達成でき、これら2つはページのマークアップを一切変更する必要がありません。

リサイズが圧縮よりも効果的な理由

画像の寸法（サイズ）がファイル容量の大部分を決定するため、リサイズはどの品質設定よりも多くの容量を削減できます。 1200ピクセルで表示される写真を4000ピクセルのまま表示すると、ページが表示できるピクセルデータの11倍ものデータを読み込むことになります。

3行目は、なぜリサイズを最初に行うべきかを示しています。リサイズ単体でも圧縮単体より効果があり、両方を組み合わせることで最も高い効果が得られます。数値は画像や接続環境によって異なりますが、この順序の優位性は一貫しています。

プリロードと fetchpriority

プリロードは、ブラウザがページの解析を完了する前にヒーロー画像をフェッチするように指示するもので、通常200〜500ミリ秒を短縮できます。 ブラウザはページの解析プロセスの後半で画像を発見するため、この設定が重要になります。

プリロードする画像は1つだけにしてください。複数プリロードすると、ブラウザの処理が分散してしまい効果が失われます。fetchpriorityをhighに設定することでも、少ないマークアップで同様の効果が得られ、初期HTMLに既に存在する画像であれば、これだけで十分な場合がよくあります。

LCPを悪化させる間違い

• ヒーロー画像の遅延読み込み（Lazy loading）。 遅延読み込みは、最も早く読み込みたいファイルそのものを遅らせてしまいます。遅延読み込みはファーストビューより下の画像にのみ適用してください。
• JavaScript経由でヒーロー画像を読み込む。 スクリプトによって挿入された画像は、そのスクリプトが実行されるまでダウンロードを開始できません。
• CSSの背景画像を使用する。 背景画像はimg要素よりも発見が遅れ、優先順位付けも容易ではありません。
• 複数の画像をプリロードする。 優先順位が競合すると、プリロードのメリットが完全に失われます。
• widthとheightの省略。 レイアウトシフトが発生し、LCPを改善しようとする一方で、別の測定指標（CLS）を悪化させます。

LCP要素がテキストである場合

テキストベースのLCPは、通常、テキスト自体ではなくWebフォントによって遅延しています。 ブラウザはテキストデータをすぐに取得していますが、描画する前にフォントファイルの到着を待っています。

font-displayをswapに設定して、Webフォントが到着するまでは代替フォントでテキストをレンダリングするようにします。最も重要なフォントファイルを1つだけプリロードし、ページで実際に使用する文字だけにフォントをサブセット化します。これにより、フォントサイズを200 KBから30 KB未満に削減できることがよくあります。また、独自のドメインからフォントを配信することで、サードパーティへの余分な接続を排除できます。

サーバーの応答時間が限界値を決める

LCPは、サーバーが最初の1バイトを返す時間（TTFB）より速くなることはありません。そのため、遅いサーバーは他のすべての改善効果を制限してしまいます。 最初の1バイトまで600ミリ秒未満を目指してください。

画像を最適化する前にこの数値を確認してください。サーバーの応答に2秒かかっている場合、ファイルに何をしてもLCPの目標である2.5秒を達成することは不可能です。キャッシュの利用、より高速なホストへの移行、またはコンテンツデリバリーネットワーク（CDN）の導入によってこの問題に対処します。画像への取り組みは、他で設定された限界と戦うのではなく、残りの部分を改善するために行います。

サードパーティのスクリプトも画像を遅らせる

アナリティクス、同意バナー、チャットウィジェット、広告スクリプトは、帯域幅と処理時間をめぐってヒーロー画像と競合します。 完璧に最適化された画像であっても、その前に12個のスクリプトが読み込まれると、レンダリングは遅れてしまいます。

同意バナーは最も悪影響を及ぼします。なぜなら、多くのバナーは訪問者が選択するまでレンダリングをブロックするからです。サードパーティのスクリプトはdeferまたはasync属性を使用して読み込み、ページを妨げないようにし、本当に必要なスクリプトの数を監査してください。使用していない3つの追跡スクリプトを削除する方が、画像の圧縮をさらに繰り返すよりもLCPが改善することがよくあります。

変更を正しくテストする

拡張機能を無効にしたプライベートウィンドウでテストし、1回限りの結果を信頼するのではなく、測定を3回実行してください。 測定結果は実行ごとに顕著に変動します。

ブラウザが実際に小さくなったファイルを受信したか確認します。デベロッパーツールを開き、「ネットワーク」タブに切り替え、画像でフィルタリングして再読み込みします。転送サイズとフォーマットがリストに表示されます。ページがまだ古いファイルを配信している場合、最適化が失敗したのではなく、キャッシュレイヤーが以前のバージョンを保持していることを意味しているのが一般的です。

改善後にLCPの高速性を維持する

新しいページで問題が再発するため、ヒーロー画像を個別に修正するのではなく、ルールを設定してください。 一度修正したサイトでも、編集者がカメラから直接アップロードするようになれば、数ヶ月以内に元の状態に戻ってしまいます。

ヒーロー画像の最大幅と最大ファイルサイズを合意して文書化し、すべての新しいページに適用します。「幅1920ピクセル、200 KB未満」といったルールは確認が容易で、ほぼすべてのデザインをカバーできます。複数の人が公開作業を行う場合、測定数値は最も優れたページではなく最も悪いページを反映するため、技術よりも明文化されたルールの方が重要になります。

ヒーロー画像を一括で準備する

サイト上のすべてのヒーロー画像は、同じ仕様と目標サイズを共有しているため、まとめて処理します。 ほとんどのサイトでは、ランディングページ、カテゴリページ、記事全体で10〜100個のヒーロー画像が存在します。

幅と目標のKBサイズを一度設定して画像をドロップすれば、すべてのファイルがその設定に合わせて出力されます。1バッチあたり最大500枚の画像を、お使いのブラウザ内かつご自身のプロセッサ上で完全に処理できます。何もアップロードされないため、ステージングアセット、未公開のキャンペーンページ、クライアントの作業ファイルなどを手元のマシンに残したまま、ライブラリ全体を準備できます。