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

WordPressとCore Web Vitals：現状

WordPressにはパフォーマンスの問題があります。CrUXデータを活用したCore Web Vitals Technology Reportによると、WordPressはモバイルのCore Web Vitals合格率で常に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%であり、インフラストラクチャレベルでTTFBが処理されるShopifyのような完全ホスト型プラットフォームとは対照的です。これはホスティング品質の問題であり、プラットフォームの問題ではありません。

CoreDashによって監視されているWordPressサイト全体で、その傾向は一貫しています。最適化前は、モバイルLCPの中央値は3.5〜4.5秒です。このガイドで説明されているホスティング、キャッシュ、画像の最適化を実施した後、中央値は1.6〜2.1秒に低下します。単一で最も影響の大きい変更は、ほぼ常に、ページキャッシュのない共有ホスティングから、サーバーレベルのキャッシュとCDNを備えたマネージドホスティングへのアップグレードであり、これだけで通常、TTFBは800ミリ秒以上から200ミリ秒未満に短縮されます。

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

修正に飛び込む前に、WordPressサイトがCore Web Vitalsで不合格になる5つの根本原因を理解する必要があります。私のコンサルティング業務で見られるすべての問題は、以下のいずれか（または複数）に起因しています：

1. ページビルダーの肥大化

Elementor、Divi、WPBakeryのようなページビルダーは、すべてのページに膨大な量の追加HTML、CSS、JavaScriptを加えます。Elementorだけでも、解凍すると21MBを超えるコードがWordPressインストールに追加される可能性があります。各ウィジェット、アニメーション、およびスタイリングオプションは、DOMサイズとレンダリングブロックリソースの量を増加させます。

結果として、何百もの不要な<div>ラッパー要素を持つ肥大化したページ、ウィジェットが使用されているかどうかにかかわらずすべてのページで読み込まれる複数のCSSファイル、ページ読み込み中にメインスレッドをブロックするJavaScriptが生じます。これは直接的にLCP（レンダリングブロックリソースの増加）、INP（メインスレッドで競合するJavaScriptの増加）、CLS（ビルダーのCSSが読み込まれる際のレイアウト再計算）に悪影響を及ぼします。

Gutenberg（ネイティブのWordPressブロックエディタ）は、DOMのフットプリントが小さく、はるかにクリーンなHTMLを生成します。新しいWordPressサイトを構築する場合は、重いページビルダーの代わりに、GeneratePress、Astra、Kadenceなどの軽量テーマとGutenbergの使用を検討してください。

2. プラグインの過剰搭載

平均的なWordPressサイトには、20〜30個のアクティブなプラグインがあります。各プラグインは、そのプラグインが使用されていないページであっても、すべてのページに独自のCSSとJavaScriptを注入する可能性があります。ホームページでスクリプトを読み込むお問い合わせフォームプラグイン。ブログ投稿で読み込まれるWooCommerceスクリプト。1つのページでしか使用していないにもかかわらず、あらゆる場所で読み込まれるスライダープラグインなどです。

私は、未使用のプラグインスクリプトを削除することで、JavaScriptの総量を40%以上削減できたWordPressサイトを監査したことがあります。解決策は必ずしもプラグインを完全に取り除くことではありません。重要なのは条件付き読み込み、つまり各プラグインのアセットが実際に必要なページでのみ読み込まれるようにすることです。PerfmattersやAsset CleanUpのようなプラグインを使用すると、どのスクリプトやスタイルを読み込むかをページごとに制御できます。

3. 未最適化の画像

WordPressはデフォルトでは画像の最適化を強制しません。コンテンツ編集者がカメラから直接3000x2000ピクセルの写真をアップロードすると、テーマが800ピクセルの幅でしか表示しない場合でも、WordPressはフル解像度で配信します。ほとんどのWordPressページのLCP要素は画像であり、未最適化のヒーロー画像はLCP失敗の最も一般的な単一の原因です。

WordPress 5.8以降ではネイティブのWebPサポートが追加され、WordPress 5.5以降ではネイティブの遅延読み込みが追加されましたが、これらの機能には適切な設定が必要です。多くのテーマやプラグインはそれらを上書きしたり、独自の（多くの場合、より悪い）バージョンを実装したりします。完全な戦略については、Core Web Vitalsのための画像最適化ガイドをご覧ください。

4. 遅いホスティングとサーバーの応答

サーバーのTime to First Byte（TTFB）は、LCPの基準を定めます。応答に800ミリ秒かかるサーバーは、どれだけフロントエンドの最適化を行っても補うことはできません。安価な共有ホスティング（数百のサイトが単一のサーバーを共有する）は、WordPressサイトのTTFBが低下する最も一般的な原因です。

WordPressは、ページリクエストごとにPHPを実行し、MySQLデータベースにクエリを実行する動的CMSです（キャッシュが設定されていない場合）。ページキャッシュがない場合、WordPressは静的サイトよりも本質的に遅くなります。適切なキャッシュと高品質なホストがあれば、TTFBは200ミリ秒未満になります。それらがない場合、500ミリ秒から1500ミリ秒になるのが一般的です。詳しくは、Time to First Byte最適化ガイドをご覧ください。

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

多くのWordPressテーマはGoogleのサーバーからGoogle Fontsを読み込みますが、これにはフォントのダウンロードが始まる前にDNSルックアップと外部ドメインへの接続が必要です。これによりテキストのレンダリングが遅延し（テキストベースのLCP要素のLCPを悪化させます）、ウェブフォントが切り替わってフォールバックと置き換わる際にFlash of Unstyled Text（FOUT）を引き起こし、CLSを発生させる可能性があります。

解決策：フォントをセルフホストし、適切に調整されたフォールバックフォントとともにfont-display: swapまたはfont-display: optionalを使用してレイアウトのずれを最小限に抑えます。

WordPressでのLCPの修正

Largest Contentful Paintは、メインコンテンツがどれだけ早く表示されるかを測定します。WordPressでは、LCPの失敗はほぼ常に、画像、レンダリングブロックリソース、または遅いサーバー応答に起因します。LCPを修正するための優先順位は次のとおりです：

LCP要素の特定

ページをPageSpeed Insightsで実行し、「診断」セクションの「Largest Contentful Paint element」を確認します。ほとんどのWordPressページでは、これはヒーロー画像、アイキャッチ画像、または最初の大きなテキストブロックです。LCP要素が何であるかを知ることで、最適化戦略が決まります。

LCP画像のプリロード

LCP要素が画像の場合は、テーマの<head>にpreloadヒントを追加します。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画像をプリロードする方法をご覧ください。

レンダリングブロックリソースの排除

WordPressのテーマやプラグインは、レンダリングをブロックするCSSやJavaScriptを<head>内にエンキューすることがよくあります。パフォーマンスプラグインを使用して、非クリティカルなJavaScriptを遅延させ、非クリティカルなCSSを非同期に読み込みます。最も効果的なオプションは以下のとおりです：

• WP Rocket: ユーザーの操作があるまでJavaScriptの実行を遅延させ、クリティカルCSSを自動的に生成します
• FlyingPress: 同様のdefer（遅延）およびクリティカルCSS機能を備えた軽量な代替手段です
• Perfmatters: ページごとのきめ細かいスクリプト管理を行い、未使用の機能を無効にします
• 私たちのWP Core Web Vitalsプラグイン: LCP検出と高度な画像タイミングを備えたCWV最適化に特化して設計されています

手動で制御する場合は、JavaScriptを遅延させる14の方法とクリティカルCSSの生成と使用方法をご覧ください。

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

ページキャッシュは各ページの完全にレンダリングされたHTMLを保存するため、WordPressは訪問のたびにPHPを実行してデータベースにクエリを実行する必要がなくなります。これによりTTFBが劇的に短縮され、LCPが直接的に改善されます。高品質のマネージドWordPressホスト（Kinsta、SiteGround、WP Engine、Cloudwaysなど）のほとんどは、サーバーレベルのキャッシュを含んでいます。利用中のホストに含まれていない場合は、キャッシュプラグインをインストールしてください。

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

WordPressでのINPの修正

Interaction to Next Paintは、クリック、タップ、キー入力に対してサイトがどれだけ早く応答するかを測定します。WordPressサイトがINPで不合格になる理由は、メインスレッド上の過剰なJavaScriptです。最大の原因は以下のとおりです：

プラグインのJavaScript問題

インストールされた各プラグインは、すべてのページ読み込み時に実行されるJavaScriptを追加する可能性があります。訪問者がその機能と一度もやり取りしなくても、その機能のJavaScriptはメインスレッドの時間を巡って競合し続けます。訪問者がボタンをクリックしたとき、ブラウザはメインスレッドが空くまで応答できません。

プラグインを徹底的に監査してください。各プラグインについて、このタイプのページで読み込む必要があるか？と自問してください。Chrome DevTools Coverage tabを使用して、各ページでどれだけのJavaScriptが未使用であるかを確認します。次に、スクリプト管理プラグインを使用して、不要なページで特定のスクリプトを無効にします。

WooCommerceのスクリプト管理

WooCommerceは、WordPressのINP問題における最大の要因の1つです。デフォルトでは、WooCommerceはコマース機能のないブログ投稿や静的ページを含む、すべてのページでJavaScriptとCSSを読み込みます。Disable WooCommerce BloatやPerfmattersのようなプラグインを使用して、ショップ以外のページでWooCommerceのアセットが読み込まれるのを防ぎます。

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

Google Analytics、Facebook Pixel、Google Tag Manager、チャットウィジェット、マーケティングツールはすべて、メインスレッドをブロックするJavaScriptを追加します。最も効果的な戦略は、最初のユーザーインタラクション（スクロール、クリック、キー入力）までこれらのスクリプトを遅延させることです。こうすることで、サードパーティのスクリプトが初期のページの応答性に影響を与えることは全くなくなります。

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宣言を使用して明示的なスペースを確保してください。

フォント関連のレイアウトのずれを修正する

ウェブフォントが読み込まれ、フォールバックフォントと置き換わる際、テキストがリフローして周囲の要素をずらす可能性があります。解決策は2つあります：フォントをセルフホストし（外部DNSルックアップを排除する）、CSSでfont-display: optionalを使用するか、CSSのsize-adjustプロパティを使用して慎重に調整されたフォールバックを使用するように設定します。こうすることで、ウェブフォントの読み込みが遅れてもテキストがずれることはありません。完全なガイドについては、CLS最適化ガイドをご覧ください。

WordPressホスティングとCore Web Vitals

ホスティングプロバイダーは、WordPressサイトのパフォーマンスの上限を決定します。主なホスティングタイプがCore Web Vitalsに与える影響は次のとおりです：

TTFBが常に400ミリ秒を超えている場合、どれほどフロントエンドの最適化を行っても良好なLCPには到達しません。まずホスティングをアップグレードしてください。SiteGround、Kinsta、CloudwaysなどのマネージドWordPressホストは、サーバーレベルのキャッシュ、PHP 8.x、およびCDN統合を提供し、TTFBを劇的に短縮します。

CrUXデータは、これがWordPressの最大の問題であることを裏付けています。インフラストラクチャが管理されているShopifyやWixなどの完全ホスト型プラットフォームと比較して、良好なTTFBを持つWordPressサイトはわずか32%です。CoreDashのフィールドデータも同じ傾向を示しています。共有ホスティングのWordPressサイトの平均p75 TTFBは900ミリ秒〜1400ミリ秒です。同じサイトをサーバーレベルのキャッシュを備えたマネージドホスティングに移行すると、120ミリ秒〜250ミリ秒に低下します。この単一の変更だけで、他の最適化を行わなくてもLCPが「poor」から「good」に改善されることがよくあります。

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

ページビルダーの選択（または使用しないこと）は、WordPressのCore Web Vitalsに影響を与える最大のアーキテクチャ上の決定事項です。私の監査で一貫して見られるのは次のとおりです：

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

WordPressサイトからのCoreDashフィールドデータも同じことを物語っています。Gutenbergと軽量テーマで構築されたサイトは、一貫して2.0秒未満のモバイルLCP中央値を達成します。最適化前のElementorサイトは、通常3.8〜5.2秒のモバイルLCP中央値を示し、その差はほぼ完全に、追加のレンダリングブロックCSSとJavaScriptに起因します。最適化後（クリティカルCSS、遅延JS、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 load）しない（LCPを悪化させます）

JavaScriptとCSS

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

フォント

• Google Fontsをセルフホストする
• クリティカルなフォントファイルをプリロードする
• font-display: swapまたはoptionalを使用する
• フォントファミリーを最大2つに制限する

モニタリング

• CoreDash Real User Monitoringを設定してフィールドデータを継続的に追跡する
• Google Search ConsoleのCore Web Vitalsレポートを毎週監視する
• テーマの更新、プラグインの変更、またはコンテンツの更新後に毎回再テストする

すべての最適化領域をカバーするクロスプラットフォームの完全なチェックリストについては、究極のCore Web Vitalsチェックリストをご覧ください。

WordPressでのCore Web Vitalsの測定

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

• Google Search Console: 実際のCrUXフィールドデータに基づいて、サイト全体でどのページが合格または不合格であるかを示します。「エクスペリエンス」の下にある「Core Web Vitals」レポートを確認してください。
• PageSpeed Insights: フィールドデータ（CrUX）とラボデータ（Lighthouse）の両方で個々のURLをテストします。これを使用して特定のページを診断します。
• CoreDash: ページ、デバイス、国、および個々の要素ごとに分類されたリアルタイムのフィールドデータを提供するReal User Monitoring（RUM）です。CrUXの28日間のローリングウィンドウとは異なり、CoreDashは変更による即時の影響を示します。
• Chrome DevTools: Performanceパネルを使用してINPをブロックしている長いタスクを特定し、Coverageタブを使用して未使用のJavaScriptやCSSを見つけます。

これらのツールの完全な比較については、測定ツールの比較表が含まれているCore Web Vitalsの概要をご覧ください。

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

何百ものWordPressサイトを監査してきた私の経験から、最もよく目にする間違いは以下のとおりです：

• LCP画像の遅延読み込み（lazy loading）。WordPressはデフォルトで画像にloading="lazy"を追加します。ヒーロー画像がLCP要素である場合、それを遅延読み込みすると読み込みが遅れます。LCP画像が遅延読み込みから除外され、fetchpriority="high"が設定されていることを確認してください。
• 最適化プラグインが多すぎる。WP Rocket、Autoptimize、LiteSpeed Cache、およびW3 Total Cacheを同時にインストールすると、競合が発生します。1つのキャッシュ/最適化プラグインを選び、適切に設定してください。
• フィールドデータの無視。Lighthouseのスコアが95であることは、Core Web Vitalsに合格していることを意味しません。Googleは実際の訪問者からのフィールドデータを使用します。実際のデバイスを使用する実際の訪問者は、まったく異なるエクスペリエンスを経験する可能性があります。常にSearch Consoleを確認するか、RUMを使用してください。
• アップデート後のテストを怠る。テーマやプラグインのアップデートにより、知らないうちにCore Web Vitalsが悪化する可能性があります。初期の最適化後だけでなく、継続的に監視してください。