LCP 改善で最初に疑うべきなのは、画像の重さだけではありません。実務で詰まりやすいのは、HTML の返却が遅い、LCP 要素が HTML から見つからない、画像は届いているのに CSS や JavaScript が描画を止めている、この 3 つです。ここを見ないまま画像圧縮から入ると、工数をかけても 0.1 秒から 0.2 秒しか縮まらないことが珍しくありません。
Largest Contentful Paint の解説では、LCP はビューポート内の最大要素が表示された時点を指し、Web Vitals の解説では 75 パーセンタイルで 2.5 秒以下が良好と整理されています。つまり見るべきなのは、「画像を軽くしたか」ではなく、「最大要素が 2.5 秒以内に出てくる設計になっているか」です。LCP が赤いページを立て直すなら、画像、CSS、サーバー、JavaScript を同時に触るのではなく、遅れている区間を分けて順に直す必要があります。
LCP改善は4つの遅延区間の順序から見直す
LCP の最適化ガイドでは、LCP を `TTFB`、`LCP 要素の発見待ち`、`リソース読込時間`、`描画待ち時間` の 4 区間で考える方法が示されています。この分解を使えば、同じ LCP 3.4 秒でも、どこから手を付けるべきかが変わります。現場ではこの 4 区間を見ないまま「画像最適化を先にやろう」と決めて失敗する例が多いため、まずは内訳を確認してください。
実務では、次の目安で判断すると優先順位がぶれにくくなります。
遅延区間 | 実務での目安 | 最初にやるべきこと | 先にやらない方がよいこと |
|---|---|---|---|
TTFB | 800ms 超 | CDN、キャッシュ、リダイレクト、SSR の待ち時間を確認する | 画像圧縮だけで片付けようとする |
発見待ち | 300ms 超 | LCP 要素を HTML に出す、CSS 背景依存を減らす | preload を乱発する |
読込時間 | 600ms 超 | 画像形式、`srcset`、`sizes`、配信地域を見直す | CSS や JS の削減だけで済ませる |
描画待ち | 300ms 超 | 初期非表示、描画準備待ち、フォント待ちを外す | 未使用 CSS の削減だけに時間を使う |
特に強く勧めたいのは、`TTFB が 800ms を超えるページは画像より先に配信構成を見直す` ことです。初手で画像だけ触ると改善幅が見えにくく、施策そのものへの信頼が落ちます。逆に、TTFB が 400ms 前後で安定しているのに LCP が悪いなら、HTML 到着後の処理に問題がある可能性が高いと見てよいでしょう。
もちろん例外はあります。ブランド訴求が強い LP でヒーロー画像のサイズが極端に大きい場合や、海外流入が多く画像配信地域に偏りがある場合は、画像配信の見直しを先に進める方が効果的です。ただしその場合でも、LCP 要素が HTML からすぐ見つかる設計かどうかは同時に確認すべきです。順番を誤ると、圧縮や形式変換の効果が埋もれてしまいます。
PageSpeed Insightsは実測から先に読む
PageSpeed Insights は便利ですが、診断一覧から読み始めると優先順位を誤りやすくなります。最初に見るべきなのは実測データ、次に LCP 要素、最後にラボデータです。この順番を守るだけで、「見た目に気になる提案」ではなく、「事業への影響が大きい詰まり」から直せます。
読み方は、次の順番が安全です。
- 実測のモバイル LCP を確認する。75 パーセンタイルで 2.5 秒以内なら、緊急改修より回帰監視を優先します。
- LCP 要素を確認する。画像、見出し、動画ポスターで打ち手は変わります。
- ラボで TTFB、レンダーブロック、長いタスクの傾向を見る。
- 診断一覧は最後に使う。診断は原因候補の整理には役立ちますが、手を付ける順番までは決めてくれません。
Chrome DevTools の Performance 機能も必ず併用してください。LCP マーカーまでのタイムラインを見れば、HTML の到着、LCP リソースの取得開始、Main スレッドの詰まりを同じ画面で追えます。PageSpeed Insights だけで「遅い」は分かっても、「どこで止まっているか」までは特定しきれません。
Core Web Vitals改善の進め方 最新評価軸に合わせて表示速度と操作体験を立て直すでも触れた通り、LCP だけを追うと CLS や INP を崩すことがあります。最初の計測段階で、LCP の数値だけでなく関連する指標まで一緒に見る方が安全です。
実測だけ悪いときに先に疑う箇所
実測だけが悪く、ラボではそこまで悪くないなら、端末差、回線差、地域差を疑うべきです。この場合、社内の高速回線で何度計測しても答えは出ません。CDN の配信地域、HTML キャッシュの有無、画像配信拠点を先に確認してください。特に国内だけで見ていると、海外流入や地方回線の遅さを見落とします。
推奨は明確です。`中位 Android 端末` と `4G 制限` で再計測し、それでも差が大きいなら配信経路を先に直すべきです。例外は、実測のサンプル数が極端に少ない新規ページです。その場合は、ラボ計測とテンプレート分析を先に進めても構いません。
ラボだけ悪いときに過剰反応しない
ラボだけ 3 秒台でも、実測が 2.5 秒以内なら本番停止の優先度は高くありません。ここで大規模改修に進むより、差分監視と再現性の確認を優先する方が合理的です。主要テンプレートを 3 種類ほど固定し、毎週同条件で計測してください。単発の悪化なのか、継続的な回帰なのかが見えてきます。
ただし例外があります。開発中の新機能でラボ計測が明確に悪化しているなら、実測に反映される前に止めるべきです。実測は 28 日窓で更新されるため、悪化が見える頃には手遅れになることがあります。
実測とラボが両方悪いときの進め方
実測もラボも悪いなら、局所的な対応ではなくテンプレート構造の見直しが必要です。HTML 配信、LCP 要素の見つかる順序、描画待ちを一緒に点検してください。商品詳細やサービス LP でこの状態なら、単発の画像差し替えで終わることは少なく、2 週間から 6 週間の改修サイクルを見込むべきです。
HTML配信の遅さは画像より先に見直すべき
LCP が悪いページで最初に確認すべきなのは、画像容量より HTML 配信です。Time to First Byte の解説でも、最初の 1 バイトが遅いと後続の全工程が後ろへずれると説明されています。実務では `TTFB 800ms 超` を一つの分岐点にすると判断しやすく、`1.2 秒超` なら画像だけで 2.5 秒以内に戻すのはかなり厳しくなります。
よくある原因は 3 つです。`不要な 301・302`、`URL パラメータでキャッシュが効かない構成`、`SSR が API 待ちで止まる構成` です。記事ページや資料ページのように個別性が低いページで、毎回配信元サーバーまで取りにいく構成は避けるべきです。配信が安定しているページなら、フルページキャッシュやエッジキャッシュを先に検討してください。
もう一つ重要なのが、LCP 要素の手掛かりが初期 HTML に含まれているかどうかです。クリティカル レンダリング パスの解説の通り、ブラウザは HTML を受け取ってから CSSOM やレンダーツリーを組み立てます。ヒーロー画像や主要見出しが JavaScript 実行後にしか現れない構成は、LCP 改善の面で不利です。React 系の実装でも、初期表示を完全にクライアント描画へ寄せるのは避けた方がよいでしょう。
症状ごとの最初の打ち手を表で整理する
症状 | まず選ぶ施策 | 推奨理由 | 例外 |
|---|---|---|---|
TTFB が 800ms を超える | キャッシュとリダイレクト整理 | LCP 全体をまとめて縮めやすい | 会員情報を含むページは上部だけ共通化する |
LCP 要素の取得開始が遅い | HTML に LCP 要素を出す | 発見待ちをまとめて削れる | 背景画像が必須なら preload を 1 件だけ使う |
画像取得は速いのに LCP が遅い | CSS・JS の描画待ちを外す | 画像圧縮より改善幅が大きい | フォント演出を重視するブランド LP は代替表示を設計する |
地域差が大きい | CDN と画像配信拠点を見直す | 実測改善につながりやすい | 国内限定流入ならテンプレート改善を優先する |
サイトの条件別に最初の推奨を決める
月間 PV 10 万未満の記事中心サイトなら、最初にやるべきは `HTML キャッシュ`、`不要リダイレクト削減`、`ヒーロー要素の HTML 明示` の 3 点です。画像 CDN の全面更改から入る必要はありません。例外は、ヒーロー画像が 1MB を超え、しかもモバイルでそのまま配信しているケースです。この場合は画像の見直しも同時に進めるべきです。
React 系で商品詳細を大量に配信しているなら、`主要見出しとヒーロー画像を初期 HTML に含める` ことを優先してください。API 完了までヒーローを待たせる設計は避けるべきです。個別価格や在庫など動的な部分は、後から差し込めます。
会員情報を含む動的ページが中心なら、ページ全体を個別化するより、`上部の共通領域だけ先に返す` 構成を勧めます。ここを分けるだけで、LCP が 0.4 秒から 1.0 秒ほど縮むケースがあります。例外は、上部そのものが個別表示で成り立っているマイページ系の画面です。その場合は、ログイン後の主要導線を簡素にし、表示要素数を減らす方が先になります。
LCP画像は容量より見つかる時刻を先に直す
LCP 要素が画像のとき、実務で最も多い失敗は「圧縮すれば終わる」と考えることです。もちろん画像が重すぎるなら軽くすべきです。ただし LCP の最適化ガイドが示す通り、LCP 画像には `発見待ち`、`読込時間`、`描画待ち` があり、容量だけを削っても改善が小さいことがあります。先に直すべきなのは、ブラウザがその画像をいつ見つけるかです。
避けたいのは、ヒーロー画像を CSS の `background-image` にだけ持たせる構成と、初期表示の画像まで一律で `loading="lazy"` を付ける構成です。LCP の最適化ガイドでも、LCP 画像に lazy-load を付けるのは不利だと明確に示されています。画面上部の主要画像は `img` 要素で HTML に出し、必要に応じて `fetchpriority="high"` を使う方が安全です。
実務の目安として、モバイルのヒーロー画像は `250KB から 350KB` に収まると扱いやすく、`500KB 超` なら改善余地を疑うべきです。`1MB 超` の画像をそのままモバイルへ流す構成は、特別な理由がない限り避けてください。ただし、同じ 500KB でも HTML の先頭近くで見つかる画像と、CSS の後に見つかる画像では結果が大きく変わります。先に発見順を整え、その後に AVIF や WebP、`srcset`、`sizes` を詰める方が効果は安定します。
LCP要素ごとの先手を表で整理する
LCP 要素 | 最初の推奨 | 避けるべき実装 | 例外 |
|---|---|---|---|
`img` 要素 | `loading="eager"` 相当で扱い、必要なら `fetchpriority="high"` を付ける | 初期表示の画像まで lazy-load する | 画像が 2 枚以上競合する場合は preload を 1 枚に絞る |
CSS 背景画像 | 可能なら `img` に置き換える | 背景のまま画像圧縮だけで終える | デザイン要件で背景必須なら preload と CSS の早期配信を併用する |
見出しテキスト | フォント読込と CSS 配信を優先する | 画像施策を先に進める | ブランドフォント必須なら `font-display` を再設計する |
カルーセル 1 枚目 | 1 枚目だけ固定表示にする | 初期化完了まで DOM を隠す | どうしてもスライダー必須なら 1 枚目だけ静的に出す |
ヒーロー画像で外せない確認項目を絞る
- LCP 要素が本当にその画像かを確認する。
- 画像が HTML に直接書かれているかを見る。
- `loading="lazy"` が入っていないかを確認する。
- `fetchpriority="high"` か preload のどちらが必要か判断する。
- `srcset` と `sizes` が端末幅に合っているかを見る。
- そのあとで AVIF、WebP、圧縮率を調整する。
この順番を逆にすると、画像処理だけ細かく調整しても改善幅は小さくなります。反対に、発見順が整えば、容量調整の工数を抑えても 0.3 秒から 0.8 秒改善することがあります。
CSSとJavaScriptの描画待ちを止めていく
画像の取得自体は速いのに LCP が伸びるなら、原因は CSS か JavaScript です。クリティカル レンダリング パスの解説でも、ブラウザは HTML を受け取った後にスタイル計算とレイアウトを行うため、上部の描画を止めるコードがあると LCP は悪化します。実務では、`ヒーローを初期非表示にしている`、`描画準備が終わるまで主要要素を出さない`、`ウェブフォント待ちで見出しが見えない`、`外部タグが一斉に走る` の 4 パターンが特に多く見つかります。
ここでの推奨は明確です。`初回表示に不要な CSS と JavaScript を後ろへ回し、上部の表示だけを先に成立させる` べきです。未使用 CSS の削減は悪くありませんが、150KB を 100KB に減らすより、ヒーローの初期非表示を外す方が効く場面は少なくありません。LCP を立て直す局面では、総量削減より表示順の整理を優先してください。
JavaScript についても同じです。レビュー、レコメンド、チャット、AB テスト、計測タグを初回からすべて動かすと、中位端末では Main スレッドが簡単に詰まります。LCP 要素に関係ない処理は初回描画後へ回すべきです。特に商品詳細や LP では、ヒーローの表示前に対話機能をすべて準備する必要はありません。
INP の解説や INP の最適化ガイド、CLS の解説、CLS の最適化ガイドも合わせて見ると、LCP 改善の副作用を防ぎやすくなります。LCP だけを優先して無理に DOM を早出しし、高さが後から変われば CLS が悪化します。逆に JavaScript を雑に削って操作応答が落ちれば INP に跳ねます。上部を先に出し、下部や補助機能を後ろへ回す進め方が最も安全です。
構成ごとに優先施策の順番を変える
記事詳細ページで装飾 CSS が多いなら、先にやるべきなのは `上部に必要なスタイルだけを早く届ける` ことです。細かなアニメーションや装飾は後回しで構いません。記事ページは構造が比較的単純なため、2 週間前後で改善を確認しやすいはずです。
SPA 色の強いサービス LP なら、`ヒーロー、主要見出し、主導線を初期 HTML に戻す` ことを強く勧めます。初期表示の直後に不要な API を並列で投げる構成は避けてください。例外は、上部の内容そのものが利用者ごとに大きく変わる場合です。その場合でも、共通の背景、見出し、主要ボタンまでは先に出せます。
動画やアニメーションを多用するページでは、初回は静止画で見せる方が安定します。動画再生や複雑な動きは、ユーザー操作後か LCP 後へ回すべきです。検索流入の入口ページで動画そのものを LCP に背負わせる設計は、よほど明確な理由がない限り選ばない方がよいでしょう。
サイト規模に応じて優先施策の順番を決める
LCP 改善は、サイト規模に応じて優先順位を変えるべきです。月間 PV 3 万の記事サイトと、月間 PV 300 万の商品サイトでは、同じ施策でも回収効率が異なります。小規模サイトが最初から配信基盤を全面更改する必要はありませんし、大規模サイトが個別対応を続けるのも非効率です。
月間 PV 10 万未満で単一テンプレート中心なら、`主要 3 ページの TTFB`、`LCP 要素`、`lazy-load の有無` を点検し、`フルページキャッシュ`、`ヒーロー画像の発見順`、`不要プラグイン整理` の 3 つに絞って進めるべきです。この規模なら、1 か月以内に LCP が 0.5 秒前後改善する余地が残っていることが多くあります。
月間 PV 10 万から 100 万で複数テンプレートを持つなら、記事、カテゴリ、商品詳細、LP でテンプレートを分け、悪い順に直してください。全ページ一律対応は避けるべきです。実測の悪い上位 20 パーセントへ集中した方が、工数対効果は高くなります。
月間 PV 100 万以上なら、テンプレート別、デバイス別、流入別に実測を持つ運用が必要です。Web Vitals の解説でも、自前の実測計測の重要性が示されています。この規模では、単発修正より性能予算のルール化が効きます。週次で 75 パーセンタイルを追い、基準を超えた変更を止める運用まで入れるべきです。
海外流入や地域差が大きいサイトなら、最初に CDN 配信地域、画像配信拠点、配信元サーバーの位置を見直してください。国内計測だけで判断し続けるのは危険です。地域差が 1 秒近く出る場合は、画像圧縮より配信経路の改善が先になります。
改善の成果を事業数字につなげるなら、速度計測と GA4 を切り離さない方がよいでしょう。GA4の使い方を初心者向けに整理 SEO実装で迷わない計測設計と活用の基本で計測の土台を確認し、問い合わせや資料請求の到達率まで見たいなら GA4のコンバージョン設定で迷わない 事業判断に効く設計とベストプラクティス も合わせて読むと判断が早くなります。JPSM SEO 編集事業部でも、速度だけで議論すると施策が散るため、検索流入、スクロール到達、問い合わせ導線を同じ会議で確認する進め方を取ります。
改善前に外せない実務確認のチェック項目
LCP 改善で失敗しやすいのは、施策そのものより順番です。ここを誤ると、手を入れた量の割に成果が出ず、現場の合意形成が崩れます。Google のページ エクスペリエンスに関する案内でも、Core Web Vitals は重要ですが、それだけで検索評価が決まるわけではないと整理されています。だからこそ速度改善は、「なんとなく速くする作業」ではなく、検索流入と事業成果に近いページから順に進めるべきです。
先回りで潰したい失敗は次の通りです。
よくある失敗 | 修正の考え方 |
|---|---|
画像圧縮だけで終える | 4 区間に分解し、TTFB と描画待ちを先に切り分ける |
初期表示の画像まで lazy-load する | LCP 候補から lazy-load を外し、HTML から見つけやすくする |
ヒーローを CSS 背景だけで持つ | 可能なら `img` に置き換え、難しければ preload と CSS 配信を見直す |
SPA の都合で見出しも画像も後描画にする | 主要見出しとヒーローだけは初期 HTML に戻す |
外部タグを上部で一斉実行する | LCP に不要な処理は描画後へ回す |
改善後にラボ計測だけ見て終える | 実測の 28 日窓と検索流入の変化まで追う |
実務チェックリストは、最低でも次の 7 項目を埋めてから施策を実装してください。
- PageSpeed Insights でモバイル実測 LCP と 75 パーセンタイルを確認したか。
- LCP 要素が画像、見出し、動画のどれか特定したか。
- DevTools で HTML 開始時刻、LCP リソース取得開始、LCP マーカー時刻を並べて見たか。
- LCP 候補に lazy-load や初期非表示が入っていないか確認したか。
- TTFB が 800ms を超えるテンプレートを一覧化したか。
- 初回描画に不要な CSS、JavaScript、外部タグを後ろへ回したか。
- 改善後に実測、検索流入、到達率を 2 週間、4 週間、8 週間で追う計画を持ったか。
この 7 項目を埋めないまま、大規模な画像変換や CDN 更改へ進むのは遠回りです。現場で認識が割れているときほど、チェックリストを先に揃える方が前に進みやすくなります。
今週進めるLCP改善の実装手順を固める
LCP 改善を今週進めるなら、順番は次の通りです。速そうな施策から触るのではなく、遅延区間が大きい順に着手してください。
- 1 日目に、主要 3 テンプレートで PageSpeed Insights と DevTools を取り、`TTFB`、`発見待ち`、`読込時間`、`描画待ち` の 4 列で表にします。
- 2 日目に、TTFB が 800ms を超えるページのキャッシュ、リダイレクト、SSR の待ち時間を点検します。
- 3 日目に、LCP 要素が HTML から見えるか、初期表示の画像に lazy-load が入っていないか、CSS 背景依存になっていないかを直します。
- 4 日目に、ヒーローの初期非表示、描画準備待ち、ウェブフォント待ち、外部タグの同時実行を整理します。
- 5 日目に、改善後のラボ計測を取り、LCP だけでなく CLS と INP も確認します。
- 翌週以降に、実測の変化と検索流入、問い合わせ到達率を追い、改善幅が大きかったテンプレートから横展開します。
要点は明確です。`最初に選ぶべき施策は、画像圧縮ではなく HTML 配信と LCP 要素の発見順の整理` です。ここが整えば、画像、CSS、サーバー応答の改善が正しく効き始めます。今週はまず、主要 3 テンプレートの LCP を 4 区間で表にし、`TTFB 800ms 超`、`発見待ち 300ms 超`、`描画待ち 300ms 超` のどれに当てはまるかを確定させてください。それが、最短で成果につながる着手点です。