訪問者が WordPress ホームページにアクセスし、待機します。サーバーは PHP をスピンアップし、データベースに 17 回クエリを実行し、テーマ関数を実行し、プラグインフックをロードし、DOM をレンダリングし、最後にテキストを描画します — クリックから 2.8 秒後。すでに 3 つのキャッシングプラグインをインストール済みです。LCP は 3.1 秒のままで、CLS はフォント交換時にレイアウトを変更し、Google Search Console は同じ Core Web Vitals の失敗を報告し続けています。問題はホスティングや CDN ではありません。WordPress は 2003 年にすべてのリクエストで PHP サーバーサイドレンダリングを使ってブログ投稿をレンダリングするために設計されました。20 年後、同じランタイムでマーケティングサイト、e-コマースプラットフォーム、Web アプリをパワーアップするよう求められています — Google の Core Web Vitals アルゴリズムがあなたのコンテンツを誰もが見つけるかどうかを決定している間に。プラグインは実行モデルを書き直すことはできませんが、Next.js マイグレーションは可能です。何が壊れているのか、そして何がそれを正確に修正するのかの技術的な内訳を次に示します。

この記事では、WordPress サイトが遅い理由を正確に分解し、各問題を影響を受ける Core Web Vitals メトリクスにマップし、ヘッドレス Next.js アーキテクチャでそれらをどのように根本で修正するかを示します。バンドエイドではなく、根本で。

目次

Why Your WordPress Site Is Slow and How Next.js Fixes It

2026 年の Core Web Vitals を理解する

Google は 2024 年 3 月に Core Web Vitals を更新し、First Input Delay（FID）を Interaction to Next Paint（INP）に置き換えました。この変更はほとんどの人が気付くより重要です。サイトのパフォーマンスグレードを決定する 4 つのメトリクスを次に示します。

メトリクス 測定対象 良好 改善が必要 不良
LCP（Largest Contentful Paint） メインコンテンツがどれだけ速くロードするか ≤ 2.5s 2.5s – 4.0s > 4.0s
INP（Interaction to Next Paint） ユーザーインプットへの応答性 ≤ 200ms 200ms – 500ms > 500ms
CLS（Cumulative Layout Shift） ロード中のビジュアル安定性 ≤ 0.1 0.1 – 0.25 > 0.25
TTFB（Time to First Byte） サーバーレスポンス時間 ≤ 800ms 800ms – 1800ms > 1800ms

2026 年初頭の Chrome UX Report によると、すべての 3 つの Core Web Vitals 閾値を通過する WordPress オリジンはわずか 42% です。Next.js を搭載したオリジンの 67% と比較してください。これは限定的な違いではありません — 異なるリーグです。

これらのメトリクスが実際に重要な理由

Google は明確にしています：Core Web Vitals はランキング信号です。しかし SEO を超えて、これらのメトリクスはコンバージョン率と直接関連しています。Vodafone は LCP が 31% 改善されると売上が 8% 増加することを発見しました。Shopify の内部データは、ページロード時間が 100ms 削減されるたびにコンバージョンが 1.3% 増加することを示しています。

あなたの WordPress サイトは単に遅いだけではありません。それはあなたからお金を失わせています。

WordPress がアーキテクチャ的に遅い理由

誰かが典型的な WordPress ページにアクセスするときに何が起こるかをお見せします。

  1. DNS ルックアップ → ドメインを解決します
  2. TCP/TLS ハンドシェイク → セキュアな接続を確立します
  3. リクエストがサーバーにヒット → Apache/Nginx がそれを受け取ります
  4. PHP が WordPress をブートストラップ → wp-config.php をロード、WordPress コアを初期化
  5. プラグイン初期化 → すべてのアクティブなプラグインが init、wp_loaded などにフックします
  6. テーマがロード → functions.php が実行、テンプレート階層が解決
  7. データベースクエリが実行 → WP_Query が実行、多くの場合 30-100+ クエリ
  8. PHP が HTML をレンダリング → テンプレートファイルがページ全体を生成
  9. HTML がブラウザに送信 → 最後に、レスポンスが開始
  10. ブラウザが HTML を解析 → CSS、JS、フォント、画像を検出
  11. レンダリングをブロックするリソースがロード → 15 個の異なるプラグインからのスタイルシート
  12. ページが最後にレンダリング → ユーザーがコンテンツを見ます

ステップ 4 ～ 9 は、キャッシュされていないすべてのリクエストで発生します。これは 200 以上のファイルを解析し、数十のデータベースクエリを実行し、HTML を生成する PHP です — ブラウザが単一のバイトを取得する前に。

PHP の問題

PHP 8.3 は PHP 7.x よりはるかに高速で、ほとんどの WordPress ホストが現在それをサポートしています。しかし PHP 8.3 と OPcache が有効になっていても、同期的でブロッキングプロセスを実行しています。WordPress コア単独は、すべてのリクエストで約 100,000 行の PHP コードをロードします。WooCommerce を追加すると 400,000 行を超えます。

ここで重要なのは：WP Super Cache や W3 Total Cache などのキャッシングプラグインは、このプロセスをショートサーキットして — 事前生成された HTML ファイルを代わりに提供することで動作します。しかし、それら自体が複雑さを導入し、パーソナライズされたコンテンツで破損し、ブラウザで何が起こるかを修正することもできません。

テーマの問題

ほとんどの WordPress テーマはパフォーマンスではなく柔軟性のために構築されています。Avada、Divi、または Elementor のようなテーマは、それらの機能を使用しているかどうかに関係なく、すべてのページで CSS と JavaScript フレームワーク全体をロードします。Elementor サイトでは、単純なブログ投稿で 2.5MB の CSS と 1.8MB の JavaScript をロードしているのを見たことがあります。

<!-- ページビルダーサイトの典型的な WordPress head -->
<link rel="stylesheet" href="/wp-content/plugins/elementor/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/plugins/elementor-pro/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/style.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/theme.min.css">
<link rel="stylesheet" href="/wp-content/plugins/contact-form-7/includes/css/styles.css">
<link rel="stylesheet" href="/wp-content/plugins/woocommerce/assets/css/woocommerce.css">
<!-- ... 12 個以上のスタイルシート -->

それぞれはレンダリングをブロックするリソースです。すべてのダウンロードと解析まで LCP は発生できません。

プラグイン肥満化：サイレントパフォーマンスキラー

平均的な WordPress サイトは 20-30 個のプラグインを実行します。70+ のサイトを見たことがあります。各プラグインは次の可能性があります。

  • 独自の CSS と JS ファイルを追加（多くの場合、使用されていない場所でもすべてのページで）
  • WordPress フックを登録してすべてのリクエストで実行
  • 独自のデータベースクエリを実行
  • ブートストラップフェーズ中に独自の PHP ファイルをロード
  • <head> にインラインスクリプトとスタイルを追加

実際の例

最近、34 個のアクティブなプラグインが実行されている WordPress で構築されたマーケティングサイトを監査しました。ネットワークウォーターフォールは次のようになっていました。

  • 47 個の CSS ファイル がホームページにロード
  • 38 個の JavaScript ファイル がホームページにロード
  • 総ページ重量：4.7MB
  • 総リクエスト数：127
  • LCP：4G で 6.8 秒
  • TTFB：2.1 秒

クライアントは既に最適化プラグイン（Autoptimize）とキャッシングプラグイン（LiteSpeed Cache）をインストール済みでした。両方がアクティブでも、LCP は 4.2 秒でした。まだ失敗中です。

コアの問題は、不要なコードをロードすることを最適化して解決することはできないということです。47 個の CSS ファイルを最小化して結合しても、レンダリングをブロックする大規模な CSS ペイロードが残ります。

プラグイン依存関係のトラップ

ここでこれが悪化する理由があります：プラグインは他のプラグインに依存しています。WooCommerce をインストールすると、支払いゲートウェイプラグインが必要になり、その後配送計算機プラグイン、その後製品フィルタープラグインが必要になります。それぞれ重みを追加します。機能を破損させずに削除することはできません。

これが WordPress トラップです。アーキテクチャはすべてにプラグインを追加することをお勧めし、使用されていないコードをツリーシェイクするメカニズムがありません。

Why Your WordPress Site Is Slow and How Next.js Fixes It - architecture

プラグインが修正できないデータベースクエリの問題

WordPress は単一の MySQL データベースを使用し、悪名高いフラットスキーマを使用しています。wp_options テーブルは、すべてのリクエストで autoload='yes' エントリが満たされています。3,000 個以上の自動ロード行があり、8MB のデータを合計した wp_options テーブルを見ました。

-- 自動ロードされたオプションサイズを確認します
SELECT SUM(LENGTH(option_value)) as autoload_size 
FROM wp_options 
WHERE autoload = 'yes';

-- これが > 1MB を返す場合、問題があります

wp_postmeta テーブルは別のナイトメアです。すべてをキー値ペアとして保存するため、WordPress は効率的なクエリを行うことはできません。$50 未満のすべての製品を見つけたいですか？これは、テキストフィールドに数値として保存される文字列比較で wp_postmeta の JOIN です。インデックスはあなたを救うことはできません。

クエリ数の現実チェック

あなたの WordPress サイトに Query Monitor プラグインをインストールし、クエリ数を確認してください。「単純な」WooCommerce 製品ページは通常 150-300 のデータベースクエリを実行します。関連投稿、人気投稿サイドバー、パンくずを含むブログ投稿？通常 80-120 クエリです。

これを、Next.js フロントエンドが必要なすべてのデータを取得するために正確に 1 つの API 呼び出し（またはゼロ、静的生成を使用している場合）を行うヘッドレスアプローチと比較してください。

WordPress ホスティング：平凡さに過剰な料金を支払っている可能性

ホスティングについて話しましょう。これは多くのお金が無駄に使われている場所です。

ホスティングタイプ 月額料金 典型的な TTFB アーキテクチャを修正できますか？
共有（GoDaddy、Bluehost） $3-15 1.5-4.0s いいえ
マネージド WordPress（WP Engine、Flywheel） $25-300 400ms-1.2s いいえ
プレミアムマネージド（Kinsta、Pagely） $35-600 200ms-600ms いいえ
VPS/専用（DigitalOcean、AWS） $20-500 200ms-800ms いいえ
Next.js on Vercel/Edge $0-20 50-150ms はい

その最後の列に注目してください。ホスティングのアップグレードはアーキテクチャの問題を修正しません。PHP をより速く実行するために高額な料金を支払っているが、実際のソリューションはすべてのリクエストで PHP を実行しないことです。

Kinsta のスタータープランは 25,000 回の訪問で月額 $35 をチャージします。Vercel の無料ティアは 100GB の帯域幅を処理します。Vercel の Pro プランでさえ月額 $20 で、グローバル CDN 全体のエッジデプロイを提供します。数学は嘘をつきません。

Next.js が各 Core Web Vital を修正する方法

具体的には、次の通りです。Next.js（特に Next.js 14/15 の App Router を使用）各メトリクスにどのように対処するかです。

TTFB を修正する

Next.js は複数のレンダリング戦略を提供します。

// 静的生成 - TTFB は事実上ゼロ（CDN から提供）
export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);
  return <Article post={post} />;
}

// これはビルド時にプリレンダリングされます
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

静的生成では、ページは世界中のエッジ CDN ノードから提供される事前構築された HTML ファイルです。ユーザーがどこにいるかに関係なく、TTFB は 50-100ms に低下します。PHP 実行なし、データベースクエリなし、リクエスト時のサーバー側の処理なし。

動的コンテンツの場合、Next.js は ISR（Incremental Static Regeneration）をサポートしており、キャッシュされた静的ページをバックグラウンドで再検証しながら提供します。

// 60 秒ごとに再検証
export const revalidate = 60;

LCP を修正する

Next.js には、WordPress プラグインが（失敗して）試みるすべてを処理する <Image> コンポーネントが含まれています。

import Image from 'next/image';

export default function HeroBanner() {
  return (
    <Image
      src="/hero.jpg"
      alt="Hero banner"
      width={1200}
      height={600}
      priority // LCP 画像をプリロード
      sizes="100vw"
      // srcset を自動生成、WebP/AVIF を使用、
      // デフォルトで遅延ロード、CLS を防止
    />
  );
}

priority プロップは Next.js に画像をプリロードするよう指示し、直接 LCP を改善します。自動フォーマットネゴシエーションは、サポートされているブラウザーに WebP または AVIF を提供し、JPEG と比較して画像サイズを 30-50% 削減します。プラグインは必要ありません。

Next.js は CSS モジュールと自動的な重要な CSS 抽出を通じてレンダリングをブロックする CSS を削除します。特定のページで使用される CSS のみがロードされます。

INP を修正する

INP はサイトがユーザー操作にどれだけ速く応答するかを測定します。WordPress サイトが INP で失敗する理由は、

  • プラグインからの重い JavaScript がメインスレッドをブロック
  • jQuery とそのプラグインが実行時間を競う
  • コード分割なし — すべてが事前にロード

Next.js はこれを自動コード分割で処理します。各ページは必要な JavaScript のみをロードします。

// このコンポーネントはユーザーがそれまでスクロールするときのみロード
import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('@/components/HeavyChart'), {
  loading: () => <ChartSkeleton />,
  ssr: false, // サーバーで렌더리지 않음
});

React Server Components（App Router のデフォルト）はさらに先に行きます：インタラクティビティが必要ないコンポーネントはブラウザーに 0 JavaScript を送信します。インタラクティブ要素のないブログ投稿？ゼロ KB のコンポーネント JavaScript。

CLS を修正する

WordPress での CLS は通常、

  • 明示的な寸法のない画像
  • 遅く負荷が高く、コンテンツを押し下げる広告
  • FOUT/FOIT を引き起こす Web フォント
  • ロード後に表示されるプラグイン注入バナー

Next.js はデフォルトで CLS を防止します。<Image> コンポーネントは寸法が必要です（または fill を使用してサイズされたコンテナを使用）。next/font モジュールはフォント宣言をインライン化し、レイアウトシフトなしで font-display: swap を使用します。

import { Inter } from 'next/font/google';

const inter = Inter({ subsets: ['latin'] });

export default function RootLayout({ children }) {
  return (
    <html lang="en" className={inter.className}>
      <body>{children}</body>
    </html>
  );
}

FOUT なし。フォントからのレイアウトシフトなし。それは機能します。

ヘッドレスアーキテクチャ：CMS としての WordPress、フロントエンドとしての Next.js

多くの人が見逃しているパーツがあります：ヘッドレスに移動することは WordPress を放棄することを意味しません。それは WordPress を実際に得意としていること — コンテンツ管理 — に使用し、フロントエンドを Next.js に処理させることを意味します。

アーキテクチャは次のようになります。

[WordPress Admin] → [REST API / WPGraphQL] → [Next.js Frontend] → [Vercel Edge CDN]
     ↑                                              ↑
  コンテンツエディタ                          あなたのユーザーは
  なじみのある                                高速ページを取得
  WP ダッシュボードを使用                       エッジから提供

コンテンツチームはワークフローを保持します。ユーザーは高速サイトを取得します。きれいで保守可能なコードを取得します。

この種の作業は多くのことを行い、我々の Next.js 開発練習 と ヘッドレス CMS 開発 で行われます。パターンはよく確立されており、戦闘テストされています。

他のヘッドレス CMS オプションについては？

WordPress はコンテンツレイヤーの唯一のオプションではありません。ゼロから始める場合、Sanity、Contentful、Storyblok などの目的構築ヘッドレス CMS プラットフォームがしばしばより良い選択です。それらは API ファーストで構築されているため、レガシー荷物はありません。

しかし、WordPress に数年のコンテンツを持っており、そのためにトレーニングされたチームを持っている場合、WPGraphQL を備えたヘッドレス WordPress は完全に有効なアプローチです。

実際のパフォーマンスベンチマーク：WordPress vs Next.js

ここに、実施したマイグレーションおよび公開利用可能なケーススタディからの実際の数字があります。

| メトリクス | WordPress（最適化） | Next.js（静的） | 改善 | |--------|----------------------|-------------------|-------------|| | TTFB | 650ms | 80ms | 87% 高速 | | LCP | 3.8s | 1.2s | 68% 高速 | | INP | 380ms | 90ms | 76% 高速 | | CLS | 0.18 | 0.01 | 94% 改善 | | ページ重量 | 3.2MB | 450KB | 86% 軽い | | リクエスト | 85 | 12 | 86% 少ない | | Lighthouse スコア | 45-65 | 95-100 | 昼と夜 |

「最適化」WordPress は、PHP 8.3、Redis オブジェクトキャッシュ、CDN、画像最適化プラグイン、キャッシングプラグイン、データベース最適化を意味します。あなたがすることになっているすべてのもの。そしてそれはまだ近くはありません。

マイグレーションパス：モノリシック WordPress からヘッドレス Next.js へ

マイグレーションはすべてかなしかである必要はありません。推奨する段階的なアプローチは次のとおりです。

フェーズ 1：評価（1-2 週間）

  • PageSpeed Insights と CrUX データを使用して現在の WordPress サイトパフォーマンスを監査
  • すべてのプラグインをインベントリして、フロントエンド vs バックエンド機能にマップ
  • コンテンツモデルとカスタムフィールドを特定
  • WordPress をヘッドレス CMS として保持するか、完全にコンテンツを移行するかを評価

フェーズ 2：フロントエンドの構築（4-8 週間）

  • App Router で Next.js プロジェクトを設定
  • WordPress に WPGraphQL をインストールして構成
  • 現在のデザインに一致するコンポーネントライブラリを構築（または再設計 — これに適した時間）
  • コンテンツページの静的生成を実装
  • コンテンツエディタ向けのプレビューモードをセットアップ

フェーズ 3：起動とリダイレクト（1-2 週間）

  • Next.js フロントエンドを Vercel（または Netlify、または Cloudflare Pages）にデプロイ
  • DNS とリダイレクトを構成
  • すべての URL が正しくリダイレクトされることを確認（SEO 保存は重要）
  • WordPress 管理をロック（公開アクセスを削除）

フェーズ 4：最適化（継続中）

  • Google Search Console で Core Web Vitals を監視
  • ISR 再検証間隔を細かく調整
  • パーソナライゼーション用のエッジミドルウェアを追加
  • WordPress がボトルネックになった場合、目的構築ヘッドレス CMS への移行を検討

この種のマイグレーションを検討している場合、料金ページ で概算番号を確認できます。または、直接お問い合わせください。特定の状況について説明します。

Astro を使用して構築されたサイト（特にコンテンツが豊富なブログとマーケティングサイト）では、Next.js ではなく Astro 開発練習 も持っているため、静的優先サイトのためにさらに積極的なパフォーマンスを提供します。

FAQ

Next.js に切り替えずに WordPress を高速化できますか？

はい、ある程度。品質ホスト（Kinsta または Cloudways）で開始し、Redis オブジェクトキャッシュを有効にし、GeneratePress のような軽量テーマを使用し、プラグインを 15 個以下に削減し、CDN を構成します。このようにして WordPress サイトを Core Web Vitals の「改善が必要」範囲に取得できます。しかし、すべてのメトリクス — 特に INP — で「良好」範囲に一貫して突破することは、従来の WordPress アーキテクチャで非常に困難です。

WordPress からヘッドレス Next.js へマイグレーションするコストはどのくらいですか？

サイトの複雑さによります。単純なマーケティングサイト（10-30 ページ、ブログ）は通常 $15,000-$40,000 で完全なマイグレーションを実行します。WooCommerce を備えた e-コマースサイトは、より関連しており、$50,000-$150,000+ の範囲です。ROI は通常、改善されたコンバージョン率と削減されたホスティングコストから来ます。料金ページ により詳細があります。

Next.js に切り替えると SEO ランキングが低下しますか？

マイグレーションを正しく処理すれば、いいえ。適切な 301 リダイレクト、同一の URL 構造（またはマップされたリダイレクト）、有効なメタタグ、構造化されたデータ、および XML サイトマップはすべて必須です。Next.js は実際に SEO 利点を備えています — より高速な Core Web Vitals は直接ランキングを改善し、Metadata API は プログラムでメタタグを管理しやすくします。ほとんどのサイトは、マイグレーション後 2-3 か月でランキング改善を見ます。

ヘッドレスに移動した場合、コンテンツエディターは WordPress 管理を失いますか？

いいえ。ヘッドレスセットアップでは、WordPress はコンテンツ管理バックエンドとして機能し続けます。エディタは同じダッシュボード、同じエディタ、同じワークフローを使用します。彼らは単にフロントエンドテーマをもう見ないだけです — 代わりに、Next.js レンダリングバージョンを表示するプレビューボタンを使用します。一部のチームはこれが実際により良いことが分かります。プレビューがプロダクションサイトの正確な表現だからです。

WooCommerce について — Next.js は e-コマースを処理できますか？

はい、ただしそれはより大きなプロジェクトです。REST API または WPGraphQL WooCommerce 拡張機能を使用して WooCommerce をヘッドレスで使用できます。あるいは、多くのチームは Shopify の Storefront API または Saleor に移行し、Next.js をフロントエンドとして使用します。チェックアウトフローは、支払い処理と PCI コンプライアンスを含むため、慎重な処理が必要です。できますが、追加の開発時間を計画してください。

Next.js が高速フロントエンドの唯一の選択肢ですか？

いいえ。Astro、Remix、SvelteKit、さらには Nuxt（Vue チーム用）はすべて実行可能です。Astro は特にコンテンツが豊富なサイトで優れています。デフォルトでゼロ JavaScript を出荷するため。Next.js は、大量の相互性、動的機能、または e-コマースが必要なサイトで優勝します。プロジェクトの必要性に応じて Next.js と Astro の両方で作業します。

Incremental Static Regeneration（ISR）は WordPress コンテンツでどのように機能しますか？

WordPress で投稿を公開または更新すると、Webhook が起動し、Next.js デプロイに特定のページを再検証するよう指示します。次のビジター取得は新たに生成された静的ページで、エッジでキャッシュされます。再検証はバックグラウンドで発生するため、ユーザーはビルドを待つことはありません。また、時間ベースの再検証（例：60 秒ごとにリビルド）をフォールバックとして設定することもできます。

ヘッドレスに移動するときにチームが犯す最大の間違いは何ですか？

WordPress サイトを Next.js で 1:1 で複製しようとしています。ヘッドレスマイグレーションは、コンテンツアーキテクチャを再考し、ページ構造を簡素化し、何年にも及ぶ蓄積された不良品を排除する機会です。古いテーマから各ウィジェットとサイドバーをコピーしようとするチームよりも、それを新規開始と見なすチーム — コンテンツを保持しながらプレゼンテーションを再考する — はるかに良い結果を達成します。