WordPress用CWV

3つのメトリクスは実訪問者の75パーセンタイルで測定される：LCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下。Googleはあなたの Lighthouse 実行からではなく、Chrome User Experience Report のフィールドデータからこれらを読み取るため、ラボスコアが良好であることは必要条件ですが十分条件ではない。

重要なポイント：WordPress は Core Web Vitals をクリアできるが、デフォルト設定があなたに対抗する：重いテーマ、プラグインの乱立、最適化されていないメディア。まずメディアとキャッシュを修正し、次にプラグインを削減し、ラボスコアではなくフィールドデータで検証する。

• 重いテーマとページビルダー。Elementor や Divi のような多目的テーマとビルダーは大きな CSS と JavaScript バンドルを配布するが、そのほとんどはどのページでも使われていない。
• プラグインの過剰導入。アクティブなプラグインはそれぞれ独自のスクリプトとスタイルをサイト全体に追加できます。そのプラグインを使用していないページでも同様です。
• 最適化されていないメディア。メディアライブラリはアップロードされたファイルをそのまま配信します。WebP対応やサイジングがない大きなヒーロー画像が最も一般的なLCP低下の原因です。
• デフォルトではキャッシュがない。ストック状態のWordPressはリクエストのたびにPHPをレンダリングします。ページキャッシュがないと、負荷がかかったときにTTFBが悪くなります。

インパクトの順序：ページキャッシュとCDNを追加する。画像を最適化して正しくサイジングする（WebP、遅延読み込み）。テーマとプラグインのJavaScriptを削減する。TTFBを低く保つインフラでホストする。優れた[マネージドホストまたはVPS](/blog/best-vps-for-wordpress-2026/)はどのプラグインよりもTTFBを大きく改善します。ビルドが重くてこれら全てでも不十分な場合、それは[Astroを使ったHeadless WordPress](/blog/headless-wordpress-astro-setup/)の検討を示唆しており、フロントエンドの負荷が完全になくなります。

実践的なサービス版は[WordPress高速化](/wordpress-speed-optimization/)ページを参照。プラットフォームに依存しないリストは[Core Web Vitalsチェックリスト](/guides/cwv-checklist/)を参照してください。

• キャッシュプラグインを3つインストールする。競合します。1つのページキャッシュプラグインを選択する（またはキャッシュが組み込まれたホストを使用する）か、やめる。
• 手動で画像を最適化して、終わり。新しいアップロードがそれを台無しにします。アップロードするたびにWebPに変換してサイジングするプラグインかパイプラインを使用してください。
• Lighthouseで100を目指す。これは研究用ツールです。Search Consoleレポートと実際のデータがランキングを決めます。
• パフォーマンスプラグインを原因を取り除かずに追加するのは、膨れ上がったビルダーの上に絆創膏を貼るようなもの。本当の修正ではない。まず肥大化を削ぎ落とせ。

ラボスコアだけを報告するものは何もインストールするな。PageSpeed InsightsのフィールドセクションとSearch Consoleのコアウェブバイタルレポート、どちらも実ユーザーのデータを読んでいるものを使え。修正後、フィールドデータが変化を完全に反映するには約28日かかるから、翌朝スコアが動かなくてもパニックになるな。単日の数値ではなく数週間のトレンドを追い、フィールドデータが修正を確認してからはじめて完了と呼べ。