当日は録画もせず、たまたまタイミング良く見れた方だけ、という方向で進めようと考えていたのですが、やる前にちょっと気が向いてちょっとしたプレゼン資料をこしらえてみました。それがこちらです。

終了後、「資料の公開はあるの？」とお問い合わせをいただきましたので、しゃべりがあって初めて成立するスライドですが、Slideshareの方で公開しております。上のスライドの左下のmenuからPDFとしてダウンロードもできます（表向き内容のコピーとプリントは制限しておりますが、外せる方は勝手にしてください 笑）。

なお、次回の「USTREAMでやる何か」は、これとは全く方向性の異なる内容で連休明けに予定しております。

→ http://www.amazon.com/gp/kindle/mac/

特に何かする必要はゼロ、すぐ読めます

Macの場合はインストールも何もダウンロードしてドラッグ&ドロップするだけで終わります。早速起動してみる、と。

初回起動時にAmazon.comのアカウントの入力が求められるぐらいで、特別何かする必要はありません。この辺はKindle for iPhoneなんかと同じですね。

既に購入済みの電子書籍は「Archived Items」の中にリストされていますので、読みたい本をダブルクリックすれば「Home」の方に移動します。

Kindle for iPhoneと同じで読んだところが同期します

KindleとKindle for iPhoneを併用している方は既にご存知のように、「直前まで読んでいた場所」で同期が取れるようになっています。

デバイスに関係なく同じ書籍を読めるわけですから当然といえば当然ですが、自動的に同期して続きが読めるって実は何気に便利なんですよ。もちろんKindle本体なんかと同様に文字サイズや1行あたりの文字間隔なども変更可能です。

とまぁ、こんな感じのアプリケーションです。

Kindle用のデータにコンバートするのはWordやPDFなどの書類でも大丈夫ですが、HTMLで書かれているものが最良の結果が得られるようですので、何か企んでる方は今のうちから「Amazon Digital Text Platform」のドキュメントでも見ておきましょう（ログインはAmazon.comのアカウントで大丈夫です）。

余談ですが、Appleさんから発売予定のiPadの電子書籍は「ePub」フォーマットのようです。InDesignから直接ePubに書き出すとかできますけど、最終的にはいずれにしてもHTMLがベースになるってことですね。良かった良かった（何が 笑）。

It’s a very early look at the web browser, and consequently it has little in the way of a user interface. There’s no toolbar of any kind and no built-in security. The preview is instead meant to show off the IE9 platform, which includes Microsoft’s new JavaScript rendering engine (codenamed “Chakra”), and early support for emerging web standards like HTML 5, CSS3, and SVG2.

Microsoft unveils Internet Explorer 9 developer preview with HTML5 support

→ http://ietestdrive.com/

一番上にダウンロードのリンク、サイトの真ん中あたりにデモ用のコードというかサンプルページが用意されていますので、興味のある方はどうぞ。

HTML5やCSS3あたりの話題もちょこちょこ出始めていますが、そんな焦らなくてもとりあえずこのブラウザが正式リリースされてからのんびり始めても十分間に合うと思っていたりするんですけどねえ…。

→ Flowdock（現在はサインアップできます）

アカウントを取得してメンバーを招待してはじめよう

アカウントの登録が終わったら自分のホーム画面に移動します。アカウント1つあれば、チームやプロジェクト毎に「Flow」と呼ばれる独立したワークスペース的なものを用意できます。使用するFlowをクリックするとそのDashboardが表示されますので、Flowに参加して欲しいメンバーをメールで招待しましょう。

既にFlowdockのメンバーであれば、招待メールのリンクから自分のアカウントでログインすることが可能です（そうでない場合はサインアップ）。

招待された人がログインすればほぼリアルタイムでDashboardにあらわれます。Flowdockの右側に見えるペインでは、チャットしたりファイルを添付したりといったやりとりが可能です。

このぐらいだったら別にFlowdockじゃなくてもいいわけですが（笑）、Flowdockはここからが違います。

「Influx」にRSSやTwitter、メールなどを読み込む

Dashboardの左に並ぶ3つのボタンの上から2番目「Influx」をクリックすると、外部のRSSや特定のTwitterのフィード、メールなどをストリームのような形で表示することが可能です。

フィードやTwitterのストリームの追加はこのダイアログから、メールはFlow毎に用意されるメールアカウントに対してメールを投稿することでここに表示されるようです。つまり、複数人が参加しているプロジェクトやグループ内での通知事項は、そのアドレスに投げておけば自動的にこの画面に現れると。

Influxに流れてくるものは、個々にコメントをつけたりすることもできるようになっていますので、メンバー同士で意見を交わすみたいなことができます。なので、別に仕事じゃなくて特定の趣味のグループを作って、そこでワイワイやるといった使い方もありでしょう。

特定の話題やファイルの検索は「Flowser」で

チーム単位での仕事になるといろいろな事柄が毎日毎日起こっていくはずです。「あの話ってどうだったんだっけ？」みたいに過去を遡るのも大変です。Influxで流れる内容にはコメントだけでなくタグを付与することもできますので、それらを見つけるにはボタンの上から3番目の「Flowser」を使います。

特定のタグを検索したり、ファイルだけを表示したりすることも可能と。

動作は軽快。仕事だけじゃなくても使えそう

こんな感じでGoogle Waveと比較されそうな感じのFlowdockですが、できることが明快な上に動作も軽快です。チーム内のコラボレーションはもちろんですが、1つのアカウントでFlow自体は複数作れるので、Twitterなどで仲良くなった人たちとお出かけするためのグループミーティングみたいな場としても活用できるかもしれません。

こんな感じで右側にある「＋」を押せば新しいFlowが作れます。

画面のインターフェイスは英語になりますが、できることが限られているので使い方に迷うようなことはないかな、と。日本語も通りますし。現在はまだパブリックβという扱いなので、今後の発展に期待したいと思います。

最近では、高機能なプロジェクトマネジメントシステムだったり、Google Waveなんかも出てきちゃったりで、複数の会社をまたいだプロジェクトのマネジメントというか、制作チーム単位での工程管理というか、複数人でコミュニケーションを取りながら仕事を進めるスタイルにも変化の兆しがありますね。

Google Waveも鳴り物いりで登場した割には、全体的に重いからなのか使い道が思いつかないからなのか、近頃はあまりその話を目にする機会も少なくなりました（使っている方も多いとは思いますが）。が、ここにきて新しい仕事のやり方ができそうなコミュニケーションツールが登場です。その名も「Flowdock」。

Flowdockは何やら良さそげですぞ

このFlowdock、日本時間の3月11日未明にベータアカウントの登録が可能になっていました。サイトにあるビデオを見る限りGoogle Waveに似た感じもありますが、Twitterなどとも連携しているようで何やら良さそうな雰囲気です。

ここで「…いました」とか「良さそうな…」と書いてるのには実は訳がありまして…（笑）。なんだかんだで一気に広まって急激な負荷がかかっているのか、今のところ正常稼働できてないようです（中の人のつぶやきによると）。で、残念ながら現在はインビテーションのリクエスト状態になっています。どうやら復活したようで、現在はサインアップできるようになっています（2010.03.11午前の段階で）。

ボクは速攻でアカウントをいくつか作ったんで「紹介でもしとこうか」とパソコンに向かったのですが、こちらも残念ながらこの画面より先に進めません（笑）。

追って使い方などを紹介できればと考えておりますが、そんなわけなので今日のところはこの辺で閉めたいと思います。興味のある方はサイトの紹介ビデオを見るなり、β版のインビテーションリクエストを送るなりしておくと良いですね。

ひょっとしたら仕事の仕方が変わるかもしれません。

（追記: 2010.03.11）
復活していたので簡単に使い方を書いてみました。

今朝方「そう言えば…」と思い出して、外部からパフォーマンスチェックができるサービスの一覧へのリンクを入れておきました。で、改めてお礼といってはなんですが、そこにも追加した「Load Impact」さんをちょっと紹介しておこうかな、と。

こちらにも無償で利用できるパフォーマンスチェックツールがありますので、それとあわせてここのサイトのサービスを使えばどういうことが確認できて、どういう対処の仕方があるのかを簡単に書いてみましょう。

同時接続数を変えてロード時間を計測できるLoad Impact

Load Impactは、スウェーデンのとある会社が提供しているオンラインのロードテストサービスです。こちらの主なサービスは、同時に複数のクライアントで接続して負荷をかけてロード時間の平均や使用帯域を計測することができるのが特徴です（お試し版は同時接続数50クライアントまでで一日3サイトまでかな？）。

大規模なアクセスがあるサイトなんかはロードバランサーなんか入ってて負荷分散されてたりするんでしょうが、中小規模のサイトではそうはいきません。とはいえ、プレスリリースやテレビに紹介されたとかで一時的にアクセスが増えてしまうことも考えられます。ホスティングの共用サービスだとサーバのチューニングなんかはできないでしょうけど、ちょっとした負荷でも問題なくアクセスできるようなサイトにしておくことも時には必要になります。備えあれば嬉しいな、です（違）。

インフラが全然ダメなのにいきなり10MBのコンテンツとかダウンロードさせてたら、サーバとクライアントのコネクションがなかなか開放されず、すぐ一杯一杯になることは容易に想像できます（どことは言わんけど 笑）。かといって、新しい接続のためにリソースが確保できるかって言うとそこにも限界がありますから、自分とこで対応できる限界を知っておくこともまた大事なわけです。

いろんなUAをシミュレートできるPage Analyzer

この類のサービスを専門にされている会社さんは、大体無償で利用できるパフォーマンス計測ツールを公開されています。Load Impactさんでも「Page Analyzer」なる計測ツールがあります。

ここのツールの特徴は、他のとこよりも格段に豊富なUser Agentsをシミュレートすることができることでしょうか。

IEはもちろん、FirefoxやChrome、Safariなどのいろいろなバージョンが用意されています（ブラウザ毎にコネクション数とか違いますからね *1）。おそらくストックホルムからのアクセスになるはずですが、比較的レイテンシも少なくて良い感じです。

うちのヘボいトップで大体3秒前後。Chartbeatを使って国内からアクセスされている皆さんの様子を見てる感じでは、平均2秒いくかいかないかぐらいですのでまぁ良しと。秒数うんぬんより、UAのシミュレートができるということで便利です。

段階的に同時接続数をあげ、負荷をかけてロード時間を計測する

いよいよ本題に入りましょう。単なるサーバの設定などを確認する負荷テストであれば、専用のツールなどがあるのでそれを使えばいいわけですが、コンテンツの表示にかかる時間となるとどっかからやんないとなかなかわかりません。

が、しかし。このLoad Impactさんのサービスを使えば、段階的に同時接続数をあげて負荷を与えつつ、表示までにかかってる時間をチェックすることができるんですね。しかも同時接続数50までなら無償でチェック可能！、250まで接続数を上げてもたった$9！ってなわけです（どこの通販だと 笑）。

ま、そんなわけでですね、とりあえず同時に50クライアントまで増やしながらテストしてみるには無償でも可能です。Webサイトのトップにある入力欄にURL入れて、上の図の左のFreeテストに進めばチェックできます。

ただし、チェック結果の保存にはアカウントの登録が必要だったかな？ アカウント登録しても最初はFree版なので大丈夫ですけどね。

有償版は同時接続数をもっと増やしたり、細かな設定をした上でテストが可能になっています。画面見ただけだとちょっとわかりにくいのですが、$9/per dayってなってるのは「24時間内にテストする」ワンタイムフィーみたいなもんです（他にもオプションがあります）。

有償でもそんなビックリする値段じゃないですし、ある程度の規模での同時アクセスが見込まれるコンテンツなどを制作されている方にはいいかもしれません。自分の作ってるコンテンツの限界点を知るためにも、とりあえず試してみるのが一番（笑）。

とりあえず試してみたらこうなった

いや、実はちょっと前からWordPressの設定やサーバの設定をいじってはチェックしていたんですけど、今回同時に100クライアントまで増やしてロード時間を計測してみました。一番安いプランではスウェーデンのストックホルムからしか計れなかったので、とりあえずそれで。

テストにはそれなりに時間がかかりますので、コーヒー飲んでたりしてればそのうち終わります（テスト数による）。この図は、10クライアントから段階的に10ずつ増やし、最終的に100クライアントの同時アクセスまでの結果です。

グラフの線は、できるだけ横方向に同じような状態が良いのは言うまでもないですかね。グラフの縦は表示までの秒数になっています。80クライアントのとこでちょっとだけあがってますけど、広い目で見ればストックホルムからでほぼ3秒前後なので良しとしましょう。

例えばグラフがこういうことになったら、サーバ側の設定をちょっと変更したりする必要があるかな？と。40クライアントが同時アクセスしてきたらガクッと時間がかかり始めたとか、そういうことがわかるわけです。このグラフの形によって意味があるので、それはフォーラムで解説されています（英語だけど 笑）。

最後に。ちゃんとアクセスされてます（笑）

「ホントにアクセスされてんの？」とか疑う方もいらっしゃるかもしれないので（笑）、うちのサーバを監視してる「MUNIN」の画面を出しておきます。

上の図はApacheのプロセスの数を表示したグラフです。左側の縦2つのグラフの右端がガクッとあがってますが、この時がLoad Impactで負荷テストをしている時間です（50と100と2回やってるので2箇所だけ急激にあがってますね）。

WebサーバのApacheはアクセスが増えれば自動的にプロセスを増やす仕組みになってるので良いとはいえ、テストしたらある数値から急激に時間がかかってる場合などは、サーバ側の設定やらコンテンツの作り方などもろもろを見直したりした方がいいかもしれませんね。

サーバの設定をいじるなんてみんながみんなできるわけではありませんし、システムのチューニングは餅は餅屋で任せた方が良いとは思います。でもまぁ、一応こういう負荷テストを使って、コンテンツの弱点を探すってのもありじゃないかな？と思ったので簡単にご紹介まで。

うちもとりあえず「100人乗っても大丈夫」のようです。

*1: ブラウザのバージョン毎の仕様はこちらが詳しいです

• 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サイトのパフォーマンスチェックサービス

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