多くの方が既に参加レポートをあげてくださっていますが、ボクはボクなりに今回のWordCampの話を書き綴っておこうかと思います。

今回登壇するにいたるまで

@naokomcさんから「WordCamp Tokyoやるから出てくんない？」と打診をいただいたのが10月初旬。普段あまりWordPressのコミュニティに貢献しているわけでもないので、「こんなボクで何かお役に立てることならやりますよ」とオッケイを。実はもともと彼女とは旧知というか、世の中でブログが流行り始めた頃からその存在を知っていましてね。そう、皆さんご存じないと思いますが、ボクは日本で二番目にブログの本を出してまして、今や見る影もありませんがその昔はブロガー的な立ち位置だったのです（笑）。

と、そんなことはどうでもいいのですが、その後今回のWordCampの実行委員長の@waviaeiさんと三人集まって、都内某所で何を話すか会議を（というかご飯をｗ）。今回参加された皆さんはお分かりいただけたかと思うのですが、イベントに参加される皆さんのWordPressとの接し方は多岐にわたります。参加される皆さんひとりひとりをすべて満足させられるような話はできませんし、他のスピーカーの皆さんのこともあります。とりあえず、その場は何が良いんだろうね？ってトコからある程度の方向性だけを決めて、後日「レスポンシブネス」な話でいきましょうか、ということになった、と。

うまく枠にはめてきましたねｗ

10月中旬にはそういった方向性だけは決まっていたものの、その時点では他のスピーカーの方はもちろんタイムテーブルも出ていません。まぁその辺が決まってから話の内容や構成を考えようかな、とのんびり構えていました。「レスポンシブネス」といってもその指し示すところは広いわけで、実のところ「あまり視覚的な表現に振れない方向で」ということは言われてました。Webデザイン業界でいま話題になっている「Responsive Web Design」的なものは、多様なデバイスへの対応が前面に出ているので割と視覚的な部分と捉えられがちです。

で、他のスピーカーやタイムテーブルが明らかになるにつれ、「この人たちうまいこと枠にはめてきたなぁ…」と感心しました（笑）。ボクのセッションをお聞きになった方は、最後の最後で次のセッションへの案内を出したことでお分かりいただけたかと思うのですが、ボクの話は次のお三方のセッションすべてに繋がる導入セッションだったのですね。パブリッシング・プラットフォームとして、Webコンテンツに限らないレスポンシブなWordPressの使い方で、と考えたのです。

実際、後のお三方がどのようなお話をされるかは、タイトルと概要を見て判断するしかないのですが（すり合わせることはできるけどしていない 笑）、長谷川さんやたにぐちさんは普段からブログや講演をなさってますし、高橋さんは既にWordCamp Kobeで電子書籍の話をされています。幸いそんな感じで、皆さんがどういった内容を話されるかはある程度の想像が付いたので、そこに繋がるような構成で今回のボクのセッションの骨子ができあがりました。

でも、前日まで何もしていませんでした

とはいうものの、30分という限られた枠の中で講演内容を詰めていくというのは実は大変な作業です。ライトニングトークみたいな短時間なら勢いでどうにかできますし、45分や1時間ぐらいの枠であればデモを含めながらの講演も考えられます。でも、技術的な話をする場合の30分って実はすごく微妙な時間なんです。詰め込みすぎて時間オーバーするのもダメだし、かといって内容を薄くしたり早口になりすぎて早く終わりすぎてもダメ…。ましてやデモなんて、トラブったらそこで終わり…。百戦錬磨なはずの皆さんからも「30分なんだよなぁ…」と（笑）。

そんな30分をどう使うか、ということをずっと考えていたので、骨子ができた後も全然スライドに手がつきません。結局、スライドを作り始めたのは前日の夜。ある程度形になってから一回寝て、起きてからあらためて見直してまた修正。練習なんて一度もすることもなく、朝会場へ向かう電車の中でもう一度確認。でも、新宿から品川シーサイドまでの移動は20分で話す時間より短く、iPhoneに入れたPDFを使ってイメトレどころじゃない（笑）。会場について、機材チェックを終えてから控え室にこもって、ホントに直前までスライドを修正していました。つまり、正直なところ練習一度もなしのぶっつけ本番で挑んでしまいました、ごめんなさい。

聴講いただいた皆様にお礼を

当日午前中のデザイナートラックのお二方は満員御礼の大盛況。出番が近づくにつれ、変なプレッシャーがおそってきます（笑）。「おいおい、デザイナートラックなのに一枚も絵がないよ」「コードすらないじゃん」みたいな状態からは脱したものの、内容はデザイナー向けと言って良いのか？みたいなところもあって、「全然デザインの話ないじゃん！」とか言われちゃうんじゃないかと、ハラハラドキドキどうなることかと思ってました。幸いにも若干の空席はあったものの、多くの方に聞いていただいてホッとしました。

そんな練習すら一度もしていないボクのセッションをご覧くださった皆様、あらためてこの場を借りてお礼を申し上げます。ここまで登壇に至った経緯からそのバッググラウンドを書き連ねてきましたが、今回WordCamp Tokyoのボクのセッションでは、デザインのことも技術的なことも表面をなぞるぐらいしか触れていません。即効性のあるツールの使い方やちょっとしたTipsといったウケる話ではありませんでしたが、ひとりでも多くの方にこれからのコンテンツ制作、そしてコンテンツ配信の未来を考える何かしらのきっかけや気づきを与えられていたら幸いです。ありがとうございました。

＃もともと人前に出て話をすることどころか、結構な人見知りなもので懇親会なども端っこにいて交流もしなくてスミマセン（笑）。お会いして名刺交換などしていただいた皆さん、ありがとうございました。

あ、いっこ言い忘れてた

いろんな閲覧環境がますます増えていくことが想像できますから、見た目の同一性とかあんま細かいことにこだわりすぎない方がいいですよ（笑）。

それと、最後にいろいろ宣伝…

えっと、今回内容的には「Responsive Web Design」「HTML5」「電子書籍（ePub）」、そして「WordPress」とこれからのWeb技術などを織り交ぜて展開しましたが、実はいずれについても現在書籍を執筆中です。正確な発売時期や書名などは全然決まっていませんが、来年早々には書店に並ぶのではないか、と。また、この11月からアクティブ・カレッジさんで、HTML5の基礎講座、電子書籍の基礎講座、スマートフォン制作の基礎講座などを担当しておりますので、それらの技術に興味のある方はそちらもよろしくお願いいたします。

前回は「WordPressのパフォーマンス改善あれこれ」みたいな話をしましたが、今回はガラッと方向性を変えてデザイナートラックの午後一発目に「レスポンシブ・パブリッシング」というお題で30分ほど話をさせていただきます。

WordPress を使ったオンラインコンテンツも多様なデバイスに「レスポンシブ」に対応できることが望まれる昨今。視覚的な対応はもちろん、コンテンツそのものをさまざまな形態で柔軟に配信するための考え方や手法を紹介します。

というわけで、多様化していくデバイスやコンテンツ形態を見据え、これから先WordPressをどう使いこなしていけばいいか、といった内容になる予定でございます。視覚的なマルチデバイスへの対応は、後に続くたにぐちさんでも扱われると思うのでそこそこにしておきます（笑）。

当日のタイムテーブルをご覧いただくとおわかりいただけると思うのですが、多様なセッションが目白押しの1日となっております。まだ、参加登録は受付中ですので、日曜日の品川でお会いしましょう。

→ WordCamp Tokyo 2011 | 2011年11月27日（日）

＃ちなみに今回の公式サイトのトップの写真は、ボクが昨年の横浜で撮影したものです。手タレとして出ていただいてるお二方、ありがとうございます。

今頃公開するな、と言われそうですが去年のです。ごめんなさい。

今回こちらのパフォーマンスの話は別の切り口から@wokamotoさんが講演されます。その予習程度にご覧いただくといいかもしれません。

ということで、今日はその舞台裏というか、コレがアレでこうなってできているよ、って話をしてみようかと思います。なにかの参考になれば幸いです。

Responsive Web Design の簡単な説明

インターネットに接続できるデバイスが増えています、というか多様化しています。画面サイズや画面解像度はまちまちです。日本の場合は10年ぐらい前からいわゆる携帯電話で接続できてましたが、それらもやはり同じような問題を抱えていました。そのような個別の端末に対して、画面解像度や技術仕様などをベースにコンテンツを最適化して配信するということは大変ことです。

さらに、今時はスマートフォン向けのサイト制作などもあります。今後ますます増えていくであろう端末に対して、情報をどのように出していくか、ということを考えなければいけません。デバイスに完全に最適化するのか、ある程度の見栄えを維持したままワンソースで展開していくか、ってなことです。

ま、そういう手法のひとつがこの「Responsive Web Design」や「Adaptive Web Design」などと呼ばれているものです。厳密に言えば、二つの意味するとこは異なると思いますが、端末の画面サイズや利用可能な技術、仕様にあわせて、最適化というより適合させていくという考えです。

たとえば、カラムのレイアウトは流動的に変化するように「%」ベースで幅を指定する、画像や映像のサイズもそれにあわせて変化させる、といったテクニックを駆使します。そこで使われる技術としては、CSS3はもちろんMediaQueriesやJavaScriptなども含まれます。

ただし、この方法もやはり万能とは言い切れません。たとえば、ブログやニュースのような文字が主体のコンテンツには向いてますが、Webアプリや視覚的な情報も含んだコンテンツなどではコンテンツそのものの見せ方を考えなければならないかもしれません。要は向き不向きがあるってことです。

WordPressのテーマ「Skeleton」を使ってみた

ま、そんなわけで今回作ったサイトは、「書籍や誰かのインタビューなどで気になる発言を引用してメモしておく」という内容です。文字ベースになるのは明白ですし、個別のデバイスに対応する意味もあまり感じられないので、レスポンシブな感じにしてみようと思ったのですね。

そこで採用したのが（自分で作れよって話ですが）、こちらの「Skeleton WordPress Theme」です。Skelton という名前からピンと来る方もいらっしゃる方も多いかもしれませんが、このテーマの元になっているものは「Skelton」というフレームワークです。

「Beautiful Boilerplate for Responsive, Mobile-Friendly Development 」というタイトルになってるように、多様な端末での見栄えをサポートしてくれるフレームワーク。HTML5ベースで主要な要素などがシンプルにスタイリングされたものなので電子書籍などでも使える感じです。これは、カラム幅は % 指定するのではなく、960pxをベースにしたpx指定となっています。

テーマの方はWordPress以外のCMSをサポートしていたりしてるので不要なファイルなども含まれていますが、ファイルをダウンロードしてテーマのディレクトリにアップすれば使えます。いらないCSSのコードもできれば抜いた方が軽くなるでしょう（そのままだと60kぐらいになるので）。

とまぁ、SkeltonがベースのWordPressのテーマをいれて楽はしてるのですが、そのままではちょっと使えないというか、ところどころに凡ミスもあるのでその辺を修正しながら「quoted」ができています。ブラウザのサイズを変えたりiPhoneやiPadなどのデバイスでご覧いただければ、と。

（追記）iPadを縦方向にすると横幅がぴっちりになるのもやはり単純な記述ミスだと思われますが、修正する場合は「skelton.css」の「#Tablet (Portrait)」のcontainerの横幅を748pxに変更しましょう。デフォルトでは左右のマージンが10pxずつ、16カラムがベースなので.sixteenは728px、たとえば「one＋fifteen＝728px」じゃないと話がおかしくなります。

それ以外にやっていること

それと今回は、Web fontも使ってみようかな？と思って「Google Web Fonts」をタイトル部分に使っています。CSS版で入れました。

あと、FacebookのOGPはシンプルに「WP Facebook Open Graph protocol」をベースにちょっとだけ改良。デフォルトイメージの登録、「og:description」には本文先頭の160文字かexcerptを抜いてくれるので楽ですね。

それ以外には、いわゆるサイトパフォーマンス高速化の手法をあれやこれやと。例によって「W3 Total Cache」を入れてCDNのオプションを有効にし、CSSやJS、ちょっとした画像などは別サイトから配信といった感じになっています。

参考までにGTmetrixのデータはこちらです。
→ Latest Performance Report for: http://q.gaspanik.com/

以上、これからWordPressを使ってレスポンシブ・ウェブ・デザインで何か…と、お考えの皆さんの参考になればと幸いです。

このAuthorshipっていうのは、「コンテンツ（の作者）とGoogleプロフィールを結びつけて、そのコンテンツの原作者が誰かなのかをはっきりさせること。それによって、Googleを使う人たちも検索結果からその作者を見つけやすくなるでしょう」といった感じでしょうか。

そんなわけで簡単ですが、Authorshipの追加の仕方をひとつ。

ブログを例に挙げて解説するとこんな感じ

わかりやすく説明するためにブログを例にしてみますね。ブログの記事っていうのは、それぞれの記事に執筆者がいます。執筆者が単体であるうちのようなブログもあれば、複数人で書いてるブログもあることでしょう。

その記事の執筆者が誰なのかは、記事に併記されたクレジットなどから確認できますし、名前の部分にリンクが埋め込まれていればサイトのアバウトページ（もしくはそれに準ずるページ）などでプロフィールを確認することができます。ここまでは既存のブログやWebサイトによくある形です。

でも、それだけだとそこで完結してしまう。そこでAuthorshipの登場です。

それを用意しておけばの話ですが、「Googleプロフィール」というのは、Googleにある自分のアバウトページだと言い換えることもできます。そのプロフィールページにはリンクを入れる箇所が右側に用意されています。その部分とサイトのアバウトページをリンクさせる、とGoogleプロフィールとサイトが紐付くわけですね。その関係性を手短に説明するとこのような仕組みになっているようです。

前述した説明の一部だけ取り上げると単なる紐付けに思えるけど、実は同じ内容のコンテンツが仮に大量複製されて別サイトに掲載されても、そのコンテンツが初めてネットに出た時の執筆者が特定できるわけですよね。コピー先があたかも自分が書いたように同じように紐付けたらアウトというか。Googleさんからしてみれば、文章の大半が同じであるうさんくさいコンテンツの発見、そういうサイトの排除にも役立つんじゃないかと思われます（なので、ブログ書いてる人はやっといた方が良いかもね）。

では、簡単に入れ方の説明を

まず、サイト内にある個々の記事に執筆者名にリンクを入れてアバウトページへのリンクを貼ります。この時に使うのが「rel=”author”」です。

Written by <a href=”http://example.com/about” rel=”author”>執筆者名</a>

このように「rel=”author”」を指定して、一旦アバウトページへリンクします。

それができたら、アバウトページには以下のように「rel=”me”」を使ってGoogleプロフィールへのリンクを追加します。

<a href=”GoogleプロフィールのURL” rel=”me”>執筆者名</a>

たとえば、ボクの場合は以下のようになります。

<a href=”https://profiles.google.com/108893305869300078846/” rel=”me”>こもりまさあき</a>

はい。サイト側の設定はこんな感じです。Googleプロフィールのボタンを使いたい場合は、こちらのページで生成することができます。

最後にGoogleプロフィールのページのリンクを編集して、リンク先が「自分のことについて書かれているページだよ」ってところにチェックを入れて保存しておきましょう。

ちゃんとリンクされてるかどうか確認するには、「Rich Snippets Testing Tool」で適当な記事のURLを入れてみると良いでしょう。

author
profile = http://example.com/about
verified = Verified: The author link points to an author profile page on the same domain as this page.

「Verified」という緑の文字が出てきたらおそらく大丈夫です。

最後のステップとして、この解説ページの一番下にあるリンク先のフォームから何やら入れてくれって書いてあるようなので一応入れておきました。複数のサイトを持っていたりする場合などの説明もここに書いてありますのでそちらを参考にしてください。

＃WordPressでこの「rel=”author”」やら「rel=”me”」を追加する方法は、既にいくつかの記事が出ていますが、Yoastさんのとこにテンプレートをいじる方法が載っています。ご参考までに。

以前から読んでくださってる皆さんには「またかよ」って話になるのですが、このへなちょこブログを書いてる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）