2025年に「WordPress 表示速度を高速化する方法」を紹介しましたが、あれから1年、WordPress 本体の高速化が一気に進みました。2025年12月リリースの WordPress 6.9では、ブロック CSS のオンデマンド読み込みによりCSSの読み込み量が最大65%削減。近日公開予定のWordPress 7.0では、SPAのようなクライアントサイドナビゲーションが本格稼働します。本記事では、高速化に関するコア機能の進化とインフラ側の新技術を合わせて紹介したいと思います。
WordPress本体の高速化
1. SQLiteサポート（プラグイン版が実用段階に）
WordPressは長年 MySQL（MariaDB）をデータベースエンジンとして使用してきましたが、公式チームが開発する「SQLite Database Integration」プラグインが着実に成熟しています。2025年6月には完全に書き直された新しいSQLiteドライバーが公開され、MySQLのSQLをAST（抽象構文木）に解析してからSQLiteに変換するアーキテクチャに移行しました。WordPressコアのPHPUnitテストスイートで99%以上のテストがパスしており、2026年4月時点でもプラグインは継続的にアップデートされています（WordPress 6.9.4まで動作確認済み）。
なぜ速くなるのか？
SQLiteはファイルベースのデータベースエンジンです。MySQLのようにサーバープロセスとのTCP/Socket通信が不要なため、特にネットワーク越しにデータベースサーバーへ接続している環境では、TTFB（Time to First Byte）が顕著に改善します。また、SQLiteのデータベースファイルは単一ファイルなので、エッジサーバーへの配置も容易です。
2. オンデマンドブロックCSS読み込み（On-Demand Block CSS Loading）
WordPress 6.9（2025年12月リリース）で導入された最大のパフォーマンス改善の一つです。
なぜ速くなるのか？
WordPress 6.9以前では、クラシックテーマはページ内でどのブロックが使われているか判断できないため、通常はヘッダーに巨大なスタイルシート（wp-block-library）を読み込んでいました。
WordPress 6.9では、クラシックテーマでも 「ページで使用されているブロックのスタイルだけを読み込む（load block styles on demand）」 機能がデフォルトで有効になりました。
この実現には、テンプレート強化のための出力バッファ（template enhancement output buffer）が利用されています。
スタイルのホイスティング（Hoisting）：ページのBody部分がレンダリングされた後、システムは使用されたブロックを検出し、それらに対応するスタイルコード（CSS）をHTMLタグ処理機能を使って抽出し、インラインの形で <head> に挿入します。
バッファリングと解析：WordPressは、ページをブラウザに逐次出力するのではなく、まずサーバーのメモリ上でページ全体を「バッファ」に保持します。
6.9 公式サイトの記事で公開したベンチマーク結果は以下の通りです：
- CSS削減量： デフォルトのクラシックテーマ（Twenty Ten 〜 Twenty Twenty-One）でCSSファイルサイズが100KB以上削減。ページあたりのCSSの読み込み量は約30〜65%軽量化(参考2)
- LCP改善（シンプルなページ）： クラシックテーマの LCP が10%以上改善(参考2)
- LCP改善（複雑なページ）： 23種類のブロックを含むテストページでは、クラシックテーマで平均2.8%、ブロックテーマで平均 5.8%のLCP改善(参考2)
WordPress 6.9 では、ページ上で実際に使われているブロックの CSS だけを読み込む仕組みがデフォルトで有効になります。
3. WordPress 7.0 — Interactivity API とクライアントサイドナビゲーション
WordPress 7.0は近日公開予定です。Gutenberg Phase 3（コラボレーション機能）の正式ローンチとなります。
パフォーマンスの観点で最も注目すべきは、Interactivity API の安定化とクライアントサイドナビゲーションの強化です。
Interactivity API とは何か
WordPressネイティブのクライアントサイド・インタラクティビティフレームワークです。data-wp-on--click、data-wp-bind、data-wp-contextといったディレクティブを HTML に追加するだけで、ReactやVueを別途導入することなく、リアクティブな UI を構築できます。
なぜ速くなるのか？
クライアントサイドナビゲーションが有効な場合、ページ遷移時にフルリロードが発生しません。新しいページのコンテンツだけが差し替えられるため、ヘッダーやフッター、共通のCSS/JSは再読み込みされず、ユーザーから見た体感速度が大幅に向上します。これはSPA（Single Page Application）に近いナビゲーション体験を、WordPressのサーバーサイドレンダリングを維持したまま実現するものです。
4. fetchpriority 属性による読み込み優先度の制御
WordPress 6.9ではfetchpriority属性のスクリプト読み込みへの適用が強化されました。fetchpriority="high"を指定すると、ブラウザはそのリソースを最優先でダウンロードします。
典型的な使い方は、ファーストビューに表示される大きな画像（Banner 画像）に対して fetchpriority="high" を付与することです。これにより、ブラウザのデフォルトの解析順に頼るのではなく、LCP（Largest Contentful Paint）に直結するリソースを明示的に優先させることができます。
WordPressコアは自動的にメインコンテンツの最初の画像にfetchpriority="high" を付与しますが、テーマやプラグインで独自に制御することも可能です。
5. WP-Cron実行タイミングの最適化
WordPressはOSレベルのCronジョブではなく、ユーザーのページアクセスをトリガーにして定時タスク（更新チェック、予約投稿の公開など）を実行する独自のWP-Cron仕組みを採用しています。
なぜ速くなるのか？
WordPress 6.8 以前では、WP-Cronはinitフック（ページ生成の初期段階）で起動されていました。具体的には、定時タスクの期限が来ていると、WordPressは自身の wp-cron.phpにHTTPループバックリクエストを送信します。このリクエストの発行がページ生成の冒頭で行われるため、ループバックの応答が遅い環境では、そのままユーザーのTTFBに上乗せされていました。
WordPress 6.9 では、WP-Cron の起動が shutdown フックに移動しました。shutdownはページのレスポンスがブラウザに送信された後に実行されるフックです。Nginx + PHP-FPM 環境では fastcgi_finish_request() が呼ばれ、PHP-FPM がレスポンスを Web サーバーに引き渡した後もプロセスが継続するため、WP-Cron の処理はユーザーの体感速度にまったく影響しなくなります。
つまり、Cron 自体が速くなったわけではなく、ユーザーへのレスポンス完了後に実行されるようになったことで、TTFB への影響がゼロになったという改善です。
実測効果
公式サイトのデータによると、WP-Cronが実行するリクエストにおいてTTFBが最大1秒短縮される可能性があるとされています(参考2)。すべてのリクエストで1秒改善されるわけではなく、Cronタスクの実行タイミングに当たったリクエストに対してのみ効果があります。
6. HTTP 103 Early Hints
2026年のWordPress高速化で見逃せない技術の一つが HTTP 103 Early Hints です。
通常の HTTP 通信では、ブラウザがサーバーにリクエストを送ってから 200 OK レスポンスが返るまで、ブラウザは待機状態（いわゆる「サーバーの思考時間」）になります。Early Hints はこの待機時間を活用する仕組みです。
サーバーは最終的な 200 レスポンスを準備している間に、まず 103 ステータスコードのレスポンスを送信します。この 103 レスポンスには Link ヘッダーが含まれ、ページのレンダリングに必要な CSS、フォント、画像などのリソース情報がブラウザに伝えられます。ブラウザはサーバーが「考えている」間に、これらのリソースの先行ダウンロードを開始できます。
実測効果
- Cloudflare の検証では LCP が最大30%改善(参考3)
- Shopify は Black Friday/Cyber Monday のトラフィック下で LCP が 500ms 以上高速化（全アクセスの中央値）(参考3)
WordPress での導入方法
Cloudflareを利用している場合、ダッシュボードのSpeed > Optimization > Content Optimizationで「Early Hints」をオンにするだけで基本的な設定は完了します。
ただし、Early Hintsの効果を最大化するには、WordPress側で適切なLinkヘッダー（preload や preconnect）を出力する必要があります。Perfmattersなどのプラグインがこの設定を簡単に行えます。
ブラウザ対応状況
近来サポートするブラウザは多くなりました、Chrome 103 以降、Edge、Safari、Firefoxの最新版で対応しています。未対応のブラウザは103レスポンスを無視するだけなので、副作用はありません。Early Hintsは HTTP/2 および HTTP/3 上でのみ動作します。
HTTP 103 Early Hints についてさらに詳しく知りたい方は、以下の記事をご参照ください。
Early HintsをKUSANAGI+CloudFlareで利用してみる
まとめ — 2026年の WordPress 高速化ロードマップ
| 施策 | 効果 | 対象 |
|---|---|---|
| WordPress 6.9に更新（ブロックCSSオンデマンド） | CSS 30〜65%削減、LCP 最大13%改善(参考2) | 全サイト |
| HTTP 103 Early Hints の有効化 | LCP最大30%改善(参考3) | Cloudflareなど利用者 |
| Interactivity APIによるクライアントナビゲーション | ページ遷移の体感速度向上 | ブロックテーマ利用者 |
| SQLiteデータベースへの移行 | TTFB改善・デプロイ簡素化 | 小〜中規模サイト |
| fetchpriority属性の適切な付与 | LCP改善 | 全サイト |
| WP-Cron の shutdown 移行 | TTFB最大1秒短縮（Cron実行時）(参考2) | 全サイト |
まず取り組むべきは WordPress 6.9 への更新です。本記事で紹介した高速化施策のブロック CSS のオンデマンド読み込み、fetchpriority によるスクリプト最適化、WP-Cronの実行タイミング改善は、6.9に更新するだけで自動的に有効になります。その上で、CloudflareのEarly Hints有効化を検討し、総合的なパフォーマンス向上が見込めます。
参考
１，Introducing a new SQLite driver for WordPress – WordPress Playground
２，WordPress 6.9 Frontend Performance Field Guide – Make WordPress Core
