CMS高速化で圧倒的に効いたのはサーバ変更！実測3.4倍差の比較データをもとに解説！

CMS（WordPressなど）の高速化手法には、大きく以下の3つが挙げられます。

1. プラグインの利用やコードの最適化
2. 画像圧縮やCDN活用
3. サーバ環境の変更

このうち1と2はよく言われることですが、最も根本的な改善効果があるのは3のサーバ環境です。

本記事では、実際にサーバ環境を変えるだけでどれだけ速度が変わるかを、実測データでお伝えします。

CMSの高速化で見落とされがちな「サーバ環境」

CMSの表示速度を改善しようとするとき、多くの方がまず取り組むのはプラグインの見直しや画像圧縮、キャッシュの設定といった「手軽に着手できる部分の最適化」でしょう。

確かにこれらは一定の効果はあるものの、そもそもサーバ側の処理速度が遅ければ、高速化には限界があります。

なぜなら、CMSの表示速度は「サーバがページを生成して返す速度」が土台になっています。その土台が遅い状態では、どれだけフロント側を最適化しても体感速度の改善にはつながりにくいからです。

CMSがページを表示する際の流れを整理すると、以下のようになります。

1. ユーザーのリクエストを受ける
2. サーバがHTMLを生成する
3. それをブラウザに返す

この「サーバがHTMLを返すまでの時間（TTFB：Time To First Byte）」がそもそも遅いと、その後の画像やCSSの読み込みもすべて後ろ倒しになります。プラグインでの最適化は、この前提の上でしか機能しません。

ちなみに、TTFBを含む表示速度の改善はSEOにも直接影響します。Core Web VitalsとWordPressの関係については「WordPressサイトのSEO効果を最大化する！Core Web Vitals完全攻略ガイド」もぜひ参考にしてください。

つまるところ、CMS高速化の優先順位としては、次のように考えるのが良いでしょう。

施策	効果の性質
プラグイン・コード最適化	フロントの無駄を削る
画像圧縮・CDN	転送量を減らす
サーバ環境の最適化	処理の起点を速くする

上記のサーバ環境の改善は、「上限値そのものを引き上げる」施策であり、他の最適化と組み合わせたとき、大きな効果を発揮します。

なお、サーバ内部でどの層がボトルネックになりやすいかを詳しく知りたい方は、「WordPressの高速化はサーバのどこで決まる？Web・PHP・DB別に遅延ポイント解説」もあわせてご覧ください。

それでは実際に、サーバ環境を変えると速度はどれほど変わるのか、次章で実測データを使って見ていきます。

CMS（WordPress）の高速サーバ比較！

比較の結果を見ていく前に、利用しているサーバスペックや条件についてお伝えします。

今回比較で利用するサイトはこのような表示になっています。（どちらも同じ見た目にしています）

比較その1：ブラウザの検証用ツール【処理速度約3.4倍高速化】

それでは、速度比較をしてみます。

まず使う測定方法は、Google Chromeなどの「ブラウザの検証用ツール（Devツール）」です。WindowsであればF12キーを押すと出てくる画面のものです。

ここの中で、サーバ側の速度を比較する際に使える指標がいくつかありますが、今回は「Network」タブのTypeがdocument の読み込み時間を見てみます。

通常のLAMP環境で、WordPressのサーバ速度比較（ブラウザの検証用ツール）

通常のLAMP環境ですが、以下の画像のように表示が出ました。ここの Nameが「nokusanagispeed.com」という場所を見ていただくと横に Time というのがあります。ここが、196ms となっていますね。
msは、ミリ秒（0.001 秒）のことです。

この196ms ですが、もう1つポイントがあります。3つ横に document という表示があります。ブラウザがページを読み込む際に最初に取得するのがHTML（ドキュメント）で、その後HTMLを起点にCSSや画像、JSタグなどを取得していきます。
つまり、一番最初のリクエストということになりますので、表示高速化の判断材料とすることができます。ここが遅いと、そもそものサイト表示が後ろ倒しになっていくわけですね。

KUSANAGI環境で、WordPressのサーバ速度比較（ブラウザの検証用ツール）

それでは、続いて「KUSANAGI環境」を見ていきます。

すると、「kusanagispeed.com」の横 Time を見てみると、58ms となっています。
先程のLAMP環境と比較すると、196ms と 58ms ですので、3.4倍くらいです。

つまり、KUSANAGI環境にするだけで、通常と比較すると 3.4倍程度速い ということがわかります。

ちなみに、当然KUSANAGI環境側でキャッシュを使ったりはしていませんので、サーバ側の処理で比較をしています。

いかがでしょうか？かなりの高速化が実現しています。WordPressの作りの変更やキャッシュなどは一切使わずに、基盤として、アクセスに対する処理の高速化が強力ということです。

比較その2：サーバの負荷テスト【処理性能約1.53倍向上】

次は、双方のサーバにログインし、Linuxの負荷テストコマンドで比較してみます。

今回使うのは、Apache Bench（アパッチベンチ）です。これはApacheに標準についている、Webサーバの性能を計測するコマンドで、コマンドを実行するだけで計測ができます。

コマンドは、以下です。

ab -n 1000 -c 30 http://kusanagispeed.com/sample-page/

-nと-cはオプションです。-nは、送るリクエストの総数、-cは、同時に発行するリクエストの数 になっています。そして最後にリクエスト先のURLを記載しています。

通常のLAMP環境で、WordPressのサーバ速度比較（サーバの負荷テスト）

実行するコマンドはこちらになります。

ab -n 1000 -c 30 http://nokusanagispeed.com/sample-page/

それでは実行してみます。

実行が終わると、テスト結果が表示されます。
ここで見ていただきたいのが、「Requests per second」という部分です。

結果の画像を見ると、 72.65 [#/sec] となっています。これは1秒間で処理することができるリクエスト数を意味しています。つまり、LAMP環境の方では、1秒間に72.65のリクエストを処理できるということですね。

この数値は、対象のWebサイト等が「メディアに載る」「バズる」などで急激なアクセスが見込まれる場合には相応のサーバ環境やサーバスペックを用意しておかなければならないということになります。

KUSANAGI環境で、WordPressのサーバ速度比較（サーバの負荷テスト）

実行するコマンドはこちらになります。

ab -n 1000 -c 30 http://kusanagispeed.com/sample-page/

それでは実行してみます。

実行が終わると、テスト結果が表示されます。
「Requests per second」を見てみましょう。

結果の画像を見ると、今度は 111.23 [#/sec] となっています。
つまり、KUSANAGI環境の方では、1秒間に111.23のリクエストを処理できるということですね。

数値を比較すると、KUSANAGIの方がおおよそ 1.53倍 程度処理性能が高いということになります。

秒間で処理できる数値が大きいので、大量アクセスが来てもサーバが遅くなったりダウンしたりせずに対応できるということになります。

この2つの環境を用意する際には、特別なことはしていないのですが、純粋にこれだけの数値差が出るというのはかなりすごいことです。

まとめ：CMS高速化は、原理原則のサーバから！

今回、2つの環境を定量的に比較してきました。結果をあらためて整理すると、サーバ環境を変えるだけで、他の設定を一切いじらずに3.4倍の速度差が生まれるということです。

この結果を踏まえて、CMS高速化の打ち手全体を整理してみます。

施策	効果	難易度	コスト感
画像の圧縮・WebP化	△ 小〜中	低	ほぼ無料
キャッシュプラグインの導入	△〜○ 中	低〜中	無料〜数千円/月
不要プラグインの整理	△ 小	低	無料
CDNの導入	○ 中	中	数千〜数万円/月
PHPバージョンのアップデート	○ 中	中	ほぼ無料
サーバ環境の最適化	◎ 大	低〜中	低〜中
サーバスペックの増強（CPU・メモリ増設）	○ 中	低	継続的に増加

注目していただきたいのが、「サーバスペックの増強」と「サーバ環境の最適化」の違いです。

スペックを上げるのは手軽ですが、コストが膨らみます。環境そのものを最適化することは、追加コストを抑えながら処理性能の上限値を引き上げられる、もっともコスパの高い施策です。

社内にエンジニアリソースがなく技術的な対応が難しい場合でも、KUSANAGIマネージドサービスのように、サーバからWordPressまでをまるごと保守運用できる選択肢があります。まずはライトなご相談からでも、お気軽にご連絡ください。

また、今回の内容を動画にもしていますのでぜひご覧ください。