2018年9月11日に、エックスサーバーで、高速化＋大量アクセス耐性強化のための独自開発による新機能「Xアクセラレータ」の提供を開始しました。
また、それに先立つ 9月6日には、同じく表示速度の高速化機能である「ブラウザキャッシュ設定」機能の提供も開始しています。
もともと、エックスサーバーは共用サーバーの中でも CPU やメモリなどのスペックが非常に高く、サイトの表示速度もトップレベルです。しかし、同業他社も同様にどんどん高速化を図っていることもあり、業界トップを走るエックスサーバーとしても後れを取るか、と言わんばかりに、今回の高速化機能の提供を開始しました。
今回、この「Xアクセラレータ」と「ブラウザキャッシュ設定」を有効にした際の Webサーバーの応答状況、および WordPress の表示速度を計測してみましたが、確かにいずれの機能も高速化に大いに効果があることが確認できました。
以下に、「Xアクセラレータ」と「ブラウザキャッシュ設定」機能の特徴・メリットや利用上の注意点と、検証結果を解説していきます。
「Xアクセラレータ」と「ブラウザキャッシュ設定」の特徴
まず、新たに導入された 2つの機能が、実際にどういったものなのかざっと確認してみましょう。
「Xアクセラレータ」とは？
まず、「Xアクセラレータ」機能ですが、「Webサイトの表示速度向上」と「同時アクセス数の大幅拡張」の両方を行える機能です。
この「Xアクセラレータ」に、具体的にどのような技術が使用されているのかなどの情報は、残念ながら確認できないのですが、「速度向上＋大量アクセス対策」という効果と、設定方法についてのヘルプの情報から、「リバースプロキシ」を利用した機能であることが推測されます。
サイトのデータなどをキャッシュし、Webサーバーの代わりに、外部からのアクセスに対してデータを送り返す役割を果たすサーバー（※他にも多くの役割を持たせることができるが、ここでは省略）
通常は、外部からサイト表示のリクエストがあった際には、Webサーバーが応答して、データを返します。
しかし、この方式では、外部ユーザーと Webサーバーの間に、もう一つアクセスをさばくための代理のサーバーを設置し、そこにサイトのキャッシュデータを置くことによって、高速にデータを返す＋Webサーバーの負荷を軽減できる仕組みになっています。
「ブラウザキャッシュ設定」機能とは？
一方、「ブラウザキャッシュ設定」は、ユーザー側のブラウザに一度表示したデータをキャッシュ（一時保存）するように指示するデータを付与する機能です。
初回のアクセスに関しては、一通りデータを読み込むことになるため、速度は速くなりませんが、同じページや同じ画像などを二回目以降に読み込む際には、毎回サーバーからダウンロードせず、ブラウザにキャッシュされたデータを読み込むようになるため、表示の高速化につながります。
「Xアクセラレータ」は、エックスサーバー側にサイトのデータをキャッシュする機能ですが、この「ブラウザキャッシュ設定」は閲覧者側にサイトデータをキャッシュする、という違いがあります。両方の機能を併用することで、よりサイト表示の高速化が図られるわけです。
各機能の設定は 2段階で切り替えられる
なお、「Xアクセラレータ」と「ブラウザキャッシュ設定」には、サイトの「静的ファイル」のみ、または「全てのファイルを有効にする」（ただし、CSS と JavaScript を除く）、の 2段階を任意で選択することができます。
画像や動画ファイルなど、常に同じ、固定された状態で提供されるファイルのこと。
反意語は「動的ファイル」で、こちらは PHP など、ユーザーがアクセスするごとに新たにサーバー上で作られて、送り返されるファイルのこと。WordPressの場合、Webページの情報はアクセスごとに作られるため、この「動的ファイル」にあたる。
「Xアクセラレータ」の場合、サーバー側で「静的ファイル」は 2分間、「動的ファイル」は 1分間キャッシュされます。
キャッシュ機能のデメリット
サイトの高速表示＋サーバー負荷の軽減（大量のアクセスをさばける）と、いい事づくめのようですが、キャッシュ機能にもそれなりにデメリットはあります。
たとえば、「Xアクセラレータ」の場合、訪問者ごとに表示内容が異なるようなサイト（会員制サイトやショッピングサイト）等では、その都度サイトデータの構築を行う必要があるため、高速化や負荷軽減の効果は出にくいです。
また、特定のユーザーや特定の環境だけに公開しているページなどがある場合にも、リバースプロキシ上にキャッシュされてしまい、本来閲覧できないはずのユーザーがアクセスできてしまうこともありえます。
そういうサイトを運営している人は、「静的ファイル」のみの機能を有効にするか、OFF にするのがいいでしょう。
今回実施した測定条件の詳細
では、早速「Xアクセラレータ」と「ブラウザキャッシュ設定」の実力を、各種ツールで測定して結果を見ていきたいと思いますが、その測定を行った際の条件を以下に挙げておきます。結果だけ見たい人は、こちらをクリックしてください。
| 項目 | 詳細 |
|---|---|
| 利用プラン名 | X10 |
| WordPress のバージョン | ver.4.9.8 （比較する以前のデータは 4.9.5） |
| WordPress のテーマ | Twenty Seventeen |
| WordPress プラグイン | WP Multibyte Patch / Akismet / Hello Dolly |
| コンテンツ内容 | WPテーマユニットテスト （すべてのコンテンツをトップページに表示した状態） |
| 測定ツール | monitis 測定元サーバー（東京） |
| 測定期間 | 7日間 |
| 測定内容 （安定性） | httpリクエストへの応答状況 （60秒毎にリクエスト実施/10秒でタイムアウト）） |
| 測定内容 （表示速度） | WordPress サイトの表示速度 （20分ごとに計測を実施） |
コンテンツには、「WPテーマユニットテスト」というテスト用のデータを利用しています。テキストもほどほどの量があるほか、画像や Youtube なども貼り付けられているため、実際のブログなどに近いデータ量になっています。
プラグインに関しては、WordPress をインストールした際に導入済みのもので、それ以上の意味はありません。
Webサーバーの応答速度が爆速に！
最初に「Webサーバーの応答速度」について見てみましょう。
「応答なし回数」は、Webサーバーから応答が返らなかったり、大幅に遅延したりしたケースの回数で、回数が少ないほうが安定しています。
また、「平均応答速度」「最速」「最遅」は、Webサーバーから応答が返ってくるまでの速度で、数値が小さいほど応答が速いため、安定性も高いことを意味しています。（単位はすべて「ミリ秒」）
各機能の違いもチェックするため、順次機能を ON にしていきました。
途中ちょっと勘違いしてしまって、入れ子状態になってしまったのですが、以下のような流れで設定を ON にしました。
- ブラウザキャッシュ：静的ファイルON
- Xアクセラレータ：静的ファイルON
- Xアクセラレータ：全ファイルON
- ブラウザキャッシュ：全ファイルON
- mod_pagespeed：ON
なお、最後にエックスサーバーで以前から利用可能な高速化機能である「mod_pagespeed」も有効にしてみました。（以下のグラフでは見切れています）
Google社により開発された拡張モジュールで、ファイルを圧縮してデータ転送量を削減したり、同種のファイルを一まとめにしたりして無駄な通信を削減するなどの最適化処理を行う機能。
これにより、データ転送量が減少し、かつページの読み込み時間を短縮できるため、Webサイトの表示速度を高速化できる。
Webサーバーの応答速度計測結果
| 応答なし 回数 | 平均表示 時間 | 最速 | 最遅 | |
|---|---|---|---|---|
| 元 | 0 | 296.2 | 258.0 | 5271.0 |
| ブラウザキャッシュ 静的ファイルON | 0 | 291.0 | 139.0 | 8926.0 |
| Xアクセラレータ 静的ファイルON | 0 | 189.3 | 142.0 | 8047.0 |
| Xアクセラレータ 全ファイルON | 0 | 121.6 | 51.0 | 6013.0 |
| ブラウザキャッシュ 全ファイルON | 0 | 121.7 | 51.0 | 8821.0 |
| mod_pagespeed ON | 1 | 123.8 | 51.0 | 89.7 |
※単位は「ms」（ミリ秒） ※無断転載禁止
今回の比較対象になっている元のデータ（表の一番上のデータ）は、前回の CPU ・メモリなどのスペックアップ時に計測したデータで、高速化機能は利用していない、いわゆるスッピン状態です。
グラフを見てもわかる通り、「Xアクセラレータ：静的ファイル」をONにしたときに最も変化が見られます。一気に平均応答速度が上がっていますね。
また、「Xアクセラレータ：静的ファイル」をONにしたときには、すべての値においてさらに高速化が見られています。特に、最速の値が、これ以降 51ms で固定されているので、これが現状での最速の応答値と思われます。
そして、なぜか「ブラウザキャッシュ：全ファイル」を ON にした段階で、最遅の値が戻ってしまっていますが、これはたまたまなのか、機能による影響なのかはちょっとわかりません。平均応答速度がほぼ変わらないことから考えると、たまたまブレが大きかっただけのような気もします。
最後に、「mod_pagespeed」を ON にしたところで、平均応答速度が 2秒ほど伸びていますが、最遅の値が 2桁にまで縮まりました。大幅なブレがなくなるのは、非常に大きいですね。
いずれの値においても、高速化機能を利用していない状況よりかなり良くなっていますので、これらの機能の効果は非常に高いと言えるでしょう。
WordPressの表示はブレが少なく安定化！
続けて、WordPress を使用したサイトの表示速度がどれくらいかを確認してみましょう。こちらは、単に数値が小さいほうが速いです。
こちらも上と同様の順番で、順次機能を ON にしていっています。
WordPressの表示速度計測結果
| 応答なし 回数 | 平均 表示時間 | 最速 | 最遅 | |
|---|---|---|---|---|
| 元 | 0 | 1.71 | 1.28 | 17.11 |
| ブラウザキャッシュ 静的ファイルON | 0 | 1.83 | 1.33 | 6.74 |
| Xアクセラレータ 静的ファイルON | 0 | 1.81 | 1.23 | 6.25 |
| Xアクセラレータ 全ファイルON | 0 | 1.77 | 1.22 | 3.75 |
| ブラウザキャッシュ 全ファイルON | 0 | 1.90 | 1.23 | 3.06 |
| mod_pagespeed ON | 1 | 1.95 | 1.34 | 12.63 |
※単位は「ms」（ミリ秒） ※無断転載禁止
こちらも比較対象にしている元のデータ（表の一番上のデータ）は、前回の CPU ・メモリなどのスペックアップ時に計測したデータで、高速化機能は利用していない、いわゆるスッピン状態です。
劇的に変化があった、Webサーバーの応答速度に比べて、WordPress の表示速度に関しては、全体的にそれほど変わりがありません。平均速度もほんの少し遅くなっていますが、前回とは収容サーバーも違いますし、その差も 0.06秒～0.24秒なので、まあ誤差の範囲と考えてもいいレベルかもしれません。
よい数値が出ているのは、ちょうど中ほどの「ブラウザキャッシュ：静的ファイル」＋「Xアクセラレータ：全ファイル」の組み合わせでした。
この組み合わせでは、最速と最遅の値でスッピン状態よりも良い数値が出ており、特に最遅が半分ほどになっているため、ブレがかなり減っていることがわかります。
一方、Webサーバーの応答速度では、ブレが非常に小さかった mod_pagespeed の ON により、平均表示速度、および最遅が遅くなってしまいました。原因は残念ながらよくわかりませんでしたが、もしかしたら機能同士の相性のようなものがあるのかもしれませんが、他のコンテンツやもう少し長いスパンでの検証を行えば何か見えるかもしれませんね。
まとめ
以上、「Xアクセラレータ」と「ブラウザキャッシュ」の実力について検証結果を見てみましたが、Webサーバーの応答速度に関しては、どちらも非常に有効でした。
一方、WordPress の高速化に対しては、必ずしもすべて有効にすればいいというわけでもないかもしれません。サイトのコンテンツによって、最適な組み合わせが変わる可能性もありますので、実際に自分のサイトである程度の日数をかけて調整するのがいいかもしれません。
とはいえ、エックスサーバーはもともと速い上に、これらの機能をうまく利用することで、さらに高速化を実現できることは確認できましたし、今回は以前のデータと比較するために、PHP 7.0 を使用しましたが、より高速な PHP 7.2 を利用すると、さらなる高速化が望める可能性が高いと思います。
今やレンタルサーバー業界は「高速化競争」の真っ只中ですが、さすが業界トップを走るエックスサーバー、素晴らしい機能を提供してくれました。
エックスサーバーは、10日間無料でお試しできますので、ぜひその速さを体験してみてください。
