長年運用してきた技術ブログ(WordPress+webpackビルドの自前フロント)を、WordPressをAPI専用のヘッドレスCMSとして残しつつ、表示側をNext.js(App Router)+Vercelに全面的に置き換えた。
単なる技術的な好奇心ではなく、実際にLighthouseスコアがどう変わったかを定量的に比較したので、その結果を中心にまとめる。
構成
変更前:t-creative-works.com → WordPress(表示・管理画面・DB、すべて1台のXserverで完結)
変更後:t-creative-works.com → Vercel(Next.js、表示専用、SSG/ISR)
cms.t-creative-works.com → Xserver(WordPress、REST APIバックエンド+管理画面専用)WordPress側は記事データの保管・編集だけに専念させ、実際にユーザーが見る画面は全部Next.jsで作り直した。WordPressの管理画面・投稿フローはそのまま使えるので、更新の手間は増えていない。
計測結果
同一ページ(TOPページ/記事詳細ページ)を、旧WordPress版(現在はcms.t-creative-works.comとしてAPI専用で裏に残している)と、新しいNext.js版で、PageSpeed Insights(モバイル)で比較した。
TOPページ
| 指標 | 旧WordPress | 新Next.js |
|---|---|---|
| Performance | 58 | 70 |
| Accessibility | 88 | 100 |
| Best Practices | 92 | 100 |
| SEO | 61 | 100 |


記事詳細ページ
| 指標 | 旧WordPress | 新Next.js |
|---|---|---|
| Performance | 57 | 71 |
| Accessibility | 85 | 96 |
| Best Practices | 92 | 96 |
| SEO | 61 | 100 |
SEOとAccessibility、Best Practicesは、TOP・詳細ページともにほぼ満点(96〜100)まで改善した。Performanceも10ポイント以上向上している。


特筆すべきは、この記事詳細ページは現時点ではまだgenerateStaticParamsによる完全な静的生成(SSG)を実装しておらず、アクセスのたびにサーバーレス関数がWordPress側のREST APIを呼び出す「動的レンダリング」のままだという点だ。
この状態でも旧WordPress版を上回っているということは、静的生成に切り替えればさらに伸びしろがあるということになる。
なぜ良くなったのか
- 軽量なランタイム:旧フロントはwebpackで固めた自前のJS資産(jQuery依存のスライダー・アニメーション等を含む)を一式読み込んでいたが、Next.jsはページに必要な分だけをコード分割して配信する
- メタデータ・構造の見直し:移行を機に、タイトル・description・favicon・画像の遅延読み込みなど、SEO/Best Practicesに直結する基本項目を一通り点検・整備した
- ホスティングの最適化:VercelのCDN・画像最適化など、プラットフォーム側の恩恵もある
今後の課題
現状、記事詳細・カテゴリー・タグなどのページはまだ動的レンダリングのままで、Next.jsのサーバーレス関数がリクエストのたびにWordPress(日本のXserver)へAPIを取りに行っている。
これをgenerateStaticParamsでビルド時に静的生成する形に変更すれば、Performanceスコアはさらに伸びる見込みだ。この最適化は現在進行中で、完了したら改めて結果を追記したい。
まとめ
- WordPressをヘッドレスCMS化し、表示をNext.jsに置き換えることで、Performance・Accessibility・Best Practices・SEOの全指標で計測上の改善が確認できた
- 特にSEOスコアは旧61点から100点まで向上しており、既存のWordPress資産を活かしながらフロントだけをモダンな構成に置き換える戦略が有効に機能した
- まだ最適化の余地(SSG化)が残っており、継続して改善していく