WordPress自体のチューニングが必要な理由と高速化の基本的な考え方:とにかく速いWordPress(1)
企業のCMSサイトやオウンドメディアなどエンタープライズ用途での利用が増加しているWordPressの高速化について解説する連載。初回は、WordPressの高速化が求められる背景や、WordPress高速化の基本的な考え方であるページのロード時間とその構成要素、1秒当たりの同時アクセス数について解説します。
WordPressの高速化が求められる背景
「WordPress」は世界中で最も使われているCMS(Contents Management System)のソフトウエアです。「W3Techs」の統計によると、世界中のWebサイトの約24%、CMSソフトウエアを利用したWebサイトの約6割で利用されています(参考「Usage statistics and market share of WordPress for websites」)日本国内に限定すると、CMSソフトウエアを利用したWebサイトの約75%がWordPressを使っています(参考:Distribution of content management systems among websites that use Japanese)。
WordPressの特徴である高い開発生産性や、Web標準を意識したソースコード、デザインやユーザビリティに優れる管理インターフェースなどのメリットから、企業のCMSサイトやオウンドメディアなどエンタープライズ用途での利用も増加しています。
一方で、WordPressはPHP+MySQLベースで構成されている動的なCMSソフトウエアですので、静的なHTMLで構成されているWebサイトに比べると、動作速度の点では不利です。
しかも、近年、CPUの開発ロードマップでは、周波数(動作クロック)4GHz近辺を上限にコア数を増加させる傾向になっていることから、WordPressのような単一プロセス逐次実行の処理系では、これまでのように「CPUを中心とするハードウエアの進化によって処理速度が向上する」ことは期待しづらくなっており、WordPressの絶対的な動作速度は向上しづらい環境になってきています。
このような背景により、WordPressを利用するWebサイトにおいては、「いかに速くWordPressを動作させて、PV獲得の機会を失わないようにするのか」という観点から、また、ユーザーエクスペリエンスや検索エンジン最適化の観点からもWordPressの高速化が重要視されるようになってきているのです。
本連載の概要
本連載「とにかく速いWordPress」では、WordPressを高速に動作させるための考え方とテクニックを解説していきます。
具体的に言うと、サーバーOSとしてはCentOS 7をベースに、今話題のHHVM(HipHop Virtual Machine)や、nginx、Apache、PHP、MariaDBなどのミドルウエアから、WordPress固有の高速化に関するテクニック、ボトルネックの発見方法まで取り扱います。後半では、筆者が開発しているWordPress仮想マシン「KUSANAGI」の技術についても解説する予定ですので、どうぞ楽しみにしてください。
今回は初回ということで、WordPress高速化の基本的な考え方について説明します。
なお、本連載「とにかく速いWordPress」では、WordPressの高速化に関する話題を取り扱いますが、CentOS 7、HHVM、nginx、Apache、PHP、MariaDBなどに関する知識やテクニック、高速化に関する考え方は、WordPress以外のPHP+MySQLベースの他のソフトウエアに対してもそのまま活用いただけますので、ぜひ参考にしていただければと思います。
WordPressの高速化とは何か
WordPressの高速化には、主に二つの領域があります。
一つは、サーバーサイドでのWordPressの高速化です。具体的には、次の図のように、ブラウザーから送信されるHTTPリクエストをサーバーサイドのWordPressが処理してHTMLなどを生成し、ブラウザーにHTTPレスポンスとして戻るまでの処理時間に関する領域です。これは、ブラウザーがHTTPリクエストを送信してから、レンダリングを開始するまでの領域になります。
もう一つは、フロントエンドでの描画の高速化です。具体的には、HTTPレスポンスとして最初に受信するHTMLを起点として、CSSの展開やJavaScriptの実行を含むブラウザーでのレンダリングにかかる処理時間に関する領域です。
本連載では、前者の、主としてサーバーサイドでのWordPressの高速化について取り扱います。
ページのロード時間と1秒当たりの同時アクセス数
「ページのロード時間」とは、ブラウザーがHTTPリクエストを送信してから、サーバーサイドでWordPressによる処理が実行されて、ブラウザーにHTTPレスポンスとしてHTMLなどが受信されるまでの時間を表します。
「1秒当たりの同時アクセス数」とは、WordPressが1秒間に実行処理できる回数を表します。
ページのロード時間と1秒当たりの同時アクセス数は相関します。
仮に、1CPU(1コア)のアプリケーションサーバーでWordPressが動作しているとして、ページのロード時間が500ms(ミリ秒=1000分の1秒)であった場合、大ざっぱに考えると、1秒当たりの同時アクセス数は1000msを500msで除算して「2」となります(なお、ここでは話を単純化するために、ページのロード時間から通信時間を無視しています。また、WordPressの実行時間については、瞬間的に1アクセスのみが発生した場合の最大性能で考えることにします)。
WordPressを高速化して、ページのロード時間を50msまで短縮できたとすると、1秒当たりの同時アクセス数は、1000msを50msで除算して「20」になります。この状態で、サーバーのCPUのコア数を4に変更すると、1秒当たりの同時アクセス数は「80」になりますが、ページのロード時間は50msのまま変わりません。なぜなら、WordPressの実行プロセスは直列処理であり、コア数が増加しても1つの実行プロセスそのものは並列に処理されないためです。
ここから次のことが分かります。
- ページのロード時間を短くすると、それにほぼ反比例して、1秒当たりの同時アクセス数が増加する
- CPUのコア数やフロントに並べるアプリケーションサーバーの数を増加させると、それに比例して1秒当たりの同時アクセス数は増加するが、ページのロード時間は短縮しない
実務の中で、「ちょっとWebサイトが遅いのでCPUのコア数の多いサーバーに移転したらどうですか?」とか「オートスケールを設定してスケールアウトできるようにしたらどうですか?」という話が出てくることがあります。確かに、どちらの場合であっても、1秒当たりの同時アクセス数は増加しますが、ページのロード時間そのものは短縮しません。つまり、遅いWebサイトが速くなるわけではないのです。ちょっとした笑い話になっています。
ページのロード時間は、ブラウザーでレンダリングが開始されるまでの時間ということもできますから、ユーザーエクスペリエンスや検索エンジン最適化の観点からも、1秒当たりの同時アクセス数のベースになるという観点からも重要です。
ページのロード時間の構成要素
次の図に、ページのロード時間を構成する各要素を示します。これらの各要素をそれぞれ高速化させることによってWordPressを高速化させていきます。
【1】HTTPリクエストの通信時間
ブラウザーからHTTPリクエストが送信されてアプリケーションサーバーに到達するまでの時間です。
【2】PHPの実行時間
アプリケーションサーバー上でWordPressを構成するPHPの実行にかかる時間です。
【3】MySQLの実行時間
アプリケーションサーバーもしくはDBサーバー上でSQLクエリの実行にかかる時間です。
【4】翻訳処理の実行時間
WordPressは、もともと英語圏で開発されたソフトウエアですから、メッセージに関しては全て英語が基本になっています。私たちが見ている管理画面などでの日本語のメッセージは、全てリアルタイムの翻訳処理がされた結果です。翻訳処理のコスト(時間)は英語版以外のWordPressでは、比較的大きなものになっているため、項目を分けています。厳密にはPHPの実行時間の一部です。
【5】HTTPレスポンスの通信時間
アプリケーションサーバーからのHTTPレスポンスがブラウザーに到達するまでの時間です。
ページのロード時間短縮が重要
本連載のWordPressの高速化では、主としてサーバーサイドでのWordPressの高速化についての話題を取り扱います。サーバーサイドでのWordPressの高速化については、ページのロード時間と1秒当たりの同時アクセス数の概念を理解することが重要です。
中でもページのロード時間を短縮させることは、ユーザーエクスペリエンス、検索エンジン最適化の観点から、また、1秒当たりの同時アクセス数のベースになるという観点からも重要です。
ページのロード時間は、各構成要素に分解して理解することができます。ページのロード時間の各構成要素それぞれを高速化させることがWordPressの高速化になります。
次回からは、具体的なWordPress高速化の手法について解説していきます。
筆者紹介
中村けん牛
1971年栃木県生まれ。中学1年生で電波新聞社の『マイコンBASICマガジン』にプログラムを寄稿して以来、プログラミング歴30年。早稲田大学法学部を卒業後、野村證券に入社。公認会計士第二次試験合格。2002年にプライム・ストラテジー株式会社を設立、代表取締役に就任する。2005年にPT. Prime Strategy Indonesiaを設立して以来、アジアでのITビジネスに携わる。執筆監訳書籍に『WordPressの教科書』シリーズ(SBクリエイティブ)、『詳解 WordPress』『WordPressによるWebアプリケーション開発』(ともにオライリー・ジャパン)などがある。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
httpd.confによるWebサーバの最適化
Webサーバのチューニングには、いくつかの段階がある。今回は、httpd.confの修正によるApacheの最適化について説明する。(編集部)Apacheパフォーマンス・チューニングのポイント
Apacheをチューニングすることにより、Webサイトのパフォーマンスをより向上させることができる。しかし、その前に何をチューニングすべきなのかを見極める必要がある。Apacheパフォーマンス・チューニングの実践
前回、ボトルネックになり得るポイントの検討やベンチマークツール「ab」によるパフォーマンス・チェック方法を紹介した。今回はそれらを基に、Apacheのチューニングを行っていく。MySQLの高度な管理とチューニングテクニック
本連載もついに最終回。今回はMySQLサーバの運用・管理に必要な状態監視、チューニング、バックアップ、セキュリティについて解説する。以下のテクニックを駆使すれば、MySQLをさらに安定稼働させられるだろう。安全を考えてPHPの実行時設定を調整する
PHPを初期設定のまま使うと、いろいろ問題が起こる可能性があります。今回は、問題の発生を未然に防ぐ設定法をいくつか紹介します。(編集部)- 「/proc」によるLinuxチューニング [前編]:/procで理解するOSの状態
Linuxの状態確認や挙動の変更で重要なのが/procファイルシステムである。/procの概念や/procを利用したOSの状態確認方法を解説する