結論から言うと、トップページの TTFB は 2.76秒 → 0.50秒、記事ページは 2.02秒 → 0.68秒 まで改善しています。
この記事では「なぜ移管を判断したか」「どんな手順で進めたか」「実際にどこまで速くなったか」を順番に整理します。
なぜ移管することにしたか
調査のきっかけは、トップページや記事ページの初回表示が明らかに重いことでした。
調べると、Vercel 側で Cache-Control: private, no-cache, no-store になっているページが多く、CDN キャッシュにほとんど乗っていない状態でした。WordPress API 自体の応答は極端に遅くないのに、最終的な HTML 配信までの TTFB が大きく膨らんでいたのはこれが原因のひとつです。
加えて、Next.js の SSR・App Router の処理、リージョン距離、不要な prefetch、ページ組み立て時のデータ取得が積み重なり、「WordPress が遅い」のではなく「配信経路全体が重い」状態になっていました。
同じ WordPress を使っている別構成のサイトではもっと速く配信できていたため、CMS 本体を触る前に配信基盤を見直すべきだと判断しました。
移管の流れ
最初から本番を切り替えるのではなく、codex/cloudflare-pages-worker という検証ブランチを切って Cloudflare Workers 上に preview 環境を立ち上げるところから始めました。
この段階でやったことは主に3つです。
- Next.js を OpenNext 経由で Workers に載せる構成追加
- Cloudflare 向けの build / deploy 設定
- Workers 用の custom domain・preview URL 設定
その後、単純な移管だけで終わらせず、Workers で効果が出やすいようにアプリ側も合わせて整理しました。具体的には以下を実施しています。
- トップページ・一覧ページのキャッシュ設計を見直し
- 記事一覧の payload 軽量化
- 関連記事の取得をクリティカルパスから除外
- HTML サイトマップの大量 prefetch を停止
- WordPress API の前段に edge proxy を挟める構成を追加（将来的に Next/Worker → edge cache → WordPress の形へ移行できるよう準備）
運用面では、Cloudflare 側で main を production branch に設定し、custom domain stacknot.east-cloud.jp を Worker に割り当てました。preview URL で表示確認と速度比較を重ね、問題が解消できた段階で本番ドメインを切り替えています。
ベンチマーク結果
preview 環境での比較（2026年4月1日時点）
| ページ | Vercel | Cloudflare Workers | ||
|---|---|---|---|---|
| TTFB | Total | TTFB | Total | |
| トップページ | 2.76s | 3.24s | 0.50s | 0.51s |
| 記事ページ | 2.02s | 2.18s | 0.68s | 0.69s |
本番ドメイン切り替え後（2026年4月3日時点・外形監視ベース）
| ページ | ステータス | TTFB |
|---|---|---|
トップページ / | 200 | 0.97s |
HTML サイトマップ /html-sitemap | 200 | 0.94s |
| 代表記事 | 200 | 0.85s |
preview 時の最速値よりは少し落ち着きましたが、Vercel 時代と比べると体感差は大きく、初回表示の重さは明確に改善しました。
移管して分かったこと
今回の一番の学びは、「WordPress を使っているから遅い」とは限らないということです。
実際には、配信基盤・キャッシュ方針・SSR の組み立て・不要な prefetch など、WordPress の外側にボトルネックがあるケースも多いです。特に Next.js App Router では、ページ本体だけでなく周辺 UI のデータ取得やリンク先 prefetch が積み重なりやすく、そこを整理するだけでもかなり改善します。
また、Cloudflare Workers への移行により、速度改善以外にもメリットがありました。
- WordPress API の前段に edge proxy を置ける構成が取れるようになった
- custom domain 配下での配信・制御を一元化しやすくなった
今後は WordPress 側 webhook や Search Console 連携も含め、更新運用まで Cloudflare 側に寄せていく予定です。
おわりに
Vercel から Cloudflare Workers への移管は、単なるホスティング変更ではなく、配信設計全体を見直す機会になりました。
「WordPress が遅い」と感じているなら、CMS 本体を疑う前に、まず配信経路・キャッシュ・SSR の組み立てを分解してみる価値はあります。今回の Stacknot の移管は、その効果がかなり分かりやすく出た事例でした。
Q&A
Q. Vercel から Cloudflare Workers に移行するメリットは何ですか？ A. エッジでの配信による TTFB の大幅な改善、CDN キャッシュの柔軟な制御、edge proxy を挟んだ構成が取りやすいといったメリットがあります。Stacknot では移行後にトップページの TTFB が 2.76秒から 0.50秒まで改善しました。
Q. WordPress サイトが遅い原因はどこにありますか？ A. WordPress 本体よりも、配信基盤・キャッシュ設定・SSR の組み立て・不要な prefetch など配信経路側にボトルネックがあるケースも多いです。まず Cache-Control の設定や CDN キャッシュの状況を確認することをおすすめします。
Q. Next.js を Cloudflare Workers で動かすには何が必要ですか？ A. OpenNext を使うことで Next.js を Cloudflare Workers に載せることができます。build / deploy 設定を Cloudflare 向けに調整する必要があります。
Q. TTFB とは何ですか？ A. Time To First Byte の略で、ブラウザがリクエストを送信してからサーバーの最初の1バイトを受信するまでの時間です。この値が小さいほどサーバーの応答が速く、ページ表示の体感速度に直結します。
