WPMLが商用化されて以来、wpml.orgははるかに多くのトラフィックを処理しています。2週間前、サーバーは95%の負荷で稼働し、応答時間は10秒を超えていました。W3TCを導入したことで、負荷は5%に戻り、応答時間は約300msになりました。
ご存じない方のために説明すると、W3TCはサイトパフォーマンス向上のためのプラグインです。ページキャッシュ機能が含まれていますが、それはほんの始まりにすぎません。基本的なページキャッシュに加えて、JSおよびCSSファイルの縮小、すべての圧縮、そしてCDN（コンテンツ配信ネットワーク）の実行も行います。これらの機能を組み合わせることで、サイトを大幅に高速化し、複雑なWordPressサイトでも大量のトラフィックを処理できるようになります。
WordPressサイトにとって非常に重要である理由
百聞は一見に如かずです。以下は、キャッシュを一切使用しない場合のサイトの読み込み状況です（Pingdom Toolsで生成）。
これが恐ろしいと思うなら、実際はさらに悪かったことを覚えておいてください。この読み込み時間のグラフは、サーバーが実際に5%の負荷で稼働しているときに取得されたものです。キャッシュなしで実際に稼働していたとき、サーバーは95%の負荷で熱を持ち、処理時間はさらに長くかかっていました。最初のバイトが出力されるまでに、このグラフに見られるような1/2秒ではなく、5秒かかりました。
ホームページを完全に表示するために、サーバーは77個のファイルを送信する必要がありました。サーバー負荷5%で実行されているこのグラフでさえ、30秒でタイムアウトして終了しています（赤い線を参照）。
これは、ずさんなプログラミングや不適切な設計手法のせいでしょうか。いいえ、違います。
WordPressの強みはモジュール性にあります。好きなテーマを選び、プラグインを自由に組み合わせることができます。つまり、これらはそれぞれ独立して開発され、独自のリソースで実行されるということです。有効化するプラグインの多くには、複数のCSSやJavascriptファイルが含まれており、PHPやMySQLの処理に影響を与えます。手動で最適化することもできますが、それではこの素晴らしいモジュール性が失われ、振り出しに戻ってしまいます。
Pingdomのツール、またはその他のページ読み込み時間測定ツール（それ用のFirefoxアドオンもあります）でサイトをテストしてみてください。どのファイルがどの順序で読み込まれるかを確認します。CSSファイルが画像や他のCSSを読み込み、各ページで大量のJavascriptファイルが読み込まれていることに気づくでしょう。
期待を高めるために、W3TCのあらゆる機能を駆使して達成した結果をご紹介します。
ここに表示されている数字は正確です。ページを表示するために取得されるファイルは合計28個です。5つのファイルはwpml.org（自社サーバー）から取得され、残りはCDN（コンテンツ配信ネットワーク）から取得されます。このページを配信するためにPHPが処理する必要があるのは、キャッシュ内にあるかどうかの確認といくつかの小さな確認だけで、ほとんど何もする必要がありません。
ページ全体が2秒未満で読み込まれ、サーバー上で測定できないほどの負荷しかかかりません。私たちも満足し、訪問者も満足し、Googleさえも満足しています。
ステップ1）ページキャッシュ
最初に行うべき最も基本的なことは、ページキャッシュを有効化することです。Performanceに移動し、W3TCを有効化してPage Cachingセクションを設定します。
ページキャッシュについては、基本的な設定のままにしました。追加したことの1つは、W3TCがWPMLクライアントアカウントやWPMLのダウンロードに干渉しないように、クライアントアカウントとダウンロードのセクションをページキャッシュから除外したことです。
オペコードキャッシュを使用している場合、W3TCはこれを利用してサイトをさらに高速化します。私たちは使用していませんが、キャッシュされていない複雑なPHP処理を実行している場合は価値があります。
ステップ2）縮小 – CSSとJavaScriptのパッケージ化と圧縮
テーマやプラグインが追加するすべてのCSSおよびJSファイルを覚えていますか。今こそ、それらが引き起こしている負荷を修正する時です。
縮小機能は、複数のリソースファイルを収集し、1つのファイルにパッケージ化して圧縮します。その結果、何十もの小さなファイルではなく、1つの大きなファイルになります。
合計サイズが50%しか縮小されない場合でも、これによって節約される負荷は膨大です。ブラウザが複数のHTTPリクエストを発行して多数の小さなファイルを取得する代わりに、1つのリクエストを発行してそれらをすべてまとめて取得します。この変更は、特に（CSSやJSをまだキャッシュしていない）新規訪問者に対するサイトの応答性向上に最も貢献する要素と言えるでしょう。
ページ上部にあるHelpボタンをクリックします。W3TCがサイト全体をスキャンし、リソースファイルを検索します。その後、結合するファイルを選択できます。通常はすべてを選択できますが、読み込み順序が変わる可能性があるため、操作には注意を払う必要があります。
縮小するCSSおよびJSファイルを選択したら、その順序が正しいことを確認する必要があります。
CSSファイルの場合は、リスト内でファイルを上下にドラッグします。
このリストに表示される順序は、縮小機能を使用せずにCSSファイルが読み込まれる順序と一致している必要があります。これはHTMLのページソースで確認できます。
Javascriptファイルは少し複雑です。順序を間違えるとJSエラーや機能の破損につながるため、ここでは読み込み順序がさらに重要になります。
W3TCでは、どのJSファイルをヘッダーセクションに配置し、どのファイルを本文に配置するかを選択できます。たとえば、Googleアナリティクスのスクリプトは直前に配置し、jQueryは最初に（そして縮小リストの外部で）実行する必要があるためヘッダーに配置します。
ステップ3）コンテンツ配信ネットワーク（CDN）
私たちにとって、さらに素晴らしいのは、見事に機能するCDNです。
サードパーティのサービスでアカウントを設定する必要があるため、CDNの設定と実行についてはこの記事の範囲外です。
自社サイトでは、ストレージにAmazon S3を、配信にCloudFrontを使用しています。他にも優れたオプションがありますので、調べて比較してみてください。
CDNアカウントが設定されると、W3TCはローカルファイルをCDNに送信し、サーバーからのリンクをCDN内のファイルに置き換えます。その後、サーバーはHTMLファイルのみを送信し、残りはCDNが処理します。
サーバーは単一のマシンですが、CDNは実際にはサーバーのネットワークです。各訪問者に最も近いサーバーからファイルを送信します。CDNは、どの単一サーバーよりもはるかに高速に静的ファイルを配信できます。CDNを使用することで、訪問者のエクスペリエンスを向上させ、サーバーの帯域幅とネットワーク使用率を大幅に削減できます。
W3TCのCDNセットアップウィザードに従うことをお勧めします。これにより、メディアライブラリ、テーマ、およびプラグインのリソースをCDNに転送できます。
サイトパフォーマンスの最適化を楽しんでいますか。ぜひここにコメントを残してお知らせください。
