WordPressのCore Web Vitals: 最適化ガイド（2026年）

WordPressとCore Web Vitalsの現状

WordPressにはパフォーマンス上の問題があります。CrUXデータを基にしたCore Web Vitals Technology Reportによると、モバイルのCore Web Vitals合格率において、WordPressは一貫してShopify、Wix、Squarespaceの後塵を拝しています。2025年後半時点で、3つのCore Web Vitalsすべてに合格しているモバイルのWordPressサイトは約44%にすぎません。Shopifyの約65%やWixの60%超と比べても低水準です。

これはWordPress自体が本質的に遅いからではありません。WordPressコアは軽量です。問題は、その上に追加される要素にあります。重いテーマ、肥大化したページビルダー、それぞれが独自のJavaScriptやCSSを挿入する無数のプラグイン、最適化されていない画像、そしてサーバー応答時間の遅い安価な共有ホスティングです。

一方で、WordPressはコード、ホスティング、最適化戦略を完全に制御できます。そのため、適切な最適化を行えば劇的な改善が見込めるプラットフォームでもあります。私が支援しているサイトでは、すべてのページで日常的にCore Web Vitalsに合格しています。重要なのは、各指標に影響を与えるWordPress特有の要因を理解し、体系的に対処することです。

数字で見るWordPressのCore Web Vitals

CrUX Technology ReportとHTTP Archiveは、主要CMSのCWV合格率を追跡しています。2025年後半時点におけるWordPressの立ち位置は以下のとおりです。

出典: HTTP Archive提供のCrUX Technology Report（2025年6月）。INPの順位はSearchEngineJournalの分析によるものです。

このデータから得られる重要な知見は、WordPressの課題はINPではないということです（合格率は85.9%で、平均をわずかに下回る程度です）。WordPressの真の課題は、低速なTTFBに起因するLCPです。CrUXデータによると、良好なTTFBを達成しているWordPressサイトはわずか32%にとどまります。これに対し、Shopifyのようなフルホステッド型のプラットフォームではインフラレベルでTTFBが最適化されています。これはプラットフォーム自体の問題ではなく、ホスティングの品質の問題です。

CoreDashでモニタリングしているWordPressサイト全体を見ても、同じ傾向が一貫して現れています。最適化前のモバイルLCP中央値は3.5〜4.5秒です。本ガイドで解説するホスティング、キャッシュ、画像の最適化を実施した後は、中央値が1.6〜2.1秒まで改善します。最も効果が大きい変更は、ページキャッシュのない共有ホスティングから、サーバーレベルのキャッシュとCDNを備えたマネージドホスティングへの移行です。この変更だけで、通常800ms以上かかっていたTTFBが200ms未満に短縮されます。

WordPressがCore Web Vitalsで苦戦する理由

具体的な対策に入る前に、WordPressサイトがCore Web Vitalsに不合格となる5つの根本原因を理解しておく必要があります。私のコンサルティング経験上、目にする問題はすべて以下のいずれか（または複数）に起因しています。

1. ページビルダーによる肥大化

Elementor、Divi、WPBakeryなどのページビルダーは、すべてのページに膨大な量の余分なHTML、CSS、JavaScriptを追加します。Elementorだけでも、解凍後のコード量はWordPress環境に21MB以上追加されることがあります。ウィジェット、アニメーション、スタイリングのオプションが増えるたびに、DOMサイズとrender blockingリソースの量が増加します。

その結果、何百もの不要な<div>ラッパー要素でページが肥大化し、ウィジェットが使われているかどうかにかかわらずページごとに複数のCSSファイルが読み込まれ、読み込み中にJavaScriptがmain threadをブロックします。これは、LCP（render blockingリソースの増加）、INP（main threadを占有するJavaScriptの増加）、CLS（ビルダーのCSS読み込みによるレイアウト再計算）に直接悪影響を及ぼします。

WordPress標準のブロックエディタであるGutenbergは、はるかに簡潔なHTMLを生成し、DOMサイズも小さく抑えられます。新規にWordPressサイトを構築する場合は、重いページビルダーを避け、GeneratePress、Astra、Kadenceなどの軽量テーマとGutenbergの組み合わせを検討してください。

2. プラグインの過剰導入

一般的なWordPressサイトでは、20〜30個のプラグインが有効化されています。プラグインは、使用されていないページであっても、あらゆるページに独自のCSSやJavaScriptを挿入する可能性があります。トップページでお問い合わせフォームのスクリプトが読み込まれたり、ブログ記事でWooCommerceのスクリプトが読み込まれたり、1ページでしか使っていないスライダーのプラグインが全ページで読み込まれたりします。

私が監査したWordPressサイトの中には、不要なプラグインスクリプトを削除しただけで、JavaScriptの総量を40%以上削減できたケースもあります。必ずしもプラグインを完全に削除する必要はありません。重要なのは条件付き読み込みです。各プラグインのアセットが、実際に必要とされるページでのみ読み込まれるように設定します。PerfmattersやAsset CleanUpなどのプラグインを使えば、読み込むスクリプトやスタイルをページ単位で制御できます。

3. 最適化されていない画像

WordPressはデフォルトでは画像の最適化を強制しません。コンテンツ管理者がカメラから直接3000×2000ピクセルの写真をアップロードすると、テーマが800ピクセル幅でしか表示しない場合でも、WordPressはフル解像度で配信してしまいます。大半のWordPressページにおいてLCP要素は画像であり、最適化されていないヒーロー画像はLCP不合格の最も典型的な原因です。

WordPress 5.8以降でWebPがネイティブサポートされ、WordPress 5.5以降でネイティブのlazy loadingが追加されましたが、これらの機能を活かすには適切な設定が必要です。多くのテーマやプラグインがこれらの機能を上書きしたり、独自に（往々にして質の劣る）実装を行ったりしています。包括的な戦略については、Core Web Vitalsに向けた画像最適化ガイドを参照してください。

4. 低速なホスティングとサーバー応答

サーバーのTime to First Byte（TTFB）は、LCPの下限を決定づけます。サーバーの応答に800msもかかっていては、フロントエンドをいくら最適化してもカバーできません。何百ものサイトが1台のサーバーを共有する安価な共有ホスティングは、WordPressサイトでTTFBが悪化する最大の原因です。

WordPressは動的なCMSであり、キャッシュを設定しない限り、ページリクエストのたびにPHPを実行してMySQLデータベースに問い合わせを行います。ページキャッシュがなければ、WordPressは静的サイトよりも本質的に遅くなります。適切なキャッシュと高品質なホスティング環境があれば、TTFBを200ms未満に抑えることが可能です。設定がなければ、500ms〜1500msかかるのが一般的です。詳細はTime to First Byte最適化ガイドをご覧ください。

5. フォント読み込みの問題

多くのWordPressテーマはGoogleのサーバーからGoogle Fontsを読み込みます。これには、フォントのダウンロードを開始する前に外部ドメインへのDNSルックアップと接続が必要です。これによりテキストの描画が遅れ（テキストがLCP要素の場合にLCPが悪化）、Webフォントが読み込まれてfallbackと入れ替わる際にFlash of Unstyled Text（FOUT）が発生してCLSの原因になります。

対策は、フォントをセルフホストし、font-display: swapまたはfont-display: optionalを適用したうえで、適切に調整したfallbackフォントを使用してレイアウトのズレを最小限に抑えることです。

WordPressにおけるLCPの改善

Largest Contentful Paintは、メインコンテンツがどれだけ素早く表示されるかを測定します。WordPressにおいてLCPが不合格になる原因は、ほぼ例外なく画像、render blockingリソース、またはサーバー応答の遅さにあります。LCP改善の優先順位は以下のとおりです。

LCP要素を特定する

PageSpeed Insightsでページを計測し、「診断」項目の「Largest Contentful Paint の要素」を確認してください。大半のWordPressページでは、ヒーロー画像、アイキャッチ画像、または最初の大きなテキストブロックがこれに該当します。何がLCP要素になっているかを把握することで、取るべき最適化戦略が決まります。

LCP画像のプリロード

LCP要素が画像の場合は、テーマの<head>にプリロードのヒントを追加します。WordPressでは、テーマのfunctions.phpに以下のコードを追加して実装できます。

// ホームページのヒーロー画像をプリロード
function preload_lcp_image() {
    if ( is_front_page() ) {
        echo '<link rel="preload" as="image" href="/wp-content/uploads/hero.webp" fetchpriority="high">';
    }
}
add_action( 'wp_head', 'preload_lcp_image', 1 );

また、LCP画像の<img>タグに直接fetchpriority="high"を付与してください。WordPress 6.3以降では最初のコンテンツ画像に対してこれが自動的に適用されますが、使用しているテーマで正常に動作しているか確認が必要です。包括的な戦略については、LCP画像のプリロード方法を参照してください。

render blockingリソースの排除

WordPressのテーマやプラグインは、レンダリングをブロックするCSSやJavaScriptを<head>内でキュー（enqueue）に追加することがよくあります。パフォーマンスプラグインを使用して、クリティカルでないJavaScriptを遅延実行（defer）し、クリティカルでないCSSを非同期で読み込んでください。特に効果的な選択肢は以下のとおりです。

• WP Rocket: ユーザー操作があるまでJavaScriptの実行を遅延させ、critical CSSを自動生成します
• FlyingPress: 同等のdefer機能とcritical CSS生成機能を備えた軽量な選択肢です
• Perfmatters: ページ単位での詳細なスクリプト管理、未使用機能の無効化が可能です
• 当サイトのWP Core Web Vitalsプラグイン: LCP検出や高度な画像タイミング制御を備えた、CWV最適化専用設計のプラグインです

手動で制御する方法については、JavaScriptをdefer（遅延実行）させる14の方法およびcritical CSSの生成と使用方法を参照してください。

ページキャッシュの有効化

ページキャッシュは完全にレンダリングされた各ページのHTMLを保存するため、アクセスごとにWordPressがPHPを実行してデータベースに問い合わせる必要がなくなります。これによりTTFBが劇的に削減され、LCPの直接的な改善につながります。高品質なマネージドWordPressホスティング（Kinsta、SiteGround、WP Engine、Cloudwaysなど）の多くには、サーバーレベルのキャッシュが含まれています。利用中の環境に含まれていない場合は、キャッシュプラグインを導入してください。

さらにCDNを設定し、訪問者に近いエッジロケーションからキャッシュされたページを配信してください。設定手順はパフォーマンス向上のためのCloudflare設定方法を参照してください。

WordPressにおけるINPの改善

Interaction to Next Paintは、クリック、タップ、キー入力に対するサイトの応答速度を測定します。WordPressサイトでINPが不合格になる原因は、main thread上の過剰なJavaScriptです。主な原因は以下のとおりです。

プラグインのJavaScript問題

インストールされたプラグインは、ページ読み込みごとに実行されるJavaScriptを追加する可能性があります。訪問者がその機能を利用しない場合でも、その機能のJavaScriptがmain threadの処理時間を奪い合います。訪問者がボタンをクリックした際、main threadが解放されるまでブラウザは応答できません。

プラグインは妥協せずに監査してください。すべてのプラグインに対して「このページタイプで読み込む必要があるか」を確認します。Chrome DevToolsのCoverageタブを使用して、ページごとにどれだけのJavaScriptが使われていないかを調べます。そのうえで、スクリプト管理プラグインを使い、不要なページで特定のスクリプトを無効化してください。

WooCommerceスクリプトの管理

WooCommerceは、WordPressでINPが悪化する最大の要因の一つです。デフォルトのWooCommerceは、Eコマース機能を持たないブログ記事や固定ページを含め、すべてのページでJavaScriptとCSSを読み込みます。Disable WooCommerce BloatやPerfmattersなどのプラグインを使用して、ショップ関連以外のページでWooCommerceのアセットが読み込まれないようにしてください。

サードパーティスクリプトのdeferと遅延実行

Google Analytics、Facebook Pixel、Google Tag Manager、チャットウィジェット、マーケティングツールはすべて、main threadをブロックするJavaScriptを追加します。最も効果的な戦略は、最初のユーザー操作（スクロール、クリック、キー入力）まで、これらのスクリプトの実行を遅延（delay）させることです。これにより、サードパーティスクリプトが初期ページの応答性に影響を与えるのを完全に防ぐことができます。

WP Rocketの「Delay JavaScript Execution」機能を使えば、これを自動化できます。手動で実装する場合は、JavaScriptの遅延に関するガイドを参照してください。

WordPressにおけるCLSの改善

Cumulative Layout Shiftは、予期しないコンテンツのズレを測定します。WordPressサイトでCLSが不合格になる原因は、画像の寸法指定の欠落、フォントの切り替え、動的に挿入されるコンテンツです。

画像寸法の明示

ブラウザが画像の読み込み前に正しい表示領域を確保できるよう、すべての<img>タグには明示的なwidthおよびheight属性が必要です。WordPress 5.5以降はこれらが自動的に付与されますが、多くのテーマがこの動作を上書きしたり、寸法指定のない独自の画像マークアップを使用したりしています。テーマの画像テンプレートを確認し、寸法属性が含まれているか検証してください。

広告や動的コンテンツの表示領域を確保する

ページ読み込み後にコンテンツを挿入する広告枠、Cookie同意バナー、メルマガ登録ポップアップ、通知バーなどは、WordPressサイトにおけるCLSの最も典型的な原因です。CSSのmin-height宣言を使用してこれらの要素の表示領域をあらかじめ確保し、要素が表示された際に周囲のコンテンツがズレないようにしてください。

フォントに起因するレイアウトシフトの解消

Webフォントが読み込まれてfallbackフォントと入れ替わる際、テキストが再フローして周囲の要素を押し動かすことがあります。対策は2点あります。フォントをセルフホストして外部DNSルックアップを排除すること、そしてCSSでfont-display: optionalを指定するか、CSSのsize-adjustプロパティを使って適切に調整したfallbackフォントを設定することです。これにより、Webフォントの読み込みが遅れた場合でもテキストのズレを防げます。完全なガイドについては、CLS最適化ガイドを参照してください。

WordPressのホスティングとCore Web Vitals

利用するホスティングプロバイダーによって、WordPressサイトのパフォーマンスの上限が決まります。主要なホスティングタイプがCore Web Vitalsに与える影響は以下のとおりです。

TTFBが恒常的に400msを超えている場合、フロントエンドをいくら最適化してもLCPを合格（Good）水準にすることはできません。まずはホスティングをアップグレードしてください。SiteGround、Kinsta、CloudwaysなどのマネージドWordPressホスティングは、サーバーレベルのキャッシュ、PHP 8.x、CDN統合を提供しており、TTFBを劇的に短縮できます。

CrUXデータも、これがWordPressの最大の課題であることを裏付けています。インフラが最適化されているShopifyやWixなどのフルホステッド型プラットフォームとは対照的に、良好なTTFBを達成しているWordPressサイトはわずか32%です。CoreDashのfield dataでも同様の傾向が見られます。共有ホスティング上のWordPressサイトでは、p75 TTFBの平均が900ms〜1400msに達します。同じサイトをサーバーレベルのキャッシュを備えたマネージドホスティングに移行すると、120ms〜250msまで短縮されます。他の最適化を一切行わなくても、この変更だけでLCPが「Poor（不良）」から「Good（良好）」へと改善することも珍しくありません。

ページビルダーのパフォーマンス比較

ページビルダーの選択（または使用しないという判断）は、WordPressにおけるCore Web Vitalsを左右する最大のアーキテクチャ上の決定事項です。これまでの監査で一貫して確認されている結果は以下のとおりです。

すでにElementorやDiviを使用していて移行が難しい場合は、「Optimized DOM Output」や「Optimized Asset Loading」機能を有効化し、未使用のウィジェットやアニメーションを削除したうえで、WP Rocketなどのキャッシュプラグインを使用して追加のオーバーヘッドを補ってください。

WordPressサイトのCoreDash field dataも同様の傾向を示しています。Gutenbergと軽量テーマで構築されたサイトは、一貫してモバイルLCPの中央値2.0秒未満を達成しています。一方、最適化前のElementorサイトは、モバイルLCPの中央値が通常3.8〜5.2秒となっており、その差はほぼすべて、追加されたrender blockingなCSSとJavaScriptに起因しています。最適化（critical CSS、JavaScriptの遅延、DOM削減）を実施すれば、Elementorサイトでも2.0〜2.8秒に到達できますが、プラグインやビルダーの更新によって肥大化が再発しやすいため、継続的なメンテナンスが欠かせません。

WordPress Core Web Vitals最適化チェックリスト

以下は、私がWordPressサイトのCore Web Vitalsを最適化する際に実践している体系的なアプローチです。順番に実施してください。

インフラストラクチャ（最優先で実施）

• サーバーレベルのキャッシュとPHP 8.xを備えたマネージドWordPressホスティングにアップグレードする
• CDNを設定する（Cloudflare設定ガイド）
• ページキャッシュを有効化する（サーバーレベル、またはWP Rocket / LiteSpeed Cacheを使用）
• GZIPまたはBrotli圧縮を有効化する

テーマとビルダー

• 可能であれば軽量テーマ（GeneratePress、Astra、Kadence）に切り替える
• ページビルダーを使用している場合は、DOM出力の最適化とアセット読み込みの最適化を有効にする
• 未使用のテーマ機能、ウィジェット、アニメーションを削除する
• WordPressコア、テーマ、すべてのプラグインを最新バージョンに更新する

画像

• fetchpriority="high"を指定してLCP画像をプリロードする
• ShortPixel、Imagify、Smushなどを使用して画像をWebPまたはAVIFに変換する
• 適切なsrcsetおよびsizes属性を指定してレスポンシブ画像を配信する
• すべての<img>タグに明示的なwidthとheightを追加する
• ファーストビュー（above the fold）の画像をlazy loadingしない（LCPが悪化します）

JavaScriptとCSS

• クリティカルでないJavaScriptを遅延実行（defer）する
• ユーザー操作があるまでサードパーティスクリプトの実行を遅延させる
• critical CSSを生成してインライン化する
• PerfmattersやAsset CleanUpを使用し、ページごとに不要なプラグインスクリプトを削除する
• ショップ以外のページでWooCommerceのアセットを無効化する

フォント

• Google Fontsをセルフホストする
• 重要なフォントファイルをプリロードする
• font-display: swapまたはoptionalを使用する
• フォントファミリーは最大2種類までに抑える

モニタリング

• CoreDash Real User Monitoringを設定し、field dataを継続的に追跡する
• Google Search ConsoleのCore Web Vitalsレポートを毎週確認する
• テーマの更新、プラグインの変更、コンテンツの更新を行うたびに再テストを実施する

あらゆる最適化領域を網羅したプラットフォーム共通の完全なチェックリストについては、究極のCore Web Vitalsチェックリストを参照してください。

WordPressにおけるCore Web Vitalsの計測

WordPressにはCore Web Vitalsのレポート機能が組み込まれていません。パフォーマンスを計測するには、外部ツールを使用する必要があります。

• Google Search Console: 実際のCrUX field dataに基づき、サイト全体でどのページが合格または不合格かを表示します。「エクスペリエンス」内の「Core Web Vitals」レポートを確認してください。
• PageSpeed Insights: 個別のURLをテストし、field data（CrUX）とlab data（Lighthouse）の両方を提供します。特定ページの診断に使用します。
• CoreDash: ページ、デバイス、国、個別の要素ごとにブレークダウンされたリアルタイムのfield dataを提供するReal User Monitoringツールです。CrUXの28日間の集計期間とは異なり、変更の影響を即座に確認できます。
• Chrome DevTools: Performanceパネルを使用してINPを悪化させるlong taskを特定し、Coverageタブで未使用のJavaScriptやCSSを検出します。

これらのツールの完全な比較については、計測ツールの比較表を含むCore Web Vitals概要を参照してください。

WordPressにおけるCore Web Vitalsのよくある間違い

何百ものWordPressサイトを監査してきた経験の中で、最も頻繁に目にする間違いは以下のとおりです。

• LCP画像のlazy loading: WordPressはデフォルトで画像にloading="lazy"を付与します。ヒーロー画像がLCP要素である場合、lazy loadingを行うと読み込みが遅延します。LCP画像はlazy loadingから除外し、fetchpriority="high"を指定してください。
• 最適化プラグインの重複導入: WP Rocket、Autoptimize、LiteSpeed Cache、W3 Total Cacheを同時に導入すると競合が発生します。キャッシュ/最適化プラグインは1つに絞り、適切に設定してください。
• field dataの軽視: Lighthouseのスコアが95点であっても、Core Web Vitalsに合格しているとは限りません。Googleは実際の訪問者から得られるfield dataを使用します。実機を使用する実際の訪問者の体験はまったく異なる場合があります。常にSearch Consoleを確認するか、RUMを導入してください。
• アップデート後のテスト不足: テーマやプラグインの更新によって、Core Web Vitalsが知らぬ間に悪化することがあります。初期の最適化時だけでなく、継続的に監視してください。