WordPressのCore Web Vitals — 主要CMS最下位が意味するSEOへの影響

Core Web Vitals（CWV）は、Googleが2021年に導入したページ体験の評価指標です。「ページが速いかどうか」ではなく「ユーザーがページを使う体験が良いかどうか」を3つの数値で測ります。

3つの指標をビジネス言語で理解する

LCP（Largest Contentful Paint）は、メインコンテンツが画面に表示されるまでの時間です。2.5秒以内が合格基準で、これを超えると「遅いサイト」としてGoogleの評価が下がります。ユーザーは「ページが読み込まれている」と感じる前に離脱します。

INP（Interaction to Next Paint）は、ボタンをクリックしたり、フォームを入力したりしたときの応答速度です。200ms以内が合格基準です。「クリックしたのに何も起きない」という感覚が、直帰率を押し上げます。

CLS（Cumulative Layout Shift）は、読み込み中にコンテンツが突然ズレる現象です。0.1以下が合格基準で、「読もうとしたら広告が現れてテキストが下にずれた」という体験がこれに該当します。スマートフォンで誤タップが増える主因でもあります。

ビジネスへの影響はどれほど深刻なのか？

これらは単なる技術指標ではありません。2025年の調査によると、Core Web VitalsはGoogleランキングアルゴリズムの10〜15%のウェイトを持ちます。さらに、CWV最適化によってコンバージョンが最大20%向上したという分析結果も報告されています（Magnet 2025 CWV分析）。

逆の面では、ページ読み込みが1秒から10秒に増えると、ユーザーの離脱確率が123%増加します。サイトの速度は「ユーザーエクスペリエンスの問題」ではなく「売上に直結するビジネスの問題」です。

2025年のCore Web Vitals合格率は43.44%です（Search Engine Journal）。年初の42.58%から4月の44.93%まで一時的に上昇しましたが、その後再び下落しました。1年間ほぼ横ばいで、構造的な改善は起きていません。

WordPressが遅い理由は一つではありません。複数の構造的要因が積み重なっています。

1. プラグインの重量化

WordPressの強みはプラグインのエコシステムです。しかし、プラグインを追加するたびに、ページ読み込み時に実行されるJavaScriptとCSSが増えます。10個のプラグインをインストールしたサイトは、10倍の「重さ」を抱えていることもあります。プラグインの多くは「必要な機能を提供する」ために設計されており、「軽量であること」を優先して設計されていません。

2. テーマの設計思想

WordPressテーマの多くは「あらゆるカスタマイズに対応する」ために設計されています。その結果、使わないスタイルシートやスクリプトが読み込まれ、ページが肥大化します。特に「多機能テーマ」と呼ばれる人気テーマは、使う機能が全体の20%であっても、残り80%のコードも読み込まれます。

3. レンタルサーバーの制約

WordPressサイトの大多数は、共有レンタルサーバーで動作しています。共有サーバーはコスト効率が高い一方、隣のサイトのトラフィックが自分のサイトの速度に影響する「お隣さん問題」があります。PHPの処理速度とデータベースの応答時間が、共有リソースによって制限されます。

4. 動的なDB処理

WordPressはページを表示するたびにデータベースへのクエリを実行します。キャッシュが適切に設定されていないと、アクセスのたびに同じクエリを繰り返し実行し、サーバーに負荷をかけます。

注目すべきは、競合3社がいずれもWordPressを上回っているという事実です。Shopify・Wix・Squarespaceの共通点は「プラットフォームがインフラを管理する」モデルであることです。WordPressは「ユーザーがすべてを管理する」モデルです。

「管理の自由度」は「最適化の責任」とセットです。ほとんどのWordPressユーザーは、この責任を引き受けるリソースを持っていません。

Elementor・Divi・WPBakery・Gutenbergの高度な利用など、ビジュアルビルダーはWordPressのコンテンツ編集を視覚的に直感的にします。しかし、この利便性はパフォーマンスのコストを伴います。

ビジュアルビルダーが生成するHTMLは、手書きのコードと比較して「冗長」です。1つのセクションを表示するために、本来必要な要素の3〜5倍のHTMLタグが生成されることがあります。複雑なDOM構造はブラウザの描画処理を遅らせ、LCPを悪化させます。

また、ビジュアルビルダーはそれ自体が重いJavaScriptライブラリを読み込みます。Elementorを使用しているだけで、ページは何も設定していない状態よりも重くなります。CLS（レイアウトシフト）もビジュアルビルダー利用サイトで多発します。これはビルダーが「後からスタイルを適用する」仕組みを採用していることが多いためです。

「ページを美しく作れる」と「ページが速く表示される」は、WordPressのビジュアルビルダーにおいては相反する目標になりがちです。

WP Rocket・LiteSpeed Cache・W3 Total Cacheなどのキャッシュ・最適化プラグインは確かに効果があります。適切に設定すれば、LCPを0.5〜1秒改善できることもあります。

しかし、これらはあくまで「症状の緩和」です。

最適化プラグインができること：

• 静的ファイルのキャッシュ
• 画像の遅延読み込み
• CSSとJavaScriptのミニファイ（圧縮）
• CDN連携

最適化プラグインができないこと：

• テーマの構造的な冗長性の除去
• 不要なプラグインが生成するコードの削除
• WordPressのDB処理アーキテクチャの変更
• ビジュアルビルダーが生成する複雑なDOM構造の簡素化

WP Rocketを使っても43%のWordPressサイトしかCWVを通過しない現実が、この限界を示しています。プラグインで最適化を試みているサイトが大多数を占めるにもかかわらず、合格率はほぼ改善されていません。

最適化プラグインは「遅いサイトを少し速くする」ことはできます。しかし「構造的に速いサイト」を作ることはできません。

OS iXanagiのWebsite RuntimeはNext.js 14 App Router + SSR（サーバーサイドレンダリング）で構築されています。この設計は、Core Web Vitalsへの対応を「後から最適化する」ではなく「最初から設計に組み込む」アプローチを取っています。

Next.js SSRによるLCP改善

サーバーサイドレンダリングでは、サーバーが完成したHTMLをブラウザに送ります。ブラウザはJavaScriptを実行してコンテンツを構築する必要がなく、受け取ったHTMLをそのまま表示します。LCPの多くはJavaScriptの処理待ちで発生しますが、SSRはこの待ち時間を構造的に排除します。

Meaning ObjectsによるCLS防止

OS iXanagiのMeaning Objectsは、コンテンツの構造（どこにどのサイズのコンテンツが入るか）をデータとして管理します。レイアウトはコンテンツが届く前に確定しており、読み込み中のレイアウトシフトが発生しません。CLSがゼロに近い状態が構造的に実現されます。

軽量Runtimeによるパフォーマンス

OS iXanagiのWebsite Runtimeは、特定の表示用途に最適化された軽量なNext.jsアプリケーションです。WordPressのように「あらゆるユースケースに対応する」コードベースではなく、「必要なものだけを持つ」設計です。

なお、WordPressのAIO対応とCWV最適化の関係については、このシリーズの次の記事（#5）でさらに詳しく解説しています。プラグインを使ったAIO対応が構造的な問題を解決できない理由を具体的に分析しています。

Q1. Core Web VitalsはGoogleランキングにどれほど影響しますか？

2025年現在、Core Web VitalsはGoogleランキングアルゴリズムの10〜15%のウェイトを持ちます。単独の指標としては、コンテンツの質や被リンクほど大きくありませんが、僅差の競合サイトとの差をつける要因になります。特にニッチ市場では、コンテンツ品質が同程度のライバルサイトとの勝負でCWVが決め手になるケースが報告されています。

Q2. WordPressでCore Web Vitalsを合格させることはできますか？

不可能ではありません。高速なホスティング、最小限のプラグイン構成、軽量テーマ、適切なキャッシュ設定、CDNを組み合わせれば、合格水準に達することは可能です。ただし、その状態を維持することが難しく、新しいプラグインを追加するたびに最適化の作業が必要になります。構造的に有利な立場からスタートできるプラットフォームと比較すると、常に「泳ぎ続けなければならない」状況が続きます。

Q3. モバイルとデスクトップ、どちらが重要ですか？

Googleはモバイルファーストインデックスを採用しており、モバイルのCWVスコアがランキングの基準になります。WordPressがとりわけ弱いのはモバイルのCWVです。Shopify・Wix・SquarespaceがモバイルでいずれもWordPressを上回っているという事実は、「モバイルユーザーが多い市場でWordPressを使うコスト」を示しています。

Q4. 最適化の費用対効果はどう考えればいいですか？

WordPress最適化のコンサルティング費用は、状況によりますが数十万円から始まります。そして最適化は一度やれば終わりではなく、サイトを更新するたびに維持が必要です。CWV最適化でコンバージョンが最大20%向上するというデータがある一方、その最適化を維持するコストを計算に入れる必要があります。初期コストだけでなく、維持コストと機会損失コスト（CWVが悪いことで失っているコンバージョン）を合わせた総コストで判断することをお勧めします。

Q5. Headless CMSへの移行はCore Web Vitals改善に効果がありますか？

効果があります。Headless CMSはコンテンツ管理とフロントエンドを分離し、Next.jsなどのモダンフレームワークで表示を担当させることができます。これによりSSRを活用でき、WordPressの構造的なパフォーマンス問題を根本から解決できます。Enterpriseがこの選択をしている理由の一つです（この点はシリーズ#6で詳しく解説します）。

CWVの問題は最適化プラグインでは解決しません。アーキテクチャで解決します。

OS iXanagiのWebsite RuntimeはNext.js 14 SSRで設計されており、Core Web Vitalsへの対応が最初から組み込まれています。プラグインの積み重ねで遅くなる構造ではなく、必要なものだけを持つ軽量なRuntimeがパフォーマンスを実現します。

WordPressのCWVスコアで悩んでいる方へ: 現在のサイトのCWVスコアと、OS iXanagi移行後の見込みを無料で分析します。

OS iXanagiについて詳しく見る →

• Search Engine Journal, "WordPress Core Web Vitals Pass Rate 43.44% (2025)"
• Magnet, "2025 Core Web Vitals Analysis: CWV Optimization and Conversion Rate Impact"
• Google, "Core Web Vitals Report Documentation (2025)"
• Kinsta, "WordPress Usage Statistics 2025"
• Think with Google, "The Need for Mobile Speed: How Mobile Latency Impacts Publisher Revenue (updated 2025)"
• Afteractive, "CMS Market Share Data 2022–2025"