WordPressサイトが遅い理由とNext.jsでの解決方法
ここまでのコンテンツを日本語に翻訳します
数年間にわたって数百のWordPressサイトを監査してきましたが、会話はいつも同じ方法で始まります：「キャッシングプラグインをインストールしたのに、スコアは相変わらずひどいです。」WordPressエコシステムの誰もが認めたくない事実は、ほとんどのパフォーマンスの問題はプラグインでは解決できないということです。それらはアーキテクチャに関するものなのです。WordPressは2003年にブログ記事をPHPでレンダリングするために構築されました。2025年となった今、私たちはそれに対して複雑なマーケティングサイト、eコマースプラットフォーム、Webアプリケーションを駆動させようとしています。その一方で、GoogleのCore Web Vitalsはあなたのコンテンツが実際に見つかるかどうかをますます決定しています。
この記事では、WordPressサイトが遅い理由を正確に分析し、各問題をCore Web Vitalsメトリクスにマッピングしてから、ヘッドレスNext.jsアーキテクチャがそれらを根本から解決する方法を示します。一時的な修正ではなく、根本的に解決します。
目次
- 2025年のCore Web Vitalsの理解
- WordPressがアーキテクチャ的に遅い理由
- プラグインの肥大化：サイレント性能キラー
- プラグインでは修正できないデータベースクエリの問題
- WordPressホスティング：あなたはおそらく平凡さに過剰に支払っています
- 各Core Web VitalをNext.jsがどのように修正するか
- ヘッドレスアーキテクチャ：CMSとしてのWordPress、フロントエンドとしてのNext.js
- 実際のパフォーマンスベンチマーク：WordPressとNext.js
- マイグレーションパス：モノリシックWordPressからヘッドレスNext.jsへ
- FAQ
2025年のCore Web Vitalsの理解
Googleは2024年3月にCore Web Vitalsを更新し、First Input Delay（FID）をInteraction to Next Paint（INP）に置き換えました。この変更は、ほとんどの人が気づくよりもはるかに重要です。サイトのパフォーマンスグレードを決定する4つのメトリクスは以下の通りです：
| メトリクス | 測定内容 | 良好 | 改善が必要 | 不良 |
|---|---|---|---|---|
| LCP（Largest Contentful Paint） | メインコンテンツの読み込み速度 | ≤ 2.5秒 | 2.5秒～4.0秒 | > 4.0秒 |
| INP（Interaction to Next Paint） | ユーザー入力への応答性 | ≤ 200ミリ秒 | 200ミリ秒～500ミリ秒 | > 500ミリ秒 |
| CLS（Cumulative Layout Shift） | 読み込み時の視覚的安定性 | ≤ 0.1 | 0.1～0.25 | > 0.25 |
| TTFB（Time to First Byte） | サーバー応答時間 | ≤ 800ミリ秒 | 800ミリ秒～1800ミリ秒 | > 1800ミリ秒 |
2025年初頭のChrome UXレポートによると、WordPressオリジンのわずか42％が3つのCore Web Vitalsしきい値すべてに合格しています。Next.jsで動作するオリジンの67％と比較してください。これは限定的な違いではなく、完全に異なるリーグです。
これらのメトリクスが実際に重要な理由
Googleは明確に述べています：Core Web Vitalsはランキング信号です。ただしSEOの観点を超えて、これらのメトリクスは直接コンバージョン率と相関しています。Vodafoneは、LCPの31％の改善が売上8％の増加につながったことを発見しました。ShopifyのInternal dataでは、ページ読み込み時間の100ミリ秒削減がコンバージョンを1.3％増加させることを示しています。
あなたのWordPressサイトは単に遅いだけではありません。それはあなたからお金を失わせています。
WordPressがアーキテクチャ的に遅い理由
典型的なWordPressページを訪問する際に何が起こるかを説明します：
- DNSルックアップ → ドメインを解決します
- TCP/TLSハンドシェイク → セキュア接続を確立します
- リクエストがサーバーに到達 → Apache/Nginxがそれを受け取ります
- PHPがWordPressをブートストラップ →
wp-config.phpを読み込み、WordPressコアを初期化します - プラグインの初期化 → すべてのアクティブプラグインが
init、wp_loadedなどにフックします - テーマの読み込み →
functions.phpが実行され、テンプレート階層が解決されます - データベースクエリが実行 → WP_Queryが実行され、通常1ページあたり30～100以上のクエリが実行されます
- PHPがHTMLをレンダリング → テンプレートファイルが完全なページを生成します
- HTMLがブラウザに送信 → ようやく応答が開始されます
- ブラウザがHTMLを解析 → CSS、JS、フォント、画像を発見します
- レンダリングをブロックするリソースが読み込まれます → 15個の異なるプラグインからのスタイルシート
- ページが最終的にレンダリングされます → ユーザーがコンテンツを表示します
ステップ4～9はキャッシュされていないリクエストごとに発生します。これはPHPが200以上のファイルを解析し、数十のデータベースクエリを実行し、HTMLを生成することを意味します。ブラウザが単一のバイトを取得する前に。
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フレームワークを読み込みます。シンプルなブログ投稿で2.5MBのCSSと1.8MBのJavaScriptを読み込んでいるElementorサイトを見たことがあります。
<!-- ページビルダーサイト上の典型的な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のトラップです。アーキテクチャはすべてのためにプラグインを追加することを奨励し、未使用のコードをツリーシェイクするメカニズムはありません。
プラグインでは修正できないデータベースクエリの問題
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テーブルはもう1つの悪夢です。それはすべてをキー値ペアとして保存し、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.0秒 | いいえ |
| 管理されたWordPress（WP Engine、Flywheel） | $25-300 | 400ミリ秒-1.2秒 | いいえ |
| プレミアム管理（Kinsta、Pagely） | $35-600 | 200ミリ秒-600ミリ秒 | いいえ |
| VPS/専用（DigitalOcean、AWS） | $20-500 | 200ミリ秒-800ミリ秒 | いいえ |
| Vercel/EdgeのNext.js | $0-20 | 50-150ミリ秒 | はい |
最後の列に注目してください。ホスティングのアップグレードはアーキテクチャの問題を修正しません。PHPをより高速に実行するためにプレミアム価格を支払っています。実際の解決策は、すべてのリクエストでPHPを実行しないことです。
Kinstaのスタータープランには25,000訪問で月額$35の料金がかかります。Vercelの無料ティアは100GBの帯域幅を処理できます。Vercelの月額$20のProプランでさえ、グローバルCDN全体のエッジ配置を提供します。計算は嘘をつきません。
各Core Web VitalをNext.jsがどのように修正するか
具体的になりましょう。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 }));
}
静的生成を使用すると、ページは事前構築されたHTMLファイルとして世界中のエッジCDNノードから提供されます。ユーザーがどこにいるかに関わらず、TTFBは50～100ミリ秒に低下します。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のデフォルト）はさらに進みます：相互作用を必要としないコンポーネントはブラウザにゼロ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とNext.js
以下は、実施した移行と公開されている事例研究からの実数です：
| メトリクス | WordPress（最適化） | Next.js（静的） | 改善 |
|---|---|---|---|
| TTFB | 650ミリ秒 | 80ミリ秒 | 87％高速 |
| LCP | 3.8秒 | 1.2秒 | 68％高速 |
| INP | 380ミリ秒 | 90ミリ秒 | 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サイトのパフォーマンスを監査
- すべてのプラグインをインベントリし、フロントエンド対バックエンド機能にマッピング
- コンテンツモデルとカスタムフィールドを特定
- 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（特にコンテンツが豊富なブログとマーケティングサイト用）で構築されたサイトでは、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レンダリングされたバージョンを表示するプレビューボタンを使用します。いくつかのチームはこれが実は更に良いと判断しています。なぜなら、プレビューが本番サイトの正確な表現だからです。
Next.jsはWooCommerceを処理できますか — eコマースですか？ はい、ただしそれはより大きなプロジェクトです。WooCommerceをREST APIまたはWPGraphQL WooCommerce拡張経由でヘッドレスに使用できます。代わりに、多くのチームはShopifyのStorefront APIまたはSaleorをコマースバックエンドに移行し、Next.jsをフロントエンドとして使用します。チェックアウトフローには支払い処理とPCI準拠が関連するため、注意深い処理が必要です。それは可能ですが、追加の開発時間を計画してください。
Next.jsは高速フロントエンドの唯一のオプションですか？ いいえ。Astro、Remix、SvelteKit、さらにはNuxt（Vueチーム用）はすべて実行可能です。特にAstroはコンテンツが豊富なサイトに優れています。これはデフォルトでゼロJavaScriptを出荷するためです。Next.jsは、重要な相互作用、動的機能、またはeコマースを必要とするサイトで優勝します。我々はプロジェクトのニーズに応じてNext.jsとAstroの両方で動作します。
WordPressコンテンツでIncremental Static Regeneration（ISR）がどのように機能しますか？ WordPressで投稿を公開または更新すると、Webhookが発火してあなたのNext.js配置に特定ページを再検証するよう指示します。次の訪問者は新しく生成された静的ページを取得し、エッジでキャッシュされます。再検証はバックグラウンドで発生するため、ユーザーはビルドを待つ必要がありません。時間ベースの再検証（例：60秒ごとに再構築）をフォールバックとして設定することもできます。
ヘッドレスになるときにチームが犯す最大の間違いは何ですか？ 彼らのWordPressサイトをNext.jsで1対1で複製しようとしています。ヘッドレス移行は、コンテンツアーキテクチャを再考し、ページ構造を簡潔にし、何年にもわたる蓄積した不用品を排除する機会です。コンテンツを保持しながらプレゼンテーションを再考するチーム — 古いテーマから詮索好きなウィジェットとサイドバーをコピーしようとするチームは、劇的に優れた結果を終わります。