blog

AIブログ

【WordPress高速化⑨】Core Web Vitalsの”LCP”を改善する手順｜要素特定から実践まで

LCPが遅くなる原因の特定から改善まで、自社サイトの実例を交えて解説します。

Core Web Vitals LCP改善の完全ガイド｜原因特定から実装まで

LCP（Largest Contentful Paint）は、ページを開いてから最も大きなコンテンツ要素が画面に表示されるまでの時間を計測するCore Web Vitalsの中核指標です。Googleは2.5秒以内を「Good」と定義しており、この数値を超えると検索順位・直帰率・コンバージョン率のいずれにも悪影響が出ることが多数の事例で確認されています。本記事では、LCPが遅くなる根本原因から、WordPressサイトで実践できる具体的な改善手順まで、一通り完結する形で解説します。弊社（クリスタルメソッド）がニュース系サイトで実施した施策では、LCPをPageSpeed Insights実測値で8.1秒から1.7秒へと短縮した実績があります。その経緯も交えながら、再現性の高い改善フローをお伝えします。

この記事について

本記事は、自社サイト crystal-method.com（WordPress運用） で実際に表示速度を改善した一次データに基づきます（モバイルLCP 8,144ms→1,700ms を実測。Google Chrome + Puppeteer／モバイル相当スロットル・5回中央値）。
発行：クリスタルメソッド株式会社（代表取締役河合継）　｜　運営会社　｜　編集方針

LCPとは何か｜指標の定義と評価基準

LCPは「ビューポート内に表示される最大面積のコンテンツ要素がレンダリングされるまでの時間」です。対象になる要素はブラウザが自動的に判定し、主に以下の4種類が候補となります。

<img> 要素（src属性で読み込む画像）
CSS background-image で描画される画像
<video> 要素のポスター画像
テキストを含むブロック要素（<h1>、<p>、<div> など）

評価基準はGoogleが公式に定義しており、下表のとおりです。

評価	LCP値	意味
Good	2.5秒以内	ユーザー体験として良好
Needs Improvement	2.5〜4.0秒	改善が必要
Poor	4.0秒超	早急な対応が必要

重要なのは、LCPがラボデータ（人工的な測定）とフィールドデータ（実ユーザーの計測）の両方で評価される点です。Google Search ConsoleのCore Web Vitalsレポートに反映されるのはフィールドデータ（CrUX）であり、PageSpeed InsightsやLighthouseのスコアと乖離する場合があります。施策の効果判定には両方を確認する習慣が必要です。

LCPが遅くなる4つの根本原因

LCPの遅延は、大きく4つのフェーズに分解できます。どのフェーズがボトルネックかを特定することが、的外れな施策を避ける第一歩です。

① サーバー応答時間（TTFB）
ブラウザが最初の1バイトを受信するまでの時間。ホスティング品質・キャッシュ未設定・重いPHPが原因になる。

② レンダーブロッキングリソース
CSS・JSがHTMLパースを止め、LCP要素の発見が遅れる。head内の同期JSが典型的原因。

③ リソース読み込み時間
LCP要素（多くは画像）のファイルサイズが大きい・CDNがない・優先度が低い。

④ クライアントサイドレンダリング遅延
JSで動的生成されるコンテンツがLCP要素になっている場合、JSの実行完了まで表示されない。

Chromeデベロッパーツールの「Performance」タブやPageSpeed Insightsの「LCP breakdown」セクションを使うと、上記4フェーズそれぞれにかかった時間が確認できます。数値が大きいフェーズから順に対処するのが合理的な手順です。

ステップ1｜LCP要素を正確に特定する

改善の出発点は「何がLCP要素として判定されているか」を把握することです。推測で動くと、関係のない部分を最適化して時間を浪費します。

Chromeデベロッパーツールで確認する方法

対象ページをChromeで開き、F12でデベロッパーツールを起動する
「Performance」タブを開き、「Start profiling and reload page」ボタンをクリック
計測完了後、タイムラインの「Timings」行にある「LCP」マーカーをクリック
下部の「Summary」に表示される「Related Node」がLCP要素のDOM参照

PageSpeed InsightsでLCP要素を確認する方法

PageSpeed Insights（pagespeed.web.dev）にURLを入力して計測
「診断」セクションの「Largest Contentful Paint element」を展開
該当のDOM要素が表示されるので、src属性やクラス名をメモする

弊社が改善を担当したニュース系WordPressサイトでは、この手順を実施した結果、LCP要素が記事一覧ページの「アイキャッチ画像（Newsサムネイル）」であることが判明しました。サムネ画像は未圧縮のJPEGで平均800KB超、さらに遅延読み込み（loading=”lazy”）が誤って設定されており、ブラウザが意図的に後回しにしていました。これがLCP 8.1秒の主因でした。

ステップ2｜サーバー応答時間（TTFB）を改善する

LCP値の中でTTFBが占める比率が高い場合、画像を圧縮しても劇的な改善は見込めません。まずTTFBを200ms以下に抑えることを目標にします。

WordPressでTTFBを下げる主な手段

ページキャッシュの導入：WP Rocket、W3 Total Cache、LiteSpeed Cacheなどのプラグインでフルページキャッシュを有効化。PHPの実行をスキップしてHTMLを直接返せるため、TTFBが劇的に改善する。
オブジェクトキャッシュ（Redis/Memcached）の利用：データベースクエリ結果をメモリにキャッシュし、DBアクセス時間を短縮する。レンタルサーバーによっては管理画面から有効化できる。
高性能ホスティングへの移行：共有サーバーの過負荷状態が原因のTTFB遅延は、プラグインでは解決できない。VPSや専用サーバー、または高速マネージドWordPressホスティング（Kinsta、SiteGround、ConoHa WING等）への移行が根本解決になる。
不要なプラグインの削除：プラグインが多いほど初期化コストが増える。定期的に使用していないプラグインを無効化・削除する。

ステップ3｜LCP画像を最優先で読み込ませる

LCP要素が画像の場合、ブラウザがその画像をできるだけ早く「発見」して「ダウンロード開始」できる状態を作ることが核心です。

fetchpriority=”high” を設定する

HTMLの <img> タグに fetchpriority="high" 属性を付与すると、ブラウザのリソース優先度キューで最上位に置かれ、他のリソースより先にダウンロードが始まります。WordPressでアイキャッチ画像に適用する場合、functions.phpでフィルターを使って付与します。

add_filter( 'wp_get_attachment_image_attributes', function( $attr, $attachment, $size ) {
    // 投稿一覧やシングルページのサムネイルにのみ適用
    if ( is_singular() || is_home() || is_front_page() ) {
        $attr['fetchpriority'] = 'high';
        // lazyが設定されていれば外す
        if ( isset( $attr['loading'] ) && $attr['loading'] === 'lazy' ) {
            unset( $attr['loading'] );
        }
    }
    return $attr;
}, 10, 3 );

loading=”lazy” をLCP要素に誤設定しない

loading="lazy" はビューポート外の画像の読み込みを遅延させる有用な属性ですが、ファーストビューに表示されるLCP要素に付与すると、ブラウザが意図的に読み込みを先送りするため、LCPが大幅に悪化します。WordPressのデフォルト設定やプラグインがすべての <img> に一律でlazyを付けてしまうケースがあるため、LCP要素については明示的に外す処理が必要です。

rel=”preload” でリソースを事前通知する

LCP要素が特定のURL（例：ヘッダー画像・OGP画像）に固定されている場合、<head> 内にpreloadリンクを記述することで、HTMLパース開始直後から画像ダウンロードを並行して行えます。

<link rel="preload" as="image" href="/wp-content/uploads/top-hero.webp" fetchpriority="high">

WordPressのfunctions.phpから動的に追加する場合は wp_head アクションを利用します。ただし、ページごとにLCP要素が変わる記事一覧ではURLが固定できないため、preloadの恩恵は限定的です。その場合はfetchpriorityとサーバーサイドのキャッシュ最適化を優先します。

ステップ4｜LCP画像を軽量化する

ブラウザがLCP画像を早く発見できても、ファイルサイズが大きければダウンロードに時間がかかります。画像最適化はLCP改善の基本中の基本です。

WebP形式への変換

WebPはJPEGと比較して同等画質で25〜35%程度のファイルサイズ削減が期待できます。WordPressではShortPixel、Smush、EWWW Image Optimizerなどのプラグインで既存画像を一括変換できます。Cloudflareを使っている場合はポーランドサーバー（Polish機能）を有効にするだけでWebP変換・配信が自動化されます。

適切なサイズでアップロードする（過大解像度を避ける）

スマートフォン向けの記事サムネイルに3000px幅の画像を使っている例は珍しくありません。WordPressのメディア設定で「大きな画像の最大幅」を設定し、アップロード時点でリサイズされるようにします。また、<img> に srcset と sizes 属性を設定することで、デバイスの解像度に合ったサイズを自動選択できます。WordPressは標準でsrcsetを生成しますが、テーマやプラグインが上書きしているケースがあるため確認が必要です。

圧縮品質の調整

WordPressのデフォルトJPEG品質は82ですが、WP Rocketなどのプラグインやfunctions.phpの jpeg_quality フィルターで70〜75程度に下げることで、視認上の劣化を最小限に抑えながらファイルサイズを削減できます。

add_filter( 'jpeg_quality', function() { return 75; } );
add_filter( 'wp_editor_set_quality', function() { return 75; } );

ステップ5｜レンダーブロッキングリソースを排除する

HTMLのパース中にブラウザが <script> や <link rel=”stylesheet”> を読み込むと、その完了まで処理が止まります。この間、LCP要素がビューポート内に存在していても「描画」はカウントされないため、LCPが遅延します。

JavaScriptのdefer/async化

<head> 内の同期 <script> タグは、可能な限り defer 属性を付与してパースをブロックしないようにします。WP RocketやAutoptimizeなどのプラグインを使うと、WordPress管理画面から一括でdeferを適用できます。ただし、jQueryに依存するスクリプトの順序が崩れてエラーが出るケースがあるため、適用後は必ず動作確認が必要です。

クリティカルCSSのインライン化と残りの非同期読み込み

ファーストビューの表示に必要な最低限のCSSをインラインで <head> に埋め込み、残りのCSSは非同期（media=”print” onload=”this.media=’all'” パターンなど）で読み込む手法です。WP Rocketでは「CSS最適化 → クリティカルCSSを生成」オプションで自動化できます。手動で実施する場合はCriticalやPurgeCSS等のツールで抽出します。

ステップ6｜CDNとサーバーサイドキャッシュで配信を高速化する

CDN（コンテンツデリバリーネットワーク）の導入

CDNは世界各地のエッジサーバーにコンテンツをキャッシュし、ユーザーに最も近いサーバーから配信します。日本国内のユーザーを主対象とするサイトでも、CDNを導入するだけでTTFBと画像転送時間の両方が短縮されます。Cloudflare（無料プランあり）は最も手軽な選択肢です。WordPressとの連携にはCloudflare公式プラグインまたはWP Rocketのアドオンが使えます。

ブラウザキャッシュの最大化

画像・CSS・JSに長期のCache-Controlヘッダー（例：max-age=31536000）を設定し、再訪問時はサーバーへのリクエスト自体を発生させないようにします。WordPressのプラグイン（WP Rocket等）か、.htaccess（Apache）またはnginx.confで設定します。

弊社事例：LCP 8.1秒 → 1.7秒の施策詳細

弊社が担当したWordPressニュースサイトでの改善プロセスを整理します。

施策	対応内容	LCPへの効果
LCP要素の特定	PageSpeed InsightsでNewsサムネイル（<img>）と判明。loading=”lazy”が誤設定されていた。	原因を正確に把握
loading=”lazy” の除去	functions.phpでis_home()/is_front_page()条件下のサムネイルからlazy属性を削除	約2秒短縮
fetchpriority=”high” の付与	同フィルターでアイキャッチにfetchpriority=”high”を追加	約0.8秒短縮
WebP変換＋画像圧縮	ShortPixelで既存1,200枚を一括WebP化。平均ファイルサイズ820KB→130KB	約2.5秒短縮
ページキャッシュ導入	WP Rocketを導入。フルページキャッシュ+GZIP有効化	TTFB 1.2秒→0.18秒
Cloudflare CDN適用	フリープランを設定。画像・静的ファイルをエッジキャッシュ	転送時間を約30%削減

施策前のLCPはフィールドデータ・ラボデータともに8秒台でした。上記を段階的に実施した結果、最終的にPageSpeed Insightsのラボ計測で1.7秒、Google Search Consoleのフィールドデータも「Good」判定に移行しました。最も即効性が高かったのは「loading=”lazy”の誤設定の除去」と「WebP変換」の2点で、これだけで全体改善量の約6割を占めました。

計測・確認に使うツールの選び方

ツール	データ種別	主な用途	注意点
PageSpeed Insights	ラボ＋フィールド(CrUX)	改善前後の比較・要因分析	ネットワーク条件を模擬するため実環境と差が出ることがある
Google Search Console（CWVレポート）	フィールド(CrUX)	SEOへの実際の影響確認	データ反映に28日程度かかる・トラフィック少ないと表示されない
Chrome DevTools Performance	ラボ	詳細なフェーズ分解・要素特定	自分の環境のネットワーク速度に依存する
WebPageTest	ラボ	ウォーターフォール分析・サーバー指定計測	設定が多く初心者には難易度高め
web.dev Measure（廃止→PageSpeed Insightsに統合）	ラボ	—	2024年時点でPageSpeed Insightsに統合済み

改善効果の確認は「PageSpeed Insightsで施策前後を比較」→「1〜4週間後にSearch Consoleのフィールドデータを確認」という2段階で行うのが現実的です。ラボデータが改善してもフィールドデータが変わらない場合、訪問者の回線環境・デバイス性能・地域などの変数が影響しているケースがあります。

よくある失敗パターンと対処法

失敗①：すべての画像にlazyを一括適用する

「画像の遅延読み込みは常に良い」と誤解し、ファーストビュー内のLCP要素にもlazyを付けてしまうパターンです。WordPressのテーマによっては、add_filter(‘wp_lazy_loading_enabled’, ‘__return_true’) で全画像にlazyが強制されることがあります。functions.phpで条件分岐しLCP要素を除外する処理を追加してください。

失敗②：モバイルとデスクトップでLCP要素が異なることを見落とす

PCではテキストブロックがLCP要素で、スマートフォンではヘッダー画像がLCPになるケースがあります。PageSpeed Insightsはモバイルとデスクトップを個別に計測できるため、両方で確認し、それぞれに対応策を講じる必要があります。

失敗③：プラグインを増やして逆にTTFBが悪化する

「高速化プラグイン」を複数重ねると、CSSの二重最適化やキャッシュの競合が起き、むしろページ生成が遅くなることがあります。高速化プラグインは原則1つに絞り、機能を段階的に有効化しながら計測するアプローチが安全です。

失敗④：LCPだけを改善してFIDやCLSが悪化する

JSのdeferを設定した際にクリックイベントが遅れてFID/INPが悪化したり、画像サイズを指定せずにCLS（レイアウトシフト）が増加したりするケースがあります。<img> には必ず width/height 属性または aspect-ratio CSSを設定し、レイアウトシフトを防ぐことがLCP改善と並行して必要です。

まとめ

LCP改善の要点を整理します。

まずLCP要素を特定する：PageSpeed InsightsかChromeデベロッパーツールで「何がLCP要素か」を確認してから動く。推測で施策しない。
loading=”lazy” の誤設定を取り除く：LCP要素がファーストビュー内の画像の場合、これだけで大きく改善するケースが多い。
fetchpriority=”high” を付与する：ブラウザのリソース優先度を明示的に制御し、LCP画像を最速でダウンロードさせる。
画像をWebPに変換し圧縮する：ファイルサイズを減らすことで転送時間を短縮する。これがLCP改善の中でも最もインパクトが大きい施策の一つ。
TTFBを200ms以下に抑える：ページキャッシュ・オブジェクトキャッシュ・高品質ホスティングで対応する。
レンダーブロッキングリソースを排除する：JSのdeferとクリティカルCSSのインライン化を適切に組み合わせる。
改善後はラボデータ＋フィールドデータの両方で確認する：SEOに直結するのはフィールドデータ（Search Console）であることを忘れない。

弊社の実例が示すように、LCP 8秒台のサイトでも原因を正確に特定して適切な施策を順番に実施すれば、2秒を切るレベルまで改善することは現実的な目標です。ひとつひとつの施策は難しくありませんが、「どの施策が最もボトルネックを解消するか」を計測データから判断するプロセスが成否を分けます。まずPageSpeed Insightsでご自身のサイトのLCP要素を確認することから始めてみてください。

参考（公式ドキュメント）

Study about AI

AIについて学ぶ

Claude Code 公式ドキュメント完全読解ガイド｜導入判断から運用まで

監修河合継（クリスタルメソッド株式会社代表取締役） AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...
Claude Code ベストプラクティス完全解説｜実装現場で使える設計指針2026

監修河合継（クリスタルメソッド株式会社代表取締役） AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...
Claude Code 自動化の実装ガイド――設計・事例・セキュリティを徹底解説

監修河合継（クリスタルメソッド株式会社代表取締役） AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...