• 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

最も簡単なTweetボタンの設置方法

まず、普通にコンテンツの一要素としてTwitterへのリンクを付ける場合は、以下のようなフォーマットにしてリンクを作ってあげればオッケイです。

<a href="http://twitter.com/home?status=XXX">Retweet</a>

「XXX」の部分を自分の好きなようにアレンジします。大概は閲覧中のページを誰かに教えるということが主体でしょうから、ここにはページのタイトルやURLが含まれることになるんじゃないかと。

これをRetweetの書式にあてはめると以下のようになります。

<a href="http://twitter.com/home?status=RT+@cipher+Title+URL">Retweet</a>

それぞれの文字列の間は半角スペースでもいいかと思いますが、「+」を使って連結しておけば自動的に半角スペースに変換されます。CMS的なもので更新する場合は、わざわざプラグインなんか使わなくても、テンプレートタグとか使って自動的にこの書式になるようにして追加されるようにしておけば良いですね。

公式RTではそのままの状態でRetweetされますが、時には非公式RT（QT）的な連鎖が生まれてしまう可能性もあります。そんなこともあるので、IDなどが入ることも考えれば140文字以内どころか控えめな文字数と短縮URLを利用するなどの工夫が必要になるでしょう。

つぶかれた数とRetweetボタンを一緒に付ける

ブログとかでやる場合は、最近よく見かける（というか、ここもそうですが）つぶやかれた数とRetweetボタンを同時に表示したいなぁ…という気持ちも膨らんできます（笑）。そんな時はどうするかというと、つぶやきを集積し検索サービスを提供しているとこのWidgetなりプラグインを使うのが手っ取り早いです。

ここからは、それが可能なサービスのいくつかとそこが提供しているWordPressのプラグインをあわせて紹介してみます。特にプラグインに関しては、それぞれに一長一短なとこもありますので導入の参考にしていただければと。

BackType | Tweetcount Plugin

「BackType」では数種類のプラグインを提供されてます。その中の「Tweetcount」プラグインが、カウントとボタンを一緒に出せるものです。もちろん、一般のWebサイトでも使えるように同じ機能をもったJavaScriptのWidgetも用意されてます。

このプラグインは挿入テンプレートの選択ができません。決してそれが悪いわけではありませんが、トップページとかで記事が連続する場合は、それぞれでJavaScriptを読みにいくことになるためパフォーマンスを考えた場合はその辺が問題かなぁ…と（※JSそのものはキャッシュされるようになってるようですが）。

→ http://www.backtype.com/plugins/tweetcount

Tweetmeme | Retweet Button Plugins

「Tweetmeme」のプラグインは、Tweetmemeのアカウントを持ってればアクセス数なんかも出るようになってまして、WordPress以外にもいろんなCMSに対応しています（もちろんMTはありません 笑）。その代わりいろいろな用途別のRetweetボタンのコードが用意されています。

ただ、残念なことにRetweetするときにTweetmeme経由ということで、Twitter側で一度認証してあげる必要があるのが弱点でしょうか（表示される画面は英語ですしね）。簡単に伝搬させようと思ってもそこに障壁がある感じです。それ以外は、ボタンの大きさや表示ページもコントロールできるし良いんですけどねえ…。ちなみにJSにはちゃんとGzipもかかってます。

→ http://tweetmeme.com/about/plugins

Topsy | Topsy Retweet Button for WordPress

最後は「Topsy」のプラグインです。プラグイン以外にWidgetとしてコードが公開されています。プラグインは、配置場所の選択とそれぞれのボタンの大きさなどが細かく設定できる点が素敵な感じです。Tweetmemeのような認証も不要でそのままTwitterの入力欄に放り投げられる仕様です。

その他トラックバックをどうするかとか、細かい設定が可能になってるのも特徴でしょうか。JSは有効期限の設定はされていませんが、そもそも0.9Kぐらいですしね。CSSで使ってる画像には2日先の有効期限が設定されてCDN経由で配信されてるようです。

→ http://labs.topsy.com/widgets/wordpress/

といった感じで…

WordPress用のプラグインは、これら以外にも単純にボタンをくっつけるだけのものなど多く公開されています。それぞれに特徴があって、どれを使うかが結構悩ましいものです。うちはいろいろ試してどれにするか散々テストした結果、こないだからTopsyのプラグインを採用することにしました。

以上、導入のご参考まで。

※それぞれ短縮URLの設定とかあるんですが、それはまた後日あらためて。

で、ここからが本題。ちなみにここから先の話は決してダメ出しではなくて、たぶん制作・管理されている方も気付かれていないんじゃないかと思うので、せっかくですからWebサイトの表示パフォーマンスの話と絡めてエントリーしておきます（管理されている方をご存知でしたら教えてあげてください 笑）。

WP Exploit Scannerのせいでしょ、これ

こちらのサイトのソースをチラ見 &「YSlow!」をぶん回して気付きました（YSlow!については今月発売のWeb Designing誌で 笑）。head要素の途中にWordPressの中のjQuery（1.3.2）の呼び出しがひとつ、そして</body>の直前にGoogleから呼び出してるjQuery（1.3.1）がひとつ、計二つのjQueryを読み込んでいます。

図の上の赤枠がサイト内部、緑枠がGoogleの方です。
で、こういうことって普通に制作していたらやんないはずなんですね。もろもろのJavaScriptは</body>の直前にまとめてありますし…。でも、head要素（しかもそこに置かないだろうってとこ）に怪しげなjQueryの読み込みがあります。

これがプラグインによる仕業なんですね…。
おそらくこちらではセキュリティ面にも配慮されていて、「WP Exploit Scanner」ってのを導入されているのではないでしょうか（というか、絶対にそう 笑）。このプラグイン、実はうちにもこないだまで入ってましたが、最近のアップデートでこのhead要素でのjQueryと上図の下の赤枠にある「なんちゃらform.js」を読み込むようになったんですよね…。普通2箇所で同じjQueryを読み込むなんてしないでしょう。

こういうのがボトルネックになるわけで…

これがあるとどういうことが起きるかというと下図のようになります。

→http://www.webpagetest.org/result/091222_3SW2/1/details/

誰でもテストできるから画像出しますけど、こちらのサイトにアクセスしてからのデータが落ちてきてブラウザで表示が完成するまでの流れです。
※ http://webpagetest.org/ のDulles, VAのIE 8でシミュレートしたもの

この図中の赤枠を引いてる箇所が問題のjQueryの呼び出しですね。head要素のあんなところにあるもんだから、これがダウンロードされるまでの約2秒間（レイテンシもあるので秒数はまぁいいでしょ）は、並行ダウンロードができなくなりデータが落ちてきません。要はダウンロードしたくても止まっちゃうわけですね（赤いべた塗りのとこは404ですのでなおしてね 笑）。

おそらくこの冒頭のJavaScriptの読み込みは意図せぬものだと思うので、これさえ取ってあげれば少なくともあと1〜2秒ぐらいは速く表示されるのではないでしょうか（どうしてもExploit Scannerが必要なら話は別ですが 笑）。WordPressならhead要素の内容をキレイにしてくれるプラグインもありますが、どうするかは考えなきゃいけませぬ。

とまぁ、こんな感じでサイトを管理されてる方も気付かないうちにこんなことが起きてしまうんですよ、という話でした。Webサイトのパフォーマンスアップはこんなとこを見つけながら最適化を図っていくわけですね。

繰り返しますが、これは決してダメ出しではありませんので。
サイトの表示パフォーマンスの最適化の話は、今月号の「Web Designing」の特集ページをご覧ください（繰り返される宣伝 笑）。

このプラグインを入れたIEは、metaに特定の指示詞があればそのページのレンダリングエンジンをWebKitにし、JavaScriptのエンジンもChromeに入ってるものが使われるようです。ようはそこだけChromeになるってことですね。

同意してインストールすれば終わりです。

ただこれは何もGoogle Waveに限った話ではなく、普段IEをお使いの皆さんが導入してくれれば、FirefoxやSafari、Chrome、Operaといったブラウザに最適化して作っておいても、見た目も崩れずスクリプト系も動くってことになると、その違いに頭を悩ませている開発者にとっても恩恵があるんじゃないかと思われます。

利用者側に促して入れてもらう必要はあるわけですが、「IEなんかなくなれ」とか「ウィンドウ内にアナログってだす」とか「サポートしません」というよりはいいかもしれませんね。日本のいくつかのサイトのように「IEしかサポートしません」っていつまでも言ってるのはどうかと思うんだけどね…（笑）。

自分のページというかテストをする際は、head要素内に以下を記述してアレコレ試してみましょう。現状「file://〜」で始まるローカルのものは処理しないようです。詳しいことは、Googleさんの用意しているドキュメントを見てください。

<meta http-equiv="X-UA-Compatible" content="chrome=1">

Google Chrome FrameがインストールされたIEをリンク先のページで強制的にそのモードでレンダリングさせるには、「cf:http://〜」みたいにしてリンクを記述しておくとhead要素のmetaがなくてもそれで動くようです。

ものは試しで一番手っ取り早いかなぁと思って、「Snow Stack」という名で有名なWebKitの3Dエフェクトとかを実装されたsatine.orgさんとこの実際のテストページにリンクしてみました。

→ Snow Stack demo（for IE with Google Chrome Frame）
→ Snow Stack demo（for Safari 4 / Chrome / Webkit Nightly）

こんな感じで動きました。

ただ、「cf:」付けちゃうと他のブラウザではリンクが辿れませんから、仮にそれを使うならそこはアレコレしてブラウザ毎にリンク先を振り分ける必要がありますね。

まだまだ新しい技術なので今すぐどうこうではないですけど、IEの次期バージョンの前にこれが浸透してくれたら少しだけIEの存在に頭を悩ませている開発者のストレスがなくなったり、帰宅時間が早くなったりするかもしれません（笑）。

＃あ、そうそう。世の中には「Browserscope」っていうブラウザの実装状況みたいなのが公開されているサイトもあります。

WebKitになってるってことは…

ちょっと試しに簡単なの用意してみました（CSSの角丸だけ）。

FirefoxやSafari、Chrome、Google Chrome Frameの入ったIEなら角丸の矩形になり、それ以外のブラウザはただの角張った矩形になってるはず

ということですね。
ちなみにこれ（上のmetaをいれても）、Internet Explorer本体でのみ動作してそれ以外には影響しないよう（というか、IE 8に入れたので単なるアドオン扱い）で、Expression Web Super PreviewとかIE Testerでは素のIEの状態で描画されるようです。

で、そのRSSCloudを自サイトなどにインストールしているWordPressでも有効にする（というか、<cloud ~ />で始まる要素を追加してくれる）プラグイン「RSS Cloud」が公開されています。どういうことをするものかなど、詳しいことは作者であるJoseph Scottさんのサイトの記事でご確認ください。

現状、RSSアグリゲーターの対応待ちに近いところはあるようですが、RSSCloudの可能性についてはTechCrunchやITmediaさんなどで日本語の解説が出てるようなので一読してみると良いかもしれません。

RSSの今後がこの先どうなるかわかりはしませんが、我が家はテストがてら導入済みにござります（自分自身はもうほとんど… 略）。