以前から読んでくださってる皆さんには「またかよ」って話になるのですが、このへなちょこブログを書いてるWordPressの設定は以下のような感じです。昨日書いた内容に大体則すような流れにしておきました。

• キャッシング: W3 Total Cache（以下、W3TC）
• Minify化: HTMLのみW3TC、CSS/JSは手動（外部サービス以外）
• 画像の最適化: WP Smush.itで自動実行
• 配信サーバの分割: EdgeCastのCDN（Content Delivery Network）
• Gzipの有無: Apache側で有効化
• ファイルの有効期限: Apache側で個別に設定
• head要素の最適化: 手動

APCを入れてる以外は特にバックエンドのサーバ側をチューニングしたりといったアレコレはやっていません（サーバのことを触らないつもりで引っ越したので…）。画像の最適化は、以前にも書いてるのでやっぱり省略します。

W3 Total Cacheでやってること

キャッシング系のプラグインとして有名な「WP Super Cache」ではなく、機能が豊富でかなり細かい設定が可能な「W3 Total Cache」をインストールして楽をしています（笑）。

静的なファイルでなく、Opcode Cacheで

W3TCもまた静的なHTMLファイルをキャッシュしておくことができますが、サーバ側に「APC」を突っ込んであるのもあって、せっかくなので静的なファイルではなくOpcode Cacheを使ってます（ここは気分的にｗ）。W3TCでは、ファイルやDBへの接続なども個別に指定できるようになっていますし、キャッシュを使用しないUAを指定したりといったことも可能です。

一応DBとかのキャッシュも有効にしてます。

HTMLのMinify化

W3TCには、HTML/CSS/JavaScriptのMinify化のオプションもあります。こちらはHTMLのみオンにしてファイルではなくこれもまたOpcode Cacheで。CSSとJSは数も多くないので手動でやってます。

CSSやJSなどは、複数ファイルの結合なんかも設定可能になってます（Minify化しないで結合だけとかも可）。

CDNの有効化

うちは契約しているサーバのオプションでEdgeCastのCDNが使えるのでそれを利用してます（なんせ海の向こうなので遠いんですよ…）。

W3TC側ではCDN側に設定したサーバのドメイン名（CNAME）を入れれば、あとは自動的に「wp-includes」以下のディレクトリやコンテンツ内にアップする画像のパスをCDN側のドメインに置換してくれます。うちのCDNはOrigin Pullなので、記事を公開すればCDNからデータを吸い上げてくれるので完全放置です（笑）。

あ、そうそうW3TCのCDNの設定には、FTPというかSelf Hostedなサイトのオプションもあるので、昨日書いたみたいに自前のサーバでサブドメイン使ったりする人にもいいかもしれません。

それ以外にW3TCでできること

それ以外にも、W3TCの中でMinify化やキャッシングにプラスしてGzip圧縮をかけてみたり、HTTPヘッダを付けたりしてファイルタイプ別に有効期限の設定などもできますね。うちはその辺の作業はサーバ側でまとめてやってしまっているので、W3TC側では前述したもの以外は特に何もしてません。

Apache側でやっていること

W3TCでいろいろできるのはわかってますが、いちいちWordPressの管理画面開いて設定するより、直接サーバ側で細かくコントロールした方が早いし楽なので、Gzip圧縮とファイルタイプ別の有効期限設定をおこなってます。

mod_deflateでGzip圧縮

うちなんかはそんなアクセスも多くないですし、訪問される方もだいぶ偏っているので特に気にもせずGzip圧縮が有効になるように.htaccessで設定しています。以下は、Apache 2.x系での設定例です。


AddOutputFilterByType DEFLATE text/html text/plain


せっかちな人はこんな感じでHTMLのみとかもできます。


<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
Header append Vary User-Agent env=!dont-vary
</IfModule>


特定のブラウザやファイルタイプにはGzipしないとかまでいれるとこんな感じ。詳しいことは、Apacheのマニュアルがバージョン毎に公開されてるのでそれを見ましょう。

mod_expiresで有効期限を追加

ファイルの有効期限は、Apache側でmod_expiresを使って設定しています。全部は載せてませんが、.htaccessとかでHTMLやらCSS、JavaScriptに有効期限を設定するにはこういう風に書けておけばいいですね。

<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault “access plus 1 seconds”
（中略）
ExpiresByType text/css “access plus 2 weeks”
ExpiresByType text/javascript “access plus 2 weeks”
ExpiresByType application/x-javascript “access plus 2 weeks”
ExpiresByType text/html “access plus 600 seconds”
ExpiresByType application/xhtml+xml “access plus 600 seconds”
</ifModule>

1なのに「seconds」とかsついてるじゃんみたいなくだらない突っ込みはやめてください。これでも動きますから（笑）。

HTMLのhead要素の最適化

HTMLのhead要素の最適化は、「Head Cleaner」などを入れれば何か何までやってもらえるのがわかってますが、以前から自分でプラグインの中身とかゴニョゴニョしていらんもんが出ないように改良したので手動です（笑）。

ブラウザの並行ダウンロードを妨げないように、画面の描画に関係ないJavaScriptは、</body>の直前あたりで読み込むように全部下に。直接コードが書かれてるJavaScriptは、head要素のtitle直下に置いてます。

head要素の中でいくつかのCSSを読み込んだり、JavaScriptを読み込んでる場合（もちろん直接書かれてるのも含め）は、その順番次第で表示速度が変わってくるかもしれませんので調べてみるといいですね（変えたくても、読み込み順が関係するものもあるでしょうけど）。

と、こんな感じっす

このブログはWordPressの以前のデフォルトテーマのままですしCSSもほとんどいじってはいません（仕事じゃないんで 笑）。W3TCに任せる部分とサーバ側でやる部分をわけて、読み込み順の調整やMinify化、テンプレート中の画像の最適化なんかは手作業でやってます。記事中の画像は「WP Smush.it」で最適化、と。

サーバが海の向こうってこともあるので、全部を一カ所から出すと遅くなるだろうな？ということで、一応CDNをかまして画像だけでもできるだけ近いところから出てくるようにしてる、ぐらいでしょうか。

と、こんな感じっす。

＃サーバ側があれこれいじれないのであれば、キャッシングの機能を使わなくともW3TC使うのもありじゃないでしょうかね。

そんなわけで、今日は誰でもできることから段階的に適用する感じで、WordPressのパフォーマンス向上に役立つであろう素敵なプラグインを7つ紹介してみたいと思います。

まずは、画像を最適化する

サーバ環境のこととか特別な知識も必要とせず、誰でもできる高速化の第一歩といえば、サイト内で使用する画像の最適化でしょう。WordPressにアップロードするJPGやPNGといった画像を自動的にスリムアップするのです。

WP Smush.it

「WP Smush.it」は、アップロードする際に自動的に「Yahoo! Smush.It™」を経由させて、画像から不要な部分を削除してくれます。PhotoshopやFireworksで書き出しただけの画像じゃまだまだです（笑）。画像の内容や形式で変わってきますが、JPGで10〜20%程度、PNGで1〜2%程度は軽量化できるんではないかと。

ただし、テンプレートとかの画像は最適化されませんので、それは別のツールやオンラインサービスを使いましょう。

DBへの問い合わせをキャッシュする

WordPressは、ファイルのリクエストがあればデータベースに問い合わせをして、その都度HTMLファイルを生成する仕組みです。テンプレートからページを生成するデータの呼び出し処理をキャッシュして使いまわせば、DBへのアクセス頻度を減らすことができるはずでしょう。その分の負荷を減らそうかと。

DB Cache Reloaded Fix

「DB Cache Reloaded Fix」は、そのようなバックエンドの処理をキャッシュするプラグインです。動的に都度生成されるHTMLをキャッシュするのとは別に、まずは頻繁にアクセスするであろうDBへの問い合わせをキャッシュし、生成処理自体を高速化・最適化してしまおうというものですね。

HTML、CSS、JSを最適化する

バックエンドの次はフロントエンドの最適化です。

WordPressに限った話ではないですが、多くのCMSではプラグインやテーマを使ってサイトを拡張することができます。あれもこれもと導入するのはいいのですが、結果として待ち受けているのはクライアントに送信されるHTMLがごちゃごちゃしたり肥大化してしまうことがあげられます。

Head Cleaner

@wokamotoさんが公開されている「Head Cleaner」は、プラグインやテーマによってあれこれ追加されてしまっているhead要素内を最適化してくれるプラグインです。もはや最適化というレベルを超えて、あれやこれやと高速化に役立つ処理を一手に引き受けてくれます。

フロントエンドに関係する部分を最適化することは、結果としてHTTPリクエスト数や転送サイズの削減に繫がるわけです。

静的なHTMLを作ってキャッシュする

WordPressの高速化で有名なのは、リクエストに応じて動的に生成されて送信されるHTMLを静的なHTMLファイルとしてキャッシュしてしまうプラグインの導入でしょうか。

一度リクエストがあって生成されたファイルは、有効期限内はディスクやメモリ内に保存されてそれが代用されるというものですね。頻繁にアクセスのあるようなサイトは生成処理をすっ飛ばして、保存されたHTMLを送り返す方が速いんじゃないか？って話。

WP Super Cache

いまさら説明の必要もないほど有名なプラグインです。環境に合わせて設定方法というか適用方法もいくつか用意されています。キャッシュの処理とあわせて、Gzip圧縮をかけてHTMLファイルそのものを小さくするなんてこともできます。

Quick Cache ( A WP Super Cache Alternative )

「Quick Cache」は名前にもあるようにSuper Cacheの代用になるプラグインです。他にも「Hyper Cache」とかありますが、最新版にも対応しているみたいなのでこっちを紹介。ボクはインストールしたことはありませんが、サイトのスクリーンショットやChangeLogなんかを見ると良い感じに思えますね。

キャッシュ系のプラグインは「入れる・入れない」の線引きが難しいかもしれませんが、非力なサーバ環境で負荷を減らしたいとか、ページ公開時にはアクセスが集中するといったサイトなら利用価値はあるんじゃないかと。

さらにCDNをかましてみる

全体的なページのロード時間は、HTMLファイルがダウンロードされてからが勝負です。HTML内に記述された構成要素が同じサーバから配信されていたら、順番にローカルにダウンロードされてくるのを待ってなくてはなりません。数が増えれば増えた分、データサイズが大きければ大きい分、データがダウンロードされてページ表示が完成するまでの時間がかかるわけです。

CDN（Contents Delivery Network）は、冒頭にも書いたように全体的なページのロード時間の短縮には結構良いものです（笑）。サイト内の画像、CSSやJSファイルをCDN側にも置いておけば、1サイトから全部配信されていた膨大なファイルを、閲覧側に近い高速なネットワークから配信させることができます。

CDN Sync Tool

「CDN Sync Tool」は、WP Super Cacheと併用して利用するCDNの同期プラグインです。説明には、AmazonのS3やCloudFront、CloudFiles、MaxCDNといった大手のCDNサービスの名前が列挙されています。

CDNはサービスによって、オリジナルのファイルをこちらからアップロードするのか、ファイルのリクエスト時に勝手に拾うのか、みたいな仕組みが異なります。その辺の処理（ファイルの同期をとる）を勝手にやってくれるツールと思えばいいでしょうか。

最近ではこのような既存のCDNサービスではなく、無償プランもある「CloudFlare」というサービスが人気のようです（WordPressのプラグインもある）。CloudFlareは、大元のDNSの情報から書き換えないといけないので導入できる環境がやや限定的ですかね。

ちなみに我が家は、先日も書いたとおりEdgeCastのCDNを使っています。記事中の画像だけを扱うサーバと、テンプレート中の画像やJSファイルを分けて、計3サイトからダウンロードされるようにしています。

全部まとめてやるなら、W3 Total Cacheで

ここまで段階的に適用できるWordPressのプラグインを紹介してきましたが、冒頭の「WP Smush.it」以外の処理を一気にできるプラグインもあります。

W3 Total Cache

「W3 Total Cache」はうちも入れてるのですが、それこそページキャッシュからMinify化、DBキャッシュ、サーバ側で処理したりするブラウザキャッシュの追加、CDNのサポートまで何から何まで一個で補えるプラグインです。いや、ホントに何でもかんでもできちゃいます。

最後に

ここまでいくつかのプラグインを段階的に紹介してきましたが、何も全部入れる必要はありません。配信するサイトの内容によって組み合わせの妙というのもあります。静的なHTMLファイルキャッシュさせるさせないはおいておいて、画像やDBへのアクセス、フロントエンドの最適化だけでも十分効果はあります。PHPによる動的な処理云々ではなく、多くの画像が含まれていてボトルネックになってる場合は、CDNの導入を考えてみるのもひとつの手かもしれません。

自分のサイトが遅い原因が、PHPによる動的処理なのか、サイトの作り方の問題なのか、を見極めることが最初にやるべきことです。それがわかったら、ココで紹介したものを試していくのが良いでしょう。

おまけ

一般的にいわれることですが、CSSやJSのような更新頻度の少ないファイルは、クッキーの付かないCDNなどの外部サーバから配信するのが高速化に良いとされています。HTMLファイルがダウンロードされると、次はそこに記述されたCSSやJSはもちろん画像などが順次ダウンロードされます。

ここ数日検証しながらふと思ったのですが、HTMLと一緒にページのレイアウトやデザインをつかさどるCSSをどこに置いておくのがいいのか、という問題がありました。外部のサーバに置いた場合は、DNSでそのサーバのIPアドレスを調べる時間がかかるため、初回の接続には微々たるものですが時間がかかります。

特にCSSなんてのはHTMLの頭にあるので真っ先にダウンロードが始まります。また、そこにはCDN側においた背景画像として使っている画像なんかもあります。それを考えるとCSSだけは同じサーバからの方がいいんじゃないかな？なんていう暫定的な結論に達しました（うちの場合は、CSSは一個しかないので）。

日本語でしか書いてないこのブログ、普通に考えれば国内のサーバを借りて公開ってのが筋でしょうが、あいにくのひねくれ者なので「Media Temple」という海外のホスティング会社のDedicated Virtualのサービスを使っています（俗に言うVPSに似た感じのサービスで管理があまりいらない）。

サーバのスペック的には強力になったとはいえ、日本国内からではネットワーク的にはかなり遠い…。どれぐらい遠いかと言えば、日本とアメリカぐらい（そのまま 笑）。そういう背景もあって、このWordPressを使ったブログでもあれやこれやと実験しながら、せめてコンテンツ自体を最適化してロード時間を抑えようと努力してたわけですが、ネットワークが遠すぎたら限界も出てきます。

そこで、今回のこのCDN導入とあいなったわけです。

ところでCDNって何なのよ？

大規模なサイトを運用したりしてる方にはおなじみかもしれませんが、あまりそういう機会のない方のために簡単にCDNの話から始めてみましょう。

CDNっていうのは、直訳すれば「コンテンツ配信ネットワーク」のこと。この仕組み自体は古くからあって、ライブのストリーミングやら容量が大きくなる動画ファイルの配信によく用いられていました（有名なところでは、AppleやらAdobeなんかも使ってるAkamai、国内だとJストリームなどがありますね）。

CDNを使えば、一箇所のサーバにアクセスが集中して配信が止まらないよう、データそのものを世界中に分散されたサーバに配置して、閲覧側のネットワークから近いサーバからコンテンツを配信することが可能になります。期間限定のキャンペーンなどで一時的にアクセスが集中することが予想される場合も、落ちたりしないように前もって予防策が採れるわけです。

今回の震災絡みでは、計画停電の実施で東京電力のサイトが繫がらなくなりました。あれも結構日にちが経ってからAkamaiから配信されるようになってましたが、アクセスが集中するのはアホでもわかるわけだから前もってサイトが落ちないようにすべきとこですけどねぇ…、トップとその告知のページだけでも（契約さえすれば短時間ですぐ稼働させられるんだし）。

近年ではそのような大容量になる動画などのコンテンツ配信や一時的なアクセスの集中を分散化させる以外でも用いられています。最近のWebサイトは、サイト内で使用する画像やCSS、JSといった静的ファイルの数も容量も肥大化してるので、これらのファイルをCDNに置いて配信すればより高速なページ表示が可能になるわけです。

これが大規模なサービスや人気コンテンツを持ってアクセスの多いサイトだけに有益かというとそうでもない。限定的なリソースで運用することで負荷がかかってる部分を他にまわしてあげることは、中小規模のサイトでも導入してみる価値はあります（HTTPリクエストを分散させる意味でも）。

ただし、国内でCDNなどと名が付いてるサービスは、値段が書いてない（問い合わせしてね♥）とかそもそも高いとか、個人レベルだと導入までの敷居がなんとなく高いものです。そんな理由もあるのか既に多くの人が導入しているのが、従量制で課金される「Amazon S3（Amazon Simple Storage）」や「Amazon Cloud Front」だったり、無償のプランもあって最近話題の「CloudFlare」でしょうか。AmazonのサービスやCloudFlareの導入については、多くの方が書いてるので検索してみましょう。

Media TempleのProCDNを使ってみるのさ

ボクが契約しているMedia Templeには、世界的にも有名な「EdgeCast」のCDNが月額$20-（月間転送量200GBまで）で使える「ProCDN」っていうアドオンサービスがあります。EdgeCastの持つ世界4大大陸、東京をはじめとした19箇所の拠点があるので、静的なファイルだけでも閲覧側から近いトコから出してあげれば多少なりとも表示速度は改善されるだろう、と。

日本語での解説もあるAmazonなんかのサービスと違って、英語でしか使えないような海外のサーバを使ってる物好きには説明の必要もないですかね…、でも一応。Media Templeのアカウントでログインして、サービスをアクティベートすればすぐ使えます（笑）。サービスが有効になったら、アカウントセンターからProCDNの管理画面を開いて設定をおこないましょう。

最初にやることは、Customer Originの追加

EdgeCastのCDNは、用意されたEdgeCastのサーバに手動でコンテンツをアップロードする方法と、特定のドメインをCustomer Originとして追加して自動的にコンテンツを追加する方法が採れます。自動で取得する場合は、「HTTP Large」と「HTTP Small」の区別がありますが、300kを超える.flvとか.wmvのようなコンテンツは「HTTP Large」、そうでない画像なんかは「HTTP Small」で扱えば良いようです。

自動的にコンテンツを取得する場合は、EdgeCastでどのサーバのコンテンツを拾うかを決めなければなりません。

配信の大元となるサーバとEdgeCast側の位置の紐付けは、「Customer Origin」メニューを選んでから「Directory Name」にCDN内の位置となるディレクトリ名を入力、「Hostname or IP Address」で配信元のオリジナルのサーバを追加します。で、最後に「Add」を押して終了。

うちの場合は、以前から別ドメイン（gaspanik.com）から配信していたテンプレート（テーマ）に含まれる画像やCSSは「static.gaspanik.com」、WordPressのディレクトリの「wp-includes」や「wp-content」以下にあるアップロード済みの画像やJSといった静的なファイルは「content.gaspanik.com」から配信するように設定しました。本当は一個あればいいんですけどね（笑）。

EdgeCastは、CDN側のコンテンツのGzip圧縮なんかも設定できます。

箱の用意が終わったら、DNSにCNAMEを登録する

EdgeCast側のデータの場所を決めたら、CDNとして稼働するドメインのCNAME（カノニカルネーム。言ってしまえば、エイリアスというか別名）を決めて、EdgeCast側に登録しドメイン側のDNSにもそれを反映させます。

まずは、EdgeCast側の「Edge Cnames」で別名を設定します。「cdn.〜」みたいなサブドメインを入れて、EdgeCastのサーバ内でポイントされる場所（先に設定したディレクトリ以下など）を指定します。

次に自分のドメインのDNSにCNAMEレコードを追加して、HTTP Smallなら「wac.〜.edgecast.net」みたいな指定されたEdgeCastのドメインを指定します。これでEdgeCastのCDNに関するもろもろの設定は終わり。

W3 Total CacheのCDNオプションを有効に

いよいよ本題です（笑）。WordPressで構築されたサイトの高速化するプラグインとして有名な「W3 Total Cache」には、CDNオプションが用意されています。ブログにアップロードする画像やテーマなどに含まれるJSなどはそこそこデータサイズも大きいので、更新の必要のない静的なファイルをCDN側から配信すれば更なる高速化が見込めるわけです。

W3 Total CacheでCDNのオプションを有効にするには、「General Setting」で「Content Delivery Network」を「Enable」にして、自分の使うCDNの種類を選択します。今回のうちの環境はコンテンツをミラーするだけなので、ここでは「Mirror」を選びましたが、Amazon S3やCloudFrontも選択可能です。

次に「Content Delivery Network Settings」に移動して、CDN経由で配信するコンテンツを選択します。

ミラーするだけの場合は、CDN経由で配信されるコンテンツをCNAMEに指定したドメインに置き換えることになります。W3 Total Cacheは、Configurationのところに追加すれば自動的にソースが書き換えられます。

利用するCDNのサービスによっては、FTPなどのログイン情報を指定してライブラリ内のファイルをアップロードすることになるかもしれません、はい。

今回のEdgeCastの設定はCustomer Originにしてるので、ブラウザからコンテンツがリクエストされると配信元のドメインにあるデータが自動的に保存され、その後はCDN側のサーバから配信されるようになるんですね。

あー楽ちん楽ちん。

traceroute で経路を確認してみる

CDN経由でコンテンツの一部を配信するようにしたのでどれぐらい速いかを検証したいものです。Webコンテンツのロード時間を計測するサイトは数多く存在しています。実際に世界各国からいろいろ試してた結果、ロード時間は圧倒的に速くなっていました（世界各国から見られることはないけどもｗ）。

ホストまでの経路は接続先の環境によって異なるわけですが、自分のところからの経路の比較ならターミナルから「traceroute」というコマンドを使うと手っ取り早いです。

traceroute 調べたいホスト名

と入力すればオッケイ。

うちの回線からもともとのサーバまで約20ホップあったのですが、CDNに振ったサーバだと12ホップになってるので経路自体は短くなっています。EdgeCastは東京にも拠点があるようですが、うちからだとカリフォルニアから配信されてるのはまぁご愛敬ということで（笑）。

これで少しでも国内からのアクセスが速くなればいいな、と。

単なる負荷分散で終わらすか、それとも…

一箇所に集中するコンテンツへのアクセスの負荷を分散させる目的でCDNを使うのはもちろんありですが、それと同時にサイトの高速化を目論んでいる場合は、単純にファイルをCDNから配信すればいいってわけでもありません。

CDN側におく静的なCSSやJSファイルは、Minify化やGzip圧縮することでもっと速くロードされるでしょう。画像に関しても同様で、単にPhotoshopやFireworksから書き出しただけのファイルは別の方法で最適化すればさらに小さくなります。

更新頻度の少ない静的なファイルは、ブラウザのキャッシュを有効に効かせるようにしておけばなお効果的かな、と。最近話題のCloudFlareのことを書いてるサイトは、分散させてお終いだけだったりしますからね（謎）。

負荷分散と一緒にその辺もやってあげると、転送量で課金されるCDNは安くなるだろうし、見る側のストレスもさらに軽減されるんじゃないでしょうか。自サイトで何をすべきかは、GoogleさんのPageSpeedとかGTmetrixや、下の書籍で確認してみましょうか（笑）。

→ HTML＋CSSコーディング ベストプラクティス（Amazon.co.jp）

とまぁ、そんな話はおいといて。今日は先日から思い出したようにこちらのブログにも付けたFacebookの「Like!」ボタンの話をしようと思います。

設置方法については多くのブログで解説されているので要点だけちょこっとだけ。あとは「いいね！」された回数やページを確認する方法を。

WordPressにLike!ボタンを付ける

WordPressへのボタンの設置はプラグインを使えば簡単です。

WordPressの管理画面から「Facebook like」とかで検索すれば、すごい大量のプラグインが既に登録されています。中には設定が簡単なものから、高機能なものまで多種多様です。

ボクはいくつかのプラグインをインストール・アンインストールを繰り返して、設定の簡単さと表示パフォーマンス的な部分を考えて「Facebook Like Button」を使わせていただくことに。

＃このボタンのJavaScriptはFacebookから引っ張ってくるからどうでもいいんですけど、何気にデータサイズが大きいんですよ（当社比ですがw）。

FacebookのAppIDを取得する

どのプラグインもそうなんですが、設置の際にはFacebookのアプリケーション登録をすると発行される「AppID」の入力欄が用意されています。まずは、Facebookにログインした状態でこちらのDeveloperページに行って、新しくアプリケーションを作成します（日本語版で使ってれば日本語です、たぶん）。

で、サイトの名前とURLなんかを入れて作成すると、すぐAppIDとかが表示されますのでとりあえずその文字列をコピーしておきましょう。

あとは必要に応じて、設定画面で連絡先などを登録します。独自ドメインの人は、サイトのドメインを入れておくこともできます。特にアプリケーションを公開するとかそういう手順は必要ありません。登録さえすれば終わりです。

AppIDを登録して、ボタンの表示状態を決定

さきほどコピーしたAppIDをプラグインの設定画面に入力します。プラグインによっては、次に説明する「InSights」のための「Admin ID」の設定もありますので、そちらも忘れずに入れておきましょう。

設定が終わったら、ボタンの外見をカスタマイズして終了。

「いいね！」の数は、Facebook Insightsで

せっかく設置したボタンです。ボタンを見ればわかるとはいえ、どれぐらい「いいね！」ってしてもらったのかは気になるところ（笑）。ましてや、ブログなどのように大量のページがあるものは統計が見れた方がいいですよね。で、その統計情報にあたるものが「Facebook Insights」になると考えればよいでしょうか。

このInsightsでは、どれぐらい「いいね！」してもらえたか、どのページが人気があるかなど日毎の統計が表示されます。その他、男女比や年齢分布みたいなものまでもね…、ウシシ（って、別にそれぐらいですが 笑）。

プラグインを使ってボタンを付けた場合は、自動でhead要素にもろもろのmeta要素が挿入されるので特に何もすることはありません。「どれを見ますか？」みたいなことを聞かれたら、設定したAppIDとかが表示されるので選択します。

設置してすぐには正確な数字はでませんが、数日経てば何日か前の情報がちゃんと出てきますので安心してください。

Webサイトはページビューなどで訪問数などを取得するのはできますが、内容が見てくれた人に伝わったかどうかまではわかりません。ブログとかだと、コメントするのが何か敷居が高かったりしますしね。その点、これだと気軽にポチッとできますし、数字が増えれば書く人のモチベーションもあがる、と。

つまり、何が言いたいか。この下のボタンを押してね♥ってことです。

• Webサイトの高速化的な話をWD誌で
• YSlow!、使ってわかるあんなことこんなこと
• Page Speedでチェックついでに最適化
• Page Speedが1.6βになったようで

ここのエントリーに挙げた以外に、ちょっと前にゲリラ的に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のサイトもこれを採用されてる風。

→ WordPress Super Cache

インストールは、プラグインの公開サイトからダウンロードしてもいいですし、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をキャッシュしてクライアントに送ることができるプラグインです。

→ W3 Total Cache

厳密には同じではなくて、より高機能で設定項目も多く、サーバの仕様にあわせて細かくカスタマイズできるのが特徴です。ページのキャッシュだけでなく、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などと併用することもできます。

→ Head Cleaner

何故このようなヘッダ内のお掃除が必要になるかというと、複数の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）
そういえば、パフォーマンスの計測ツールをご存じない方もいらっしゃるかもしれませんので、こちらで以前紹介していたリストのアドレスをご参考までに。

• Webサイトのパフォーマンスチェックサービス

新しく一個サービスを追加してあります。

で、早速使ってみましたよ。

ソーシャルメディア系の結果もあわせて表示しちゃうよ

kikinをインストールした後、Googleなどのkikinがサポートしているサイトで検索をすれば、WikipediaやTwitter、YouTube、Facebookみたいなソーシャルメディア系サイトからもそれに関連する項目を引っ張ってくれます。

こんな感じで検索結果の上にkikinの窓が登場します。

YouTubeを選べば、サムネイルの右下にあるPLAYボタンをクリックしてその場で再生できます。他にもAmazonやらいろいろあります。このkikinの窓を表示するしない、パーソナライズするしないといった設定は、ロゴをクリックして表示されるオプション、またはkikinのWebサイトで変更可能です。

日本語で検索しても問題ないようですので、いちいち他のサイトに見るのも面倒だなぁというものぐささんには便利かもしれません（場所取りますけど 笑）。ちなみにChrome版はカミングスーンです。

「bit.ly」「is.gd」「cli.gs」「awe.sm」「ow.ly」「am6.jp」、Googleの「goo.gl」にFacebookの「fb.me」、Flickrの「flic.kr」、自分トコのドメインより長いじゃん（笑）というBingの「binged.it」など本当に一杯あります。

Twitterをやられている方は140文字という制限内で友達にWebサイトを紹介したりもするわけで、そんな時にこのURLの短縮化は非常に役立ちます。Twitterクライアントによっては利用する短縮サービスを選択できたり、HootSuite（ow.ly）のように独自の短縮URLの機能を持ってるものもあります。また、サービスによってはクリック数も確認できますから、つぶやきの反応チェックにも使えます。

そんなわけで、今日はクリックトラッキングというかアクセス解析の機能が付いたサービスでWordPressのプラグインでも使えるものをいくつか紹介しつつ、「短縮URLはいいんだけどさ…」な話なんかをちょこっとしてみます。

WordPressとかと連動してクリック数を見たいなら

「bit.ly（j.mp）」はおそらく今最も使われてるURL短縮サービスではないでしょうか。アカウントを登録しておけば（両方共通）、短縮化したURLのクリック数などを確認することができます。現在Pro版としてより高機能なアクセス解析を搭載したものがβテスト中です。Bookmarkletで簡単にURLを短縮すれば、そのままTwitterにつぶやけて便利です（複数アカウントの使い分けも可）。

自分のアカウントのAPIキーを使ってWordPressやTwitterクライアントで短縮化すれば、それもきちんとカウントされます。

ホーム画面では、自分経由と第三者経由のクリック数、時系列でのクリック数、国別のアクセス数などが表示されます。ただ、これはいわゆるBotの数も含んでるという話がありました（今はどうかわかりません）ので、実のところの数字は…。

でもまぁ、安定度ではピカイチですね。

「cli.gs」は、Botの数を含まない純粋な人のクリックだけでアクセス解析ができるサービスです。昨年秋ぐらいからサービスの身売り先を探していたりと存続が危ぶまれていましたが、無事に買い取り先も決まって運営されています。このブログでもしばらくの間、Twitterにブログの更新のお知らせを出すときに使ってました。こちらもWordPressのプラグインやBookmarkletから簡単にURLを短縮できます。

ただ、どうも最近不安定というか、URLの転送自体はうまくいくんですが、自分のアカウントの画面で短縮化されたリストが出たり出なかったりします（笑）。リロードしろとか書かれてるんですが、それでもダメな時はダメで…。アクセス解析の方は、国別のアクセス数なんかが出るのでいいんですけどねえ…。

その他WordPressプラグインやTwitterクライアントで使えるものに「is.gd」や「tr.im」「awe.sm」なんかがありますが、今のトコ一番なのはbit.lyかなぁと（※余談ですが、awe.smのブログはクラックされてるような…。JS切って見ると… 笑）。

ow.lyとかam6.jpとかに一言…

「ow.ly」は、HootSuiteというTwitterクライアントでURLの短縮をおこなうと使われるサービスです（ow.ly単体でもいけますけど）。HootSuite自体が複数アカウントに対応していたりするので、利用されている方も多いようですね。これもWordPressプラグインでも使えたりします。

「am6.jp」で始まる短縮URLは、FeedTweetさんのサービス経由で吐き出される短縮URLのドメインとして使われています。国内のいろんなブログサービスから更新のお知らせを出すのに便利なのか、利用されている方も多い感じです。

でも、なんでこの二つを分けたかというと…。

「Webブラウザからリンクをクリックするとツールバーが出てうざい！」

Webブラウザでこれらをクリックすると上部にiframeを使ったツールバーが表示されます。これが結構うざい（笑）。そのページをシェアするのには便利かもしれませんが、「閉じる」ボタンを押さない限り中のリンクをクリックしてもずっとつきまとうし、あんまり良くないんじゃないかなぁ…と。

特にFeedTweetに関しては、iPhoneで見るときに「am6.jp → bit.ly → 元サイト」みたいな多段のリダイレクトがかかっていくため、タイトルバーがリダイレクトのたびにコロコロ変わって結構うざいんですよ…。

別にその人がやりたいようにやればいいとは思うんですが、ストレスになる仕様だとその短縮URLで始まるリンクはクリックするのを躊躇します。ほんのちょっとでいいから見る側の環境をちょっと想像してもらうと嬉しいなぁ、ボクは…。

自動化したい気持ちはわかりますが、更新通知ぐらいなら別にbit.lyのブックマークレットで手動で記事をTweetしてもいいんじゃないかな。タイトルとURLは自動で入るし、テキストを選択してBookmarkletを呼び出せばその部分もコピーされるんだからそんな手間ではないでしょう…。

そんな仕様を回避する「iframe redirector」

ま、ボクなんかが地球の片隅でうざいうざいと騒いでもどうしようもないんですが、ツールバーの存在が邪魔だと感じてる人はボクだけではないようで、FirefoxのGreasemonkeyで使える「iframe redirector」というのを公開されている方がいらっしゃいます（多謝）。

これを入れておけば、「ow.ly」や「am6.jp」の仕様をすっ飛ばして元のURLにリダイレクトしてくれますので、ツールバーの存在が嫌な方は入れておくとストレスはなくなります（※2010.01.18版でam6.jpの仕様変更にも対応したようです2010.01.23版でサイトの仕様変更にも自動対応したようです）。

うざい仕様は避けて通りましょう（笑）。

できれば短縮URLは展開したい…

このご時世、短縮されたURLを何の気なしにクリックしたらとんでもないサイトに飛ばされたということも起きなくはありません（そんな時のために、ボクは信用できるトコ以外はJavaScriptオフにしてます）。

ブラウザのプラグインやユーザースクリプトなどには短縮URLをリダイレクト先のURLに戻してくれるものもありますが、TwitterをWebブラウザから利用されている方は「PowerTwitter」を入れておくとなにげに便利です。

ほとんどの短縮URLはデコードされてリンク先のタイトルとかが表示されますので、それが押して良いものかどうなのかの判断がしやすいです。ただ、画像なども展開されて表示されますので、Followerがバンバン画像を出される人は辛いかもしれません…。思わぬ落とし穴に落ちたくなければ入れておきましょう（笑）。

そんなとこで。では、また。

あ、そうそう。ボクのソーシャル系のサービス一覧はこちらです。
→ http://bit.ly/mynameis