WordPressは世界で最も使われているCMSですが、「遅い」というのが長年の課題です。画像の最適化やキャッシュプラグインの導入など、よく紹介される高速化手法はたくさんあります。しかし、プラグインを増やすほど競合リスクが高まり、根本的な速度改善にはつながりにくいのが実情です。
この記事では、VPS＋KUSANAGIをさらに超えた高速化として、Cloudflareプロキシを組み合わせた構成を紹介します。実際にエックスサーバーVPS 4GBプランのKUSANAGI環境で12時間・13回のベンチマークを取得し、Cloudflareあり／なしの差を数値で示しました。
結論から言えば、デスクトップのTTFBは中央値で82.89%改善。プラグインなしで、サーバーとCDNの設定だけでここまで変わります。高速化を本気で追求したい方に向けて、サーバー層・CDN層・フロントエンド層の三層に分けて具体的な手順と考え方を整理しました。
WordPress高速化の全体像と三層構造
WordPressの表示速度は、ひとつの施策で劇的に変わるものではありません。速度に関わる要素は大きく3つの層に分かれており、それぞれに適切な対策を打つ必要があります。
サーバー層（オリジンサーバー）
WordPressの処理はサーバー上で実行されます。具体的には、NginxなどのWebサーバーがリクエストを受け取り、PHPがWordPressのコードを処理し、MySQLからデータを取得して、HTMLを生成します。この一連の処理にかかる時間が、TTFB（Time to First Byte）としてユーザーに直接影響します。
サーバー層を速くするには、高速なVPSの選定、Nginx設定の最適化、PHP-FPMのチューニング、MySQLの最適化、そしてサーバーサイドキャッシュの導入が有効です。KUSANAGIは、これらすべてをチューニング済みの状態で提供してくれます。
CDN層（Cloudflare）
CDN（Content Delivery Network）は、世界中のエッジサーバーにコンテンツをキャッシュし、ユーザーに最も近い拠点から配信する仕組みです。Cloudflareはこの役割に加えて、WAF（Webアプリケーションファイアウォール）やDDoS防御、HTTP/3対応など、まとめて提供してくれます。
サーバー層でどれだけチューニングしても、ユーザーとサーバーの物理的な距離による遅延は避けられません。CDN層を噛ませることで、この距離の問題を解消できます。
フロントエンド層（ブラウザ側の最適化）
HTMLがブラウザに届いた後の話です。画像の最適化（WebP/AVIF変換、遅延読み込み）、CSS/JavaScriptの圧縮・遅延読み込み、Webフォントの最適化、不要なプラグインの削除などが該当します。
多くの「WordPress高速化」記事はこの層の話に終始しますが、ここだけをいくら頑張っても、サーバーの応答が遅ければ限界があります。上流（サーバー層・CDN層）から順に手を入れるのが、高速化の正しい順序です。
KUSANAGIがWordPressを速くする仕組み
KUSANAGI（くさなぎ）は、GMOプライム・ストラテジーが開発した超高速CMS実行環境です。VPS上にOSイメージとして展開し、WordPress専用に最適化されたNginx、PHP、MariaDB/MySQLの設定が最初から含まれています。
bcacheとfcacheの二段構えキャッシュ
KUSANAGIには、fcacheとbcacheという2種類のページキャッシュが用意されています。
- fcache：nginxのFastCGIキャッシュを利用したキャッシュです。動的に生成されたページをnginxレベルで保存し、次回以降のリクエストではPHPを実行せずキャッシュ済みのページを返します。PHPの処理を完全にスキップするため、TTFBの短縮効果が最も大きいキャッシュです
- bcache：WordPress組み込みのキャッシュ機構を利用したキャッシュです。fcacheと同様に作成済みのページを保存・再利用しますが、PHPで動作し、データのストア先がデータベースである点が特徴です。PHPを経由する分、速度面ではfcacheに劣りますが、細やかなキャッシュ制御が可能です
基本的にはfcacheを有効にしておけば十分です。fcacheでカバーできないケース（ログインユーザー向けの表示切り替えなど）にbcacheを併用する形が推奨されます。なお、キャッシュ対象はPHPで動的に生成されるHTMLページであり、画像やCSS・JavaScriptなどの静的コンテンツはキャッシュされません。
Nginx＋PHP-FPMの最適化済み設定
KUSANAGIでは、NginxのワーカープロセスやPHP-FPMのプロセス数が、VPSのスペックに合わせてチューニング済みです。OPCache（PHPの中間コードキャッシュ）も有効化されており、PHP処理のオーバーヘッドが最小化されています。
共用サーバーのWordPressと比べた場合、KUSANAGIのVPS環境では処理時間が数倍から数十倍速いケースも珍しくありません。過去に筆者が行ったベンチマークでは、共用サーバーの外部TTFB 0.162〜0.367秒に対し、VPS（KUSANAGI環境）では0.103〜0.158秒という結果が出ています。
HTTP/2標準対応と高速なSSL処理
KUSANAGIはHTTP/2に標準対応しており、SSL/TLSの処理も最適化されています。Let’s Encryptの証明書連携もコマンド1つで完了します。SSL化はSEOにもプラスですし、HTTP/2による多重化はページの部品を並列で取得できるため、体感速度の向上にもつながります。
Cloudflareプロキシのメリット
KUSANAGIだけでも十分に速いWordPress環境を構築できますが、Cloudflareのプロキシ（オレンジの雲アイコン）を有効化すると、さらに複数の面で恩恵を受けられます。
キャッシングによる表示速度の向上
Cloudflareは全世界300以上のデータセンターにエッジサーバーを持っています。静的なアセット（CSS、JavaScript、画像など）はエッジにキャッシュされ、ユーザーに最も近い拠点から直接配信されます。
これにより、オリジンサーバーまで到達せずにレスポンスが完結するリクエストが増え、TTFBが大幅に短縮されます。特にPageSpeed InsightsのデスクトップTTFBでは、後述の実測で82.89%の改善を確認しています。
サーバー負荷の軽減
VPSプランの中でも、メモリが少ないプラン（2GB〜4GB）を使っている場合、ボットのクロールやスキャンでメモリが圧迫されることがあります。特にwp-login.phpやxmlrpc.phpへのブルートフォース攻撃は、CPUとメモリを無駄に消費します。
Cloudflareのプロキシを通すことで、これらのリクエストの多くはエッジでブロックまたはキャッシュ処理されるため、オリジンサーバーへの到達が減ります。結果として、本来の訪問者へのレスポンスに使えるリソースが増えます。
セキュリティ強化
Cloudflareはプロキシモードにするだけで、以下のセキュリティ機能が有効になります。
- DDoS防御：大量のリクエストによる攻撃をエッジで吸収します
- WAF（Webアプリケーションファイアウォール）：SQLインジェクションやXSSなどの攻撃パターンをブロックします
- ボットマネジメント：悪意のあるボットを検出し、アクセスを制限します
- IPアドレスの秘匿：サーバーの実IPが外部に公開されなくなります
さらに、Cloudflareのカスタムルール（WAF Rules）を使えば、wp-adminやwp-login.phpへのアクセスを特定のIPアドレスのみに制限できます。これにより、ログイン画面への不正アクセス試行をCloudflare側でブロックでき、VPSに負荷がかかることすらなくなります。
HTTP/3（QUIC）対応と無料SSL
CloudflareはHTTP/3（QUIC）にも対応しており、特にモバイル回線など不安定なネットワークでの通信効率が向上します。また、訪問者とCloudflare間のSSL（Universal SSL）はプロキシを有効にするだけで自動的に適用されます。
なお、HTTP/3で配信するにはVPS側のファイアウォールでUDP 443ポートを開放する必要があります。見落としがちなポイントなので覚えておいてください。
実測データで見るCloudflareの効果
ここからは、実際に「KUSANAGIのみ」と「KUSANAGI＋Cloudflareプロキシ」の2構成を同一サーバーで比較した結果を紹介します。
測定環境と条件
- サーバー：エックスサーバーVPS 4GBプラン（KUSANAGI）
- KUSANAGIキャッシュ：bcache ON、fcache ON（両構成共通）
- 比較パターン：Cloudflareプロキシなし vs Cloudflareプロキシあり
- 測定期間：2026年3月30日 22:00〜3月31日 10:00（JST）計13時点
- 測定方法：外部からのベンチマーク（TTFB）およびPageSpeed Insights API（モバイル・デスクトップ）を1時間おきに自動取得
13回分の測定結果サマリ
以下が、Cloudflareあり／なしを比較した13回測定の要約です。
外部TTFB（中央値）：22.97%改善（13回中11回で改善）
PSI モバイル TTFB：47.37%改善（非同点10回中10回すべてで改善）
PSI デスクトップ TTFB：82.89%改善（13回中12回で改善）
PSI デスクトップ LCP：3.28%改善（13回中10回で改善）
PSI モバイル LCP：平均では1.45%悪化ですが、外れ値の影響が大きく中央値で見ると改善側
PSI モバイルスコア：ほぼ同等（96.92 → 97.00）
PSI デスクトップスコア：同等（100 → 100）
特筆すべきは、デスクトップTTFBの82.89%改善です。Cloudflareなしでは40〜61msだったTTFBが、Cloudflareありでは3〜4msまで短縮されています。これはCloudflareのエッジキャッシュがヒットした結果で、オリジンサーバーへのリクエスト自体が発生していません。
時間帯別の詳細データ
以下は、13回分の時間帯別測定データです（CF = Cloudflare）。
外部TTFB（秒）
- 22:00 ― CFなし 0.064 / CFあり 0.067（+4.2%）
- 23:00 ― CFなし 0.082 / CFあり 0.060（-26.7%）
- 00:00 ― CFなし 0.190 / CFあり 0.059（-69.3%）
- 01:00 ― CFなし 0.065 / CFあり 0.063（-2.3%）
- 02:00 ― CFなし 0.067 / CFあり 0.065（-3.3%）
- 03:00 ― CFなし 0.070 / CFあり 0.055（-22.3%）
- 04:00 ― CFなし 0.060 / CFあり 0.059（-0.1%）
- 05:00 ― CFなし 0.073 / CFあり 0.062（-15.1%）
- 06:00 ― CFなし 0.069 / CFあり 0.054（-21.3%）
- 07:00 ― CFなし 0.062 / CFあり 0.058（-6.0%）
- 08:00 ― CFなし 0.087 / CFあり 0.055（-37.2%）
- 09:00 ― CFなし 0.062 / CFあり 0.060（-3.2%）
- 10:00 ― CFなし 0.061 / CFあり 0.063（+2.9%）
PSI デスクトップ TTFB（ms）
- 22:00 ― CFなし 43ms / CFあり 3ms（-93.0%）
- 23:00 ― CFなし 61ms / CFあり 3ms（-95.1%）
- 00:00 ― CFなし 40ms / CFあり 3ms（-92.5%）
- 01:00 ― CFなし 43ms / CFあり 3ms（-93.0%）
- 02:00 ― CFなし 50ms / CFあり 3ms（-94.0%）
- 03:00 ― CFなし 41ms / CFあり 3ms（-92.7%）
- 04:00 ― CFなし 53ms / CFあり 3ms（-94.3%）
- 05:00 ― CFなし 48ms / CFあり 3ms（-93.8%）
- 06:00 ― CFなし 40ms / CFあり 3ms（-92.5%）
- 07:00 ― CFなし 40ms / CFあり 65ms（+62.5%）
- 08:00 ― CFなし 40ms / CFあり 3ms（-92.5%）
- 09:00 ― CFなし 50ms / CFあり 4ms（-92.0%）
- 10:00 ― CFなし 47ms / CFあり 3ms（-93.6%）
07:00の1時点だけCloudflareありのTTFBが悪化していますが、これはキャッシュの更新タイミングか一時的なエッジの問題と考えられます。全体としては圧倒的にCloudflareありが有利です。
KUSANAGI初期セットアップの概要
KUSANAGIの初期設定の流れを簡単に紹介します。VPSの契約時にKUSANAGIイメージを選択できるサービスが多いため、OSインストールの手間は基本的にありません。
VPS契約とKUSANAGIイメージの選択
エックスサーバーVPS、シンVPS、ConoHa VPSなどでは、サーバー申し込み時のアプリケーションイメージとしてKUSANAGIを選択できます。OSはAlmaLinuxやCentOS Streamが一般的です。メモリは最低でも2GB以上、できれば4GB以上を推奨します。
SSH接続と初期設定コマンド
VPSにSSHで接続し、KUSANAGIの初期設定を行います。主な手順は以下の通りです。
kusanagi init：タイムゾーン、言語、管理者パスワードなどの初期設定kusanagi provision：WordPress用のプロファイル（ドメイン、DBなど）を作成kusanagi ssl：Let’s Encrypt証明書の取得と適用
コマンド数回で、SSL対応のWordPress環境が立ち上がります。CUIに慣れていない方には少しハードルがありますが、手順通りに進めれば難しいことはありません。
bcache・fcacheの有効化
プロビジョニング後、キャッシュを有効化します。
kusanagi fcache on：FastCGIキャッシュの有効化kusanagi bcache on：WordPress組み込みキャッシュの有効化
これだけで、ページキャッシュが機能し始めます。fcacheは記事の更新時に自動でパージされますので、基本的にオンにしておいて問題ありません。
Cloudflare導入手順の概要
VPS＋KUSANAGIの環境にCloudflareを導入する手順を簡潔にまとめます。
Cloudflareアカウント作成とドメイン追加
Cloudflareの無料プランで十分です。アカウント作成後、対象のドメインを追加し、既存のDNSレコードをインポートします。
ネームサーバーの変更
ドメインレジストラ側でネームサーバーをCloudflare指定のものに切り替えます。切り替え後、DNSの反映には数分〜数時間かかります。事前にTTLを短くしておくと、切り替え時のダウンタイムを最小化できます。
SSLモードの設定
CloudflareのSSL/TLS設定は「フル（厳格）」を選択してください。KUSANAGIでLet’s Encrypt証明書を取得済みであれば、この設定によりCloudflare←→オリジンサーバー間も暗号化されます。「フレキシブル」を選ぶとリダイレクトループが発生する原因になるので注意が必要です。
プロキシの有効化
DNSレコードのAレコード横にあるオレンジの雲アイコンをオンにすると、Cloudflareのプロキシが有効になります。これにより、CDN、WAF、DDoS防御など一式のセキュリティ＋パフォーマンス機能が走り始めます。
キャッシュとセキュリティの最適化設定
Cloudflareのプロキシを有効にしたら、WordPress向けにキャッシュルールとセキュリティルールを調整します。
Cache Rulesの設定
CloudflareのCache Rulesを使って、キャッシュの対象と除外を細かく制御します。
- キャッシュ除外：
/wp-admin/*、/wp-login.php、/wp-cron.phpなどの管理画面・ログイン画面はキャッシュから除外します - 静的ファイルのキャッシュ：画像、CSS、JS、フォントファイルなどは積極的にキャッシュし、Edge Cache TTLを長めに設定します
- HTMLのキャッシュ：記事ページのHTMLもキャッシュすることで、オリジンへのリクエスを最小化できます。ただし、ログインユーザーやコメント投稿直後の表示に影響する場合があるため、Cookieベースの除外条件を入れると安全です
WAF Rulesによるアクセス制限
Cloudflareのカスタムルールを使って、WordPressの管理画面へのアクセスを制限できます。
wp-login.phpへのアクセスを、自分のIPアドレス以外からブロック/wp-admin/配下へのアクセスを同様に制限（ただしadmin-ajax.phpはフロント側で使われる場合があるため除外）xmlrpc.phpへのアクセスを完全ブロック（使っていなければ）
これらのルールをCloudflare側で設定すると、不正アクセスのリクエストがVPSに到達する前にブロックされます。特にメモリの少ないVPSプランでは、この効果は大きいです。
プラグインなしで実践するフロントエンド高速化
サーバー層とCDN層を整えたら、フロントエンド層の最適化に取り組みます。KUSANAGIとCloudflareの組み合わせでは、プラグインなしでも十分な高速化が可能です。
画像の最適化
画像はページの読み込み時間に最も大きく影響する要素です。以下のポイントを押さえてください。
- WebPまたはAVIF形式への変換：JPEGやPNGと比べて30〜50%軽量化できます。Cloudflareの有料プランではPolish機能で自動WebP変換が利用可能です
- 適切なサイズの指定：表示サイズに合わせた画像をアップロードします。不必要に大きな画像は読み込み時間を無駄にします
- 遅延読み込み（lazy loading）：WordPress 5.5以降はネイティブの遅延読み込みが標準搭載されています。ファーストビューの画像以外は自動的にlazyloadされます
CSS・JavaScriptの最適化
テーマやプラグインが出力するCSSとJavaScriptは、表示速度に大きく影響します。
- 不要なスクリプトの除去：使っていないプラグインが読み込むCSS/JSを
functions.phpでwp_dequeue_script/wp_dequeue_styleして取り除きます - defer/asyncによる遅延読み込み：レンダリングをブロックするJavaScriptには
defer属性を付けます - クリティカルCSSのインライン化：ファーストビューに必要な最小限のCSSをインラインで出力し、残りは非同期で読み込みます
- CSS/JSの圧縮：CloudflareのAuto Minify機能を使えばプラグイン不要で圧縮できます
不要な機能の無効化
WordPressはデフォルトで多くの機能を読み込みますが、使っていない機能は外したほうがパフォーマンスに良いです。
- WordPress絵文字スクリプト（wp-emoji-release.min.js）の無効化
- oembed関連スクリプトの無効化
- 投稿リビジョンの制限（wp-config.phpで
AUTOSAVE_INTERVALやWP_POST_REVISIONSを設定） - 使っていないプラグインの削除（無効化ではなく削除）
Webフォントの最適化
Google Fontsなどの外部フォントは、表示速度に影響します。font-display: swapの指定で、フォント読み込み完了前にシステムフォントで代替表示させることで、体感的な遅延を防げます。フォント数は最低限に絞り、使用するウェイトも必要なものだけに限定してください。
データベースの最適化
WordPress運用が長くなると、データベースには不要なデータが蓄積します。
- リビジョンの削除：過去の記事リビジョンが数百〜数千件になっていることがあります。wp-cliの
wp post deleteコマンドで一括削除が可能です - スパムコメントの削除：放置しているとDBが肥大化します
- Transientデータのクリーンアップ：期限切れのTransientデータは自動削除されないケースがあります
- テーブルの最適化：MySQLの
OPTIMIZE TABLEコマンドで断片化を解消します
KUSANAGIにはRedisによるオブジェクトキャッシュも利用可能です。DBへのクエリ結果をメモリ上にキャッシュすることで、繰り返しのクエリを高速化できます。
PHPバージョンの最適化
PHPのバージョンは、そのまま処理速度に直結します。PHP 7系からPHP 8系への移行だけで、実行速度が20〜40%向上するケースもあります。
KUSANAGIでは常に最新のPHPバージョンが使える状態になっており、kusanagi php82のようにコマンドでバージョン切り替えが可能です。テーマやプラグインの互換性を確認したうえで、なるべく新しいバージョンを使いましょう。
表示速度の計測方法
高速化したあとは、効果を数値で確認しましょう。主要な計測ツールを紹介します。
PageSpeed Insights
Googleが提供する無料ツールです。URLを入力するだけで、モバイル・デスクトップ両方のパフォーマンススコアとCore Web Vitals（LCP、CLS、INPなど）を確認できます。特にTTFBとLCPは高速化の効果を見るのに適しています。
GTmetrix
PageSpeed Insightsよりも詳細なウォーターフォールチャートを確認できます。どのリソースがボトルネックになっているかを視覚的に把握するのに便利です。
curl や外部スクリプトによるTTFB計測
定期的な計測や時間帯別の傾向を見たい場合は、curlコマンドや自作スクリプトで外部からTTFBを取得するのが有効です。今回の実測データもこの方法で取得しています。
よくある質問
KUSANAGIは無料で使えますか
はい。KUSANAGI自体は無料のCEエディション（Community Edition）が提供されています。ただし、VPSの契約費用は別途必要です。エックスサーバーVPSやシンVPSでは月額数百円から利用できます。
共用サーバーからVPS＋KUSANAGIに移行する価値はありますか
表示速度を重視するなら価値は大きいです。筆者の実測では、共用サーバーの外部TTFBが0.162〜0.367秒だったのに対し、VPS（KUSANAGI環境）では0.060〜0.100秒前後まで短縮されています。ただし、VPSはサーバー管理の知識が必要になるため、更新や保守に不安がある場合は共用サーバーのまま他の高速化施策を検討するのも選択肢です。
Cloudflareの無料プランでも効果はありますか
今回の実測データはすべてCloudflareの無料プランで取得したものです。CDNキャッシュ、DDoS防御、WAF基本機能、HTTP/3対応など、無料プランでも十分な機能が利用できます。
高速化プラグインは不要ですか
KUSANAGI＋Cloudflareの構成であれば、WP Super CacheやW3 Total Cacheなどのキャッシュプラグインは基本的に不要です。KUSANAGIのfcacheがページキャッシュを、Cloudflareがエッジキャッシュを担当するため、プラグインとの二重キャッシュが競合するリスクを避けるためにも外しておくのが安全です。CSS/JSの最適化もCloudflareのAuto Minifyで対応できます。
まとめ
WordPress高速化の鍵は、プラグインの数を増やすことではなく、サーバー層・CDN層・フロントエンド層の三層を正しく設計することにあります。
今回紹介した構成をまとめます。
- サーバー層：VPS＋KUSANAGIで、bcache/fcache、OPCache、Nginx最適化を活用
- CDN層：Cloudflareプロキシで、エッジキャッシュ、セキュリティ、HTTP/3を一括導入
- フロントエンド層：画像最適化、CSS/JS最適化、不要機能の削除をプラグインなしで実施
実測結果として、Cloudflareを追加するだけでデスクトップTTFBが82.89%改善され、PSIスコアはデスクトップ100点・モバイル97点を維持しています。
VPSの管理やKUSANAGIの設定に不安がある方は、まずCloudflareの導入だけでも試してみてください。無料プランでも十分な速度改善とセキュリティ強化が見込めます。より詳しい設定手順は、WordPress向けサーバー比較の記事も合わせて参考にしてください。
Comment