日本のWeb業界でもそろそろサイトの表示パフォーマンスをどうにかしなきゃなぁ…と考えている方もいらっしゃることでしょう（ごく一部かもしれませんが 笑）。いわゆる普通のWebサイトの表示パフォーマンスの改善については、ここでも年末から数回にわたって取り上げています。
ここのエントリーに挙げた以外に、ちょっと前にゲリラ的にUSTREAMでくっちゃべってみたところ反響も大きかったようです（最初の回は特に他のどこ探してもないことも言いましたしね、フフフ）。
で、今回はこのブログでも使っているWordPressのパフォーマンスをアップさせるためにできることをいくつか紹介したいと思います。「できる」「できない」は設置されている環境で異なりますのであしからず。
最後にどこでも設置できるプラグインも含めておりますので、最後までお読みいただければ幸いです。すんごい長いので気合い入れてくださいね（笑）。
※一番最後にパフォーマンス計測のためのリンクを追加しました
まずはWordPressの仕組みからおさらい
CMSとしての活用事例も多いWordPressですが（海外ではね 笑）、「そもそも何故パフォーマンス改善が必要なのか」というところから話をはじめましょう。
WordPressは、基本的に静的なHTMLを生成するMovableTypeと違って、PHPを使ってリクエストのたびに動的にコンテンツを生成する仕組みです。ブラウザからのリクエストがWebサーバに届いたら、PHPがMySQLに格納されたデータを読み出し、テンプレートを使ってリクエストURLに応じたHTMLを逐一生成してる、と。
パフォーマンスチューニングされたホスティングにおいてあれば回線環境も処理速度も速いかもしれませんが、そういったケースばかりではありません。中には自宅サーバで運用されているうちみたいな貧弱な環境もあります。
そこで、Webサーバとその上で動いているPHPが処理する時間を改善し、さらにWebサイトの高速化のための手法を組み合わせることでパフォーマンスアップを図ろうじゃないか、ということですね。
閲覧側は高速なブロードバンド環境ばかりではありませんし、最近だとTwitter経由でiPhoneから閲覧することもあります。見にきてくれる人をいかに待たせないで、ストレスなく見てもらうかといったことも考えなければいけません。
ま、前振りはこれぐらいにして本編にいきましょう。
PHPの処理をキャッシュさせて速くする
VPS（バーチャル・プライベート・サーバ）やDedicated Serverみたいな比較的自由度の高いプランで契約されていれば、サーバの構成などを管理者側で設定できます。そのような環境に置かれていれば、PHPの処理そのものを高速化するといったことが可能です。このような処理をおこなうものに「eAccelerator」や「APC（Advanced PHP Cache）」、「memcache」などがあります。
ここでは詳しい話はしませんが、この辺りをサーバに突っ込んであげるだけでPHPの処理にかかる部分のパフォーマンスは大きく改善されるでしょう。ちなみにうちはAPCとmemcacheが入ってますが、それは後ほどあらためて。
動的生成しないでHTMLをキャッシュさせる
ここからがいわゆる普通のホスティングサービスでも採用できるかもしれない方法です。ここからはWordPressのプラグインを利用します。
先に述べたようにクライアント側からリクエストがあった場合、そのリクエストされたURLをWebサーバ側のWordPressが動的に生成します。この動的に生成している部分をMovableTypeのように静的なHTMLファイルとしてキャッシュしておいて、新たなリクエストがあった場合にはそれを送り返しちゃうと。
このような仕組みを実現できるプラグインはいくつかあるようなんですが、ここでは利用者の多い「WP Super Cache」と前述のPHPの高速化処理と組み合わせられる「W3 Total Cache」の2種類を紹介しましょう。
いずれのプラグインもWebサーバ側で「mod_rewrite」的なURLの書き換え処理ができる環境でないといけないかな、たぶん。なので、サイトを運用する時は安いプランだけじゃなくて、自由度をある程度高くしておいた方が都合が良いのです（笑）。
WP Super Cacheのインストールと注意事項
では、まずはWP Super Cacheから。iidaのサイトもこれを採用されてる風。
インストールは、プラグインの公開サイトからダウンロードしてもいいですし、WPの管理画面から直接インストールすることもできます。
次に紹介するW3 Total Cacheもそうなんですが、これらのプラグインのインストール時には、「wp-config.php」の中の「define(‘ABSPATH’〜」の行の前あたりに以下の記述を追加しなければなりません。
define('WP_CACHE', true);
ついでと言ってはなんですが、あらかじめ「wp-content」のパーミッションを「777」にしておくと、有効化の時とかにいちいちアラートが出てこないので楽です（終わったら755なり、元のパーミッションに戻します）。
日本語版にインストールすれば日本語で設定項目が出てきますので、特に設定に困ることはないですかね。いくつか設定項目をピックアップしてみます。
ま、こんな感じです。
一番上に「オン」「ハーフオン」「オフ」の切り替えボタンがありますので、そこでWP Super Cacheをの機能をオンにします。あとはWP Super Cacheの基本的な挙動のスイッチがありますので、必要に応じてチェックを入れましょう。
サイトによっては日本の携帯電話用にサイトをフォーマットしてくれる「Ktai-Style」やiPhone用の「WPtouch」などを利用しているかもしれません。そのような場合は「Mobile device support using」を必ず有効にしておきましょう。
WP Super Cacheは生成した静的なHTMLをGzip圧縮して送ることもできるようになっています。これを有効にすれば転送データ量を1/3程度に抑えられますが、必ずしもすべてのサイトでできるとは限りません（と書かれています 笑）。
WP Super Cacheで生成される静的なHTMLは「cache」ディレクトリに保存されますので、リクエストがあった場合はそちらにリダイレクトする必要があります。その役目を果たすのが「mod_rewrite」なので、指定された場所にある.htaccessに表示されている内容を追加しましょう。
設定を変更した場合も何か変わってないかチェックしましょうね。
その他、除外するファイルやURIなどは別で設定可能です。あとは、ファイルの有効期限などを設定すれば終わりです。これ以下にもろもろ設定項目が並んでいますが、ほとんど使いませんかね、たぶん。
以上が、WP Super Cache編でした。
W3 Total Cacheのインストールと注意事項
W3 Total Cacheは、WP Super Cacheと同様、静的なHTMLをキャッシュしてクライアントに送ることができるプラグインです。
厳密には同じではなくて、より高機能で設定項目も多く、サーバの仕様にあわせて細かくカスタマイズできるのが特徴です。ページのキャッシュだけでなく、Minify化したものやデータベースのキャッシュも保持できたり、CDN（コンテンツ・デリバリー・ネットワーク）の設定までできる優れものなんですね。余談ですが、開発者の人はTwitterでも話しかけてきます（笑）。
インストールは、WP Super Cacheと同じ手順でおこないます。
残念ながらインターフェイスは日本語化されていませんが、「基本設定」「ページのキャッシュ設定」「Minifyの設定」「データベースのキャッシュ設定」「CDNの設定」といったところですね。
一番上のチェックボックスで機能のオン・オフを切り替えます。
こちらのW3 Total Cache、単に静的なページをディスクにキャッシュするだけではありません。ページのキャッシュ、Minifyのキャッシュ、データベースのキャッシュにmemcacheやAPCを使うことができます（それらがなければ、ディスクです、たぶん）。オン・オフは個別に設定できます。
とある海外サイトのパフォーマンス計測結果によるとページのキャッシュは「Disk（enhanced）」にしておくとより高速化できるといったことが書かれていました。ディスクに溜め込むので、当然mod_rewriteが必要になります。
うちも長らくWP Total Cacheのお世話になってましたが、先日ふと思い立ってこちらに乗り換えました。現在の設定は、ページキャッシュを「Disk（enhanced）」、Minifyとデータベースのキャッシュを「APC」にしています。memcacheでもしばらく回してみたんですけど、どうにも不安定で結局この設定です。
で、携帯向けの対応をしている場合に注意点があります。
先のKtai-StyleやWPtouchが入っている場合、それらに対してページのキャッシュやMinify化をしない方が無難です。ページキャッシュの設定にある「Rejected User Agents」に除外対象を追加しましょう（※一番下にあるモバイルのUAをまるごとコピペすればいいです）。
Minify化したキャッシュも同様。「Minify Setting」にあるリジェクトのところに先ほどの携帯端末のUA一覧を貼り付けておきましょう。ただし、iPhoneやiPod touchに対してはMinify化をかけても問題ないので、それから除外してもオッケイです（ボクの検証結果では）。
このW3 Total Cacheはかなり細かいところまで手が届くプラグインです。もちろん特定URlの除外やGzip圧縮などもサポートしています。WP Total Cacheに比べてmod_rewriteの記述も少ないですし、自由度の高い環境の方はこちらの方がいいかもしれません。
ただし、特定サイトのディレクトリ以下に配したマルチブログ的な環境だとうまくいかないかも（というか、うまくいかなかったｗ）。マルチブログ環境については、フォーラムにいろいろ書かれていました（WP次期バージョンに向けてどうこうとか）。
といった感じでW3 Total Cache編でした。
キャッシュできなくても、別の部分を改善する
「mod_rewriteとかそもそもなんなの？」とか「使えるかどうかわかんないしー」みたいな方でも、いくつかのプラグインに頼ることでWordPressの表示パフォーマンスは改善可能です（といっても、なんでも入れればいいってわけではない 笑）。
まずひとつめは、WordPressのプラグインなどに勝手に組み込まれるヘッダ内のJavaScriptなどの位置を変えて高速化を図る方法があります。
Head Cleanerで表示速度の改善をする
この類のプラグインもまたいくつかありますが、日本発の「Head Cleaner」が一度になんでもかんでも処理してくれるんじゃないでしょうか（ボクは入れたことはないんですが、かなりいろいろできるようです）。もちろんWP Super Cacheなどと併用することもできます。
何故このようなヘッダ内のお掃除が必要になるかというと、複数のJavaScriptの読み込みやscript要素の順番によっては、特定のブラウザでページの構成要素のダウンロードが妨げられたりします。
なので、複数のJavaScriptやCSSをひとつにまとめてリクエストを減らしたり、改行やコメントを取ってMinify化したりすることで転送量を減らすことができます。また、ページの描画に関係のないJavaScriptなどは</body>の直前に配置したりすれば、なおよろしと。
うちは何でもかんでもプラグインに頼るのもなんなので、プラグインの数も抑えてhead要素内に組み込まれるものは手動でまとめています。
WP Smush.itで画像を最適化する
次にできること。表示速度はページ内に含まれる画像の数にも左右されます。何の気なしにPhotoshopなどで書き出したJPGやPNG画像には実はいらないデータが含まれていることもあります（特にJPG）。アップする画像も実はさらに最適化を施すことでデータ量をガクッと下げることができるんですね。
→ WP Smush.it Wordpress Plugin
「WP Smush.it」は、アメリカのYahoo!の「Smush.it™」を経由してアップロード画像を最適化してしまうプラグインです。たまにミスることもありますが、その時はあらためて「Re-Smush」すれば大丈夫でしょう。最適化されたかどうかのチェックやRe-Smushは、メディアのライブラリで確認可能です。
すべての画像が最適化されるわけではなく、必要のあるものだけが最適化されます。JPGなんかはビックリするぐらいデータ量が減るかもしれません（笑）。ちなみにGIFとPNGだったら、PNGの方が軽いです。
とまぁ、キャッシュできなくても表示パフォーマンスアップのために役立つプラグインが公開されていますので、試してみてはいかがでしょうか。
見てくれる人のことを考えてやれることはやりましょう
以上で、WordPressのパフォーマンス改善のためのアレコレの紹介は終わります。まぁ、見に来てくれる人のことを考えれば、少しでも速く表示された方がいいわけです（自分だって他見る時そうでしょう？）。幸い、WordPressは仕様のせいもあってかこのようなプラグインが多数公開されています。制作者の方にお礼を述べつつ、使えるものは使ってみるといいかもしれません。
最後に。この辺の話はまたゲリラ的にUSTREAMで喋る予定です。ここに書いた内容を補足する感じになると思いますが、「文章じゃわかりづらいよ」って方はボクのTwitterでもリストに入れておいてください（フォローするとうざい 笑）。
（追記: 2010.03.10）
そういえば、パフォーマンスの計測ツールをご存じない方もいらっしゃるかもしれませんので、こちらで以前紹介していたリストのアドレスをご参考までに。
新しく一個サービスを追加してあります。
Tags: performance, plugins, tips, wordpress, wp
[...] WPのパフォーマンスを改善してみようか | gaspanik weblog [...]