- サイトデザイン工事中です。ご意見をお寄せください。
- 赤色のリンクは、まだ日本語Codexに存在しないページ・画像です。英語版と併せてご覧ください。（詳細）
WordPress の最適化/高トラフィック WordPress サイト向けのヒント
WordPress が大量のトラフィックにも対応できるかどうか、疑問に思ったことはありますか？人気サイト、または大量の投稿を含むサイトを作成したいと考えていますか？ブログに書いたことが、はてブやスラッシュドット、その他の人気サイトで注目を集め、多数のアクセスがあるかもしれないと思ったことがありますか？多数のアクセスが会った場合、WordPress がちゃんと対応できるか、それともサイトが落ちてしまうか、知りたいと思っていますか？ WordPress はこういった状況で、適切に動作するのでしょうか。
簡単な答えは、「イエス」となります。でもこれは、条件付きの「イエス」です。もし大量のトラフィックをさばく可能性がある場合は、WordPress をパブリッシングプラットフォームとして選択することを決断する前に検討し理解すべきことがたくさんあります。本格的な高トラフィックサイトの場合は、「ごく普通の共用レンタルサーバー」上の WordPress では間に合わないでしょう。
高トラフィックサイトへの予想されているトラフィックに対する準備を整えるには、WordPress を選択する/en 前に、（WordPress が依存する）サイトのサーバーおよびサーバーソフトウェアが、トラフィックに見合うものかどうか確認する必要があります。
WordPress の最適化もご覧ください。
目次 |
ハードウェアによる制限
「WordPress が高トラフィックに対応できるでしょうか？」というのは間違った質問です。事実上、どんなブログプラットフォームでも（実際には、どんなウェブアプリも）そのソフトウェアが依存しているハードウェア/en にさばけるだけのトラフィックにしか対応できません。
大量のアクセスをさばけなくなる物理的な2つの壁は、以下の通りです。
プロセッサの限界
高トラフィックサイトのホスティングは、大量のトラフィックがもたらすサーバーの内部リソースへの要求との戦いになります。サーバーへの一般的な要求に見合うだけの十分なプロセッサ能力とメモリリソースを必ず確保しておきましょう。
サイト公開の状況によっては他にも依存する要素が存在する可能性もありますが、WordPress のデフォルト要件は以下の通りです。
MySQL
多くのブログソフトや Web アプリと同様、WordPress は出力を生成するためのデータの保存のため MySQL に依存しています。WordPress が MySQL へデータ読み書きのリクエストを送るたび、サーバーに負荷がかかります。
WordPress 自体にも機能を実行するのに必要なトランザクションを低減するための最適化が絶え間なく施されています。しかし、サイト用のプラグインやテーマの開発のやり方によっても MySQL への負荷が変わってきます。トラフィックが大量にある状況では、データベースへ多数の同時接続によってサーバーへの過負荷が発生してしまうことがあります。この場合、サーバーへの接続が完了せず、訪問者のブラウザにはよくある "Connection timed out" エラーメッセージが表示されます。
多くの場合、MySQL の接続速度は MySQL の設定の調整や動作過重となっているサーバーのメモリやプロセッサ能力の強化によって改善できます。また、クエリキャッシングや適切なインデックスの利用により、MySQL のパフォーマンスを向上することもできるでしょう。サイトはそれぞれ異なっているので、すべてのケースに使える唯一の回答というのはありません。
Web サービス
WordPress は Web サーバー中立のアプリケーションです。つまり、数多くの様々なプラットフォーム上で動かせるということです。Apache と Linux は WordPress を稼働するのに最も堅牢なプラットフォームですが、PHP と MySQL に対応しているサーバーならどんなものでも大丈夫です。
WordPress を運営する強力な環境を用意するには、ホスティングサービスがこれらのプラットフォームの最新安定板を使っていることをしっかり確認しましょう。
WordPress のコードを解釈する言語である PHP を動かすために最適な方法を選択することでも、サーバーのパフォーマンスを改善できるでしょう。CGI モードのサーバーでは、訪問者がリクエストした PHP の各ファイルに対して PHP プログラムの新しいインスタンスが作られます。共有モジュールモード（ISAPI）では、PHP への各アクセスに対して単一のライブラリインスタンスが利用されます。Apache 2 のマルチスレッド実装については多くの誤解があります。デプロイの前には独自のテストを行いましょう。一般的に、Apache 2 のパフォーマンスを mod_php で事前にフォークしておくのが最も安定した方法です。両方の方法にはそれぞれ利点と欠点があります。どちらを選ぶかを選択するときには、トラフィック量およびそれによって発生するサーバーへの負荷を留意しておきましょう。
ネットワークの限界
お使いのサーバーのインターネット接続の質によっては、一定のページ数をあなたが望むスピードで表示する事はできないかもしれません。
あなたのサーバーのネットワーク提供者（ホスティングサービスまたは ISP）は、たいていの場合サーバーと内部ネットワークをイーサネットアダプターで接続しています。アダプターは一般的に、10Mb/s、100Mb/s、1Gb/s などの一定の標準最高速度で動きます。どんな種類のファイルであっても、お使いのサーバーがこのスピードよりも速く転送するのは物理的に不可能です。また、さらにサーバーの速度を下げることにつながる転送レート障害要素が他にもあります。
まず、これらの数字は理論上のものでしかないという事を理解することが大切です。サーバーのネットワークアダプターのスピードについては特にそうです。実際にサーバーがアダプター規定の最高レートでファイルを転送できるということは決してないでしょう。これは、サーバーが実際に転送するデータに加えて、ネットでサイト読者にデータを届けるために必要なさまざまなルーティング情報を送受信していることによります。この "ネットワークオーバーヘッド" があるため、全帯域幅の一部しか実際のファイル転送に使うことができません。
次に、サーバーはネットワークプロバイダの施設にある、ネットワークアダプター以上に転送レートを制限する色々なデバイスに接続されている可能性が高いでしょう。ネットワークプロバイダは上限のある帯域幅を一カ所にある数多くのサーバーに割り当てなくてはならず、帯域幅を共有する必要があるため、こういったデバイスが設置されています。
ネットワークプロバイダによっては、データを "一局集中" させることを許可している場合もあります。これは、サイトコンテンツへのアクセスが集中した際、あらかじめ設定された転送スピードを一時的に超えても良いようになっていることを意味しています。ネットワークプロバイダのハードウェアは、こういったことが必要になった場合にそれが分かるように設計されています。プロバイダによってはこの機能に追加料金を課金したり、無料で利用できたり、機能を提供していなかったりとさまざまです。ご自分で確認してください。
利用ネットワークの転送速度
高トラフィックサイトにおいて接続の帯域幅がどうして大事なのかを理解するため、ちょっと計算してみましょう。
あなたのサイトに一日100,000ヒットがあると仮定します。この計算のために、1ヒットが1回のデータ転送だとします。この1回は、ファイル1つのみの場合も、複数のファイルを含む1ページ全体の場合もあるかもしれません。平均すると、一日100,000ヒットというのは毎秒約1.16ヒットという計算になります。
また、平均的な1ヒットには160KBの転送データが含まれているとします。HTML、画像、CSS、ダウンロードファイル、などです。毎秒、サイトは 190KB のデータ（160KB/ヒット * 1.16 ヒット/秒）を転送していることになります。190KB/秒の合計は、約 1.5MB/秒の持続スループットに換算されます（注: KB = キロバイト、Mb = メガバイトのこと。ほとんどのネットワーク速度はファイルサイズをバイトで計算した、バイト/秒で評価されます）。多くのネットワークプロバイダでは、サイトの転送レートをだいたいこのレベルに制限しています。少し高かったり低かったりする場合もあるでしょう。しかし、各ユーザーがちょうどよくバラバラに訪問した場合のみ、安定したレートを持続できるのです。
通常、複数のユーザーが一度にサイトへアクセスする状況があるはずです。また、一日の間にだれもアクセスがない時間帯もあるでしょう。もし毎秒10人のユーザーが同時にデータを取得し、このレートが長い間続くとしたら（高トラフィックのサイトには珍しいことではありません）、この同時接続についていくためだけに15MB/秒の帯域幅が必要になります。
ネットワークアダプタの理論的な最高速度が10MB/秒だとしたら、すでに需要がキャパシティ以上になってしまいます。WordPress にはまったく関わりなく、です。
10万ヒットのサイトでなくても、この問題は発生します。3万6千ヒットだけでモ、このレートで回線を1時間維持必要が出てきます。もし閲覧者が特定の時間帯に集中したる場合（もしくはコメントスパムボットが集中的に何度もサイトにアクセスしてコメントしようとした場合）、リクエストのドロップが多数発生する可能性もあります。
100MB/秒の回線なら、70の同時アクセスを同じダウンロードレートで処理できますが、高額な費用を払わない限りネットワークプロバイダがこれほどの帯域幅を完全に使わせてくれることはおそらくないでしょう。現在の共有サーバーでは、通常このような環境は得られません。
転送量の上限
動画、音声ファイル（ポッドキャスト）、大量の写真アーカイブなどをホスティングしている場合、転送量オーバーが考えられます。ホスティングサービスのプランには、たいてい転送データ量合計の上限が決められていて、その場合データ量を超えると超過データ分の金額を請求されます。1MBごとに100円といったような高価な設定もあります。
この設定の場合、データ転送量上限を超過後に20MBのデータがダウンロードされた場合、それだけで2000円の課金をされるということです。
通常、この転送量上限が多いほどホスティングプランが高価になります。上限なしの高価なプランを用意しているホスティングサービスもありますが、それでも超過課金をされた場合よりは高くつかないはずです。
サイトのパフォーマンスを最大限に引き伸ばし、超過課金をされるのを防ぐために人気のある方法は、コンテンツデリバリネットワーク（CDN）をサイトと共に使うことです。手頃な値段で、利用した分だけ払えばよいソリューションがいくつもあります。CDN とオフローディングについて詳しくは、オフローディング / en のページを読んでください。
高トラフィックへの対応法
神戸牛と同じく、WordPress は適切な条件の下に置かれたときに最高の力を発揮できます。以下に、高トラフィックの問題のために WordPress のパフォーマンスが悪い場合に試すべきことをいくつかご紹介します。
W3 Total Cache
W3 Total Cache（W3TC）は最も新しい世代の WordPress パフォーマンスプラグインです。これは、Web 開発の権威による研究をもとに、最適化された WordPress サイトでのユーザーエクスペリエンスを提供するために生まれました。W3TC は、サーバーサイドでの最適化能力と、クライアントサイドのパフォーマンスにおいて他のツールとは違っています。デフォルトでは含まれない以下のような機能を追加します。
- ページキャッシュ: これまでのプラグインと同じく、W3TC も静的 HTML バージョンページを生成し、サーバーが PHP を走らせることなくページを表示できるようにします（反応時間をスピードアップします）。コメントがついたりページが編集されると自動的に更新します。
- ファイル縮小（Minify）: HTML、CSS、JavaScript ファイルから必要のない文字を取り除き、それぞれひとつにまとめ、キャッシュファイルに HTTP 圧縮を行います。
- データベースキャッシュ: データベースクエリ（オブジェクト）もキャッシュされ、多くのサイトではページの生成にスピードアップが図れます。ページの生成は大量のコメントがつくサイトでは問題となることが多くあります。
- ヘッダー: W3TC は Web ブラウザでのファイルのキャッシュをコントロールするレスポンスヘッダ（Etag, cache-control, expires）を管理します。これにより、サーバーの負荷を軽減し、ユーザーの体感速度を高めます。
- コンテンツデリバリネットワーク（CDN): ホスティングアカウントからのリソースをオフローディング / en するために、CDN を使いましょう。W3TC は画像、CSS、JavaScript などの静的ファイルへのリクエストを高パフォーマンスのサーバーネットワークへ転送することができます。それから、読者の現在地に最も近いサーバーを自動的に選択して高速なファイルのダウンロードを可能にします。
サーバーがひとつでも複数でも、共用サーバーでも専用サーバーでも、W3TC は WordPress を最適化するためのオプションを提供します。有効化すると、安全なデフォルト設定で動作を開始します。
WP Super Cache
WP Super Cache は WordPress 用の静的キャッシングプラグインです。Apache が直接提供する HTML ファイルを生成するため、比較的重い PHP スクリプト処理を省くことができます。このプラグインを使うことでブログを大幅にスピードアップできるでしょう。
このプラグインは Ricardo Galli Granada 作の WP Cache プラグインのフォーク版です。WP-Cache は WordPress ページをキャッシュし、データベースにアクセスすることなく配信します。あいにく、この方式はキャッシュされたファイルを送るため PHP エンジンを読み込む必要があるため、現在はおすすめできません。
WP Super Cache はこの問題を解決しています。このプラグインをインストールすると HTML ファイルが生成され、PHP を一行も実行することなくページを表示します。キャッシュされた HTML ページが表示される速度は、サーバーが画像ファイルを表示できるスピードと同じくらいです。トラフィックの多さに対応するため苦心していたり、ブックマークサイトや人気サイトからリンクされることがあるようなら、このプラグインをおすすめします。
WordPress プラグインや画像の無効化、限定
WordPress ブログへのトラフィックが大量に発生した場合、ブログのコードやデザイン要素へのアクセスも同時に高まります。
例えば、ブログのデザインを作り出すため、フロントページから8つの画像が呼び出されているとしましょう。この数を、ページを構築するのに必要なテンプレートファイルの数に加えます。header.php，sidebar.php、footer.php，そしてコンテンツエリア（index.php など）が最低限でも必要です。つまり、サイト内のファイルへの呼び出しが4回増えるわけです。100名の読者が来た場合、ファイルが合計1200回呼び出されることになります。1000名なら12000回です。これにより、帯域幅とサーバーの活動が上昇します。
WordPress プラグインも、テーマによって呼び出されるファイルに含まれます。プラグインファイルは呼び出されるとデータベースにクエリを送り、ブログの情報を生成します。プラグインが多いほど、データベースクエリも多くなると言えるでしょう。
これらのアクセスファイルとデータベースクエリに訪問者の急増をかけあわせれば、サイトはかなりたくさんのリクエストをさばくことになります。
トラフィックが急増した場合、テーマテンプレートや CSS ファイルを編集し、アクセスしている画像ファイルの数を減らしてみましょう。
また、プラグインを一時的に無効化することでファイルへのアクセスやデータベースクエリを減らすことができます。
プラグインを眺めて、使わなくても構わないようなものがないか考えてみましょう。ファイルやデータベースへのアクセスをできるだけ最小限に抑えましょう。トラフィックの増大が収まったら、プラグインを元に戻してもいいでしょう。
新しいホスティングサーバー
これを聞くのは耳が痛いかもしれませんが、単によりパワフルなサーバーが必要ということもありえます。
以下は、高トラフィックによる問題が発生している場合の簡単なアップグレードステップ概要です。
- 共有サーバーで問題が起こっている場合、VPS（仮想専用サーバー）へのアップグレードをお試しください。
- VPS で問題が起こっている場合、専用サーバーへのアップグレードをお試しください。
- 専用サーバーで問題が起こっている場合、より高スペックな専用サーバーへのアップグレードをお試しください。
- 高スペックな専用サーバーで問題が起こっている場合、複数のロードバランサ（負荷分散装置）サーバー導入の検討についてホスティング提供者と話し合ってみてください。
すべての場合において、利用しているサーバーがネットワークプロバイダの能力以上の性能を発揮することはできません。ネットワークプロバイダがあなたのサイトに必要な帯域幅を提供していない場合、上限を上げるよう交渉するか、トラフィックに必要な帯域幅を確保できる他のプロバイダに移るしかないでしょう。
最新英語版： WordPress Codex » High_Traffic_Tips_For_WordPress （最新版との差分）
