netvibes::cipher

gaspanik weblog

Webサイトの高速化的な話をWD誌で - yesterday

先日エイプリルフールにあげた冗談エントリーのお詫びとして、Webサイトの高速化というかパフォーマンスアップのネタをこのブログに書こうと画策していたのですが、実は本日18日にそれらの内容をまとめた特集を含む「Web Designing vol. 102」がマイコミさんから発売されてしまいました…。（いや、書いたのボクですけど笑）。 “Web Designing vol. 102″ on Flickr Originally uploaded by [cipher]. とまぁ、出ちゃったからにはしょうがないので、本誌に掲載された内容のフォローとか締切以降に変わった話なんかをピックアップしてみたいと思います。ちなみに今回のこの記事、Livedoorの浜俊太朗さんと二人で書いてます。高速化のキモは違う視点でサイトを見直すこと Webサイトの評価というのは、見る人によって変わってきます。やれ、デザインが素敵だの面白い動きだのって話はもちろんありですが、どんなにキレイで素敵なサイトであっても重すぎたら見るまでに至らないこともあります。ただでさえ視覚的な要素が多く含まれるいまどきのWebサイトです。例えば、ページの遷移毎に毎回毎回JavaScriptだ画像だと100個近くのデータを呼び出すサイトなんてざらにありますが、それがECサイトだったりした場合どうでしょう？ただ買い物したいだけなのに、ページの表示に時間がかかってしょうがない。あんまりダラダラされちゃうと「もういいや…」ってなっちゃいます。作ればお終い。そう思ってる人も多いかもしれません。でも、自分たちが作った納品物の検証も必要です。サイトによってはさまざまな回線環境やデバイス環境になってしまうこともあります。本当に作ったもので良いのか、どれぐらいの秒数ですべて表示されるのかなど。実際にサーバから流れているデータを眺めてみたり、作り方のせいで何か引っかかってるところはないか、など視点を変えることで高速化すべき点、改善すべき点が見えてくるのではないでしょうか。こういう言い方をするのも失礼ですが、Web業界の人たちが「すごい」「素敵」と言うようなサイトも別の角度から見れば「へー、素敵だけど重くね？」ってことも多いものです。あえて断言しますが、ごめんなさい、正直重いです（笑）。もちろんサイトの性質やいろいろな条件があることを理解したうえで、もう少しどうにかできるんじゃないかな…と思うこともしばしば。なにもFlashなどを否定しているわけではなく、ちゃんと考えられて作られてるところは体感速度やさまざまな環境に配慮されていたりして閲覧にストレスは感じません。 Webサイトは、ネットワーク環境やさまざまな閲覧環境に左右されるちょっと変わった媒体です。見えるところにこだわるのは大いに結構ですが、それにプラスして目には見えないところにも気を配ってこその「Webデザイン」ではないでしょうか。言ってしまえば、この辺の話も含めたうえでの「ユーザビリティ」や「アクセシビリティ」でしょう。それもできずに「ホスピタリティ？、何それ」って話です。作り手の都合だけで作っていると落とし穴にはまります。いきなり数MB、数十MBのデータをダウンロードさせたり、必要のないJavaScriptを毎度毎度読み込ませていたり、そんな部分はちょっと視点を変えて見直して、作り方や配信の仕方を変えれば良いだけです。というわけで、その手法のいくつかや考え方を簡単にできることを中心にピックアップして本誌の特集にまとめました。 3秒。このキーワードの答えは特集の最後に。内容の一部でちょっと簡単にフォローをとまぁ、能書きというか前説はこれぐらいにして…、内容について一部フォローを。まず、訂正とお詫びをこちらにちょっとだけ…。 P066のMinify化の図03ですが、キャプションの数値がリソース込みの値になっています。正確な数値はMinify化前が10KB、Minify化後が7.5KBです P071の本文末に入れてもらった脚注のスーパーリロードの手順ですが、これは「Shift + F5（もしくはCtrl + Shift + R）」かな？すみません…。 CSSとJavaScriptの読み込み順の話まずは、本特集でいくつか触れているCSSとJavaScriptの話でいくつかの補足を。 head要素内でどうしてもJavaScriptを読み込まなければならない場合、<link><script><link> みたいに間に突っ込まない本文中でも微妙に触れてますが、JavaScriptが途中にあるとファイルの並行ダウンロードができなくなるので注意が必要です。直接描画に関係のないJavaScriptは、</body> の直前辺りにまとめておきましょう。インラインのscript要素がある場合は、外部ファイルの読み込みの前にこれも上のと同じような理由なんですが、インラインのscript要素は外部ファイルの読み込みの前に実行させることで並行ダウンロードの妨げにはなりません（上における場合は）。画像最適化の話でおまけ Photoshopなどで書き出すPNG画像やJPG画像の最適化の話については本文を参照していただくとして、特集で紹介したアプリケーション以外にオンラインのサービスなんかもあります。日本のYahoo!さんも開発者ブログ的なところで何かアプリケーションを紹介されてましたので参考にされてください。 Yahoo! Smush.it™ 米Yahoo! さんの公開されてる「SmushIt™」というのがあります。WordPressには、このSmushIt™を一回経由して画像をアップするプラグインもあります。 ⇒Smush.it™ punypng こちらはGracepoint After Fiveさんが公開されているもので、複数ファイルをまとめてアップすれば画像の最適化をしてくれます。Donateボタンも用意してありますので、安定した運用のためにも…。 ⇒punypng あ、Faviconいれとこねブラウザによっては、別に指定もしていないのに一生懸命最後の最後までFaviconを探そうとするものがあります。なので、できればFavicon作って入れておいた方がいいかもしれません（Expireを5年ぐらい先に設定して笑）。 Apacheとかのサーバの設定 Webデザイナーという立ち位置でもできることということで比較的簡単にできるような話をまとめたつもりですが、一部サーバの話もいれてます。というわけで、そちらの補足も。 Apacheのマニュアルはオンラインにありますシェア的には圧倒的に多いApacheというサーバは、大体ホスティングサービスの設定をそのまま使うしかありません（.htaccessで許可されてるものはもちろん適用できます）。VPSなどのサービス次第では、Apacheそのものの挙動を変更することができます。マニュアルというか設定例みたいなものは、オンラインで閲覧可能です（案外最新版の書籍ってないので）。gzipのかけ方のものぐさ版とかも載ってます。 ⇒Apache HTTP Server Documentation（中にバージョン毎の日本語版あり）安いだけではなく、いろいろな対応を前提としたプラン選びホスティングサービスは安いだけで選んでしまうとベストエフォートな共有回線で他のサイトに影響を受けてしまったり、思ったようなカスタマイズができなかったりといった不都合も出てきます。そんなこともあるので、多少費用はかかったとしても、先を見越したサービスというかカスタマイズなんかもできるようなプランを契約するのが良いかと思います。 Googleさん、校了後に変わったこと今回かなりギリギリまで粘って最新情報を入れる努力をしたのですが、Googleさんの12月前半のリリースラッシュにあって漏れているものもあります。Webmaster toolsの「パフォーマンスビュー」はギリギリ間に合ったのですが…。 Google Web ToolkitのSpeed Tracerが出ていますこないだGoogleさんは「Speed Tracer」という開発者ツールをリリースされてます。こちらはまだWindows専用で、Google ChromeのDev版（Ver. 4.x）が必要です。 ⇒Speed Tracer – Google Web Toolkit 何ができるかっていうと、これまで流れ落ちてくるデータをタイムラインで表示したりヘッダとかの内容確認はできましたが、このSpeed Tracerをインストールすれば接続後のデータの流れはもちろんどんなイベントがどのタイミングで発生しているか、などがチェックできます。ちなみにMac用で先日リリースされたβ版のGoogle Chromeも同じVer. 4で、こちらはWebインスペクタで似たようなタイムライン表示が可能になってます（内容は異なるけど、どういう順番で展開されて〜みたいなのが見えます）。 ⇒Google Chrome Google Analyticsのコードが非同期モードで動きますこないだこのブログでもお知らせしてますが、Google Analyticsのコードがasyncモードで動くようになっています（現在はまだβ版ということです）。これまでのコードはどうしても表示の際、最後の最後にボトルネックになっていたのですが、コードをちょっと書き換えることであら不思議速くなります（笑）。使ってみた感じでは普通に動いてますが、一応β版ですので使用される際は慎重に。 ⇒Google Analytics launches asynchronous tracking ⇒Asynchronous Tracking（記述例） Google Public DNS ギリギリ間に合ってニュース欄の記事になってる「Google Public DNS」も、実際表向きはDNSのルックアップや名前解決の時間（ラウンドトリップタイム）の短縮を目的とされているものです。Googleさんが何を考えてるか知りませんが、特集の最後にまとめたような感じじゃないのでしょうか。 WordPressのパフォーマンス最適化について本文のコラムでCMS系のツールについてちょっと触れてますが、うちでも採用しているWordPressの話を最後にしておきます。WordPressは、PHPをベースにしたツールですのでどうしても動的生成する時間がかかってしまいます。もちろんこの辺はサーバの処理能力なんかも関係するでしょう（よっぽど変なことしてなければ1秒以内には終わる）。とはいえ、1秒はGoogleのロード時間より大きいのでちょっとした話を。静的なHTMLを作って、それを配信するうちなんかがまさにそうなんですが、自宅回線で線が細い中で複数のサイトが動いてるものですから、負荷がかかる時はそれなりにかかります。一番手っ取り早いのは、WordPressのプラグインとして公開されている「WP Super Cache」などを使うのが良いでしょう。これはキャッシュとして静的なHTMLファイルを作って配信することができます（要mod_rewrite）。設定次第ではgzip化することもできます。その他にもいくつか類似のプラグインはありますが、導入が簡単なのはこれかな。 ⇒WP Super Cache CSSやJSをMinify化したり、位置を移動したり本特集で紹介したCSSやJavaScriptのMinify化や結合、ソース内の位置変更もプラグインで処理することが可能です。ただ、プラグインとして動作するってことはそれなりに生成までに時間がかかることもあります。中にはキャッシュしてくれるものもありますが、どれを使うかいくつか試してみた方が良いでしょう。あんまりプラグインに頼りすぎないのもポイント前述のCSSやJavaScriptの話もそうですが、やろうと思えば手動で処理しておいた方が速いこともあります。プラグインにあれこれ頼ってると、それが原因で遅くなったりもします。また、バージョンアップで知らないうちに余計なJavaScriptがhead要素で読み込まれていたなんてこともありました。「なんか遅くなったなぁと思ったら、お前さんかい！」みたいなことも起きますのでご注意を（笑）。ちなみに我が家は「WP Super Cache」と「WP SmushIt」のみです。あ。MovableTypeの話もしておきましょうか日本では圧倒的に利用者というか、それを使ったサイトも多いMovableTypeですが、こちらは静的なHTMLを書き出す仕組みです。ただ何と言いますか、初期状態ではまぁ見事なもので最適化とは縁遠かったりします（Ver. 4まではチェック済）。MTで作られたサイトのHTMLソースとか見てみてください（笑）。でもまぁ、基本的に静的なHTMLですから、よほどのことがない限り遅くなることはないと思うんですが、いかんせんそのまま使おうものなら余計な空白や改行などが多く含まれることになります。これは一度テンプレートそのものを見直して、極力不要なコードやスペース、改行なんかを削除すればスッキリします。いらんコードを取っちゃえば、再構築の時間も大幅に短縮されます。あとは本特集で紹介したテクニックを織り交ぜていただければ、更なる高速化が見込めるのではないかと…。適用するしないは自己判断、いらんもんを入れたら重くなるとまぁ、ここまでダラダラ補足的なことを書いてきたわけですが、サイトを高速化するキモは「別の角度からサイトを見てみること」です。自分の目だけでは気付きにくいものを別の角度から見るわけです。何かを追加すれば追加した分重くなります。時には外部サイトのデータでDNSの解決とダウンロードに時間がかかりまくることもあるでしょう。排除できるものは極力排除したり、コンテンツの構成そのものを一度見直して最適化を図ることで表示までの時間は短縮できます。見せることも大事ですし、最適化ばかり追い求めてもつまらないものになってしまう可能性もあります。要は、何でもそうですが取捨選択するバランスが大事です。今回取り上げた内容はここ数年の間、海外を中心に話題になっていたものです。Webサイトの評価基準も時代や人によって変わってきます。くれぐれも波には乗り遅れないようにしたいものです。さて、ボクあまりWeb Designingさんで執筆してないのですが、今回気合いを入れて大量ページをまとめてみました（だからこんな長文を… 笑）。浜さんにご担当いただいた分を含め、興味のある方は一度手にとって目を通していただければと思います。 ⇒Web Designing ※あ、そうそう。来年頭ぐらいに「High Performance JavaScript（英語版）」という書籍がオライリーさんから出るようです。最後にどうでもいい余談をひとつ。こないだふと思い立って京都に行きました。その前に某JRさんの京都のサイト（探してください、有名です）を見ていたら、いわゆる一般的なHTMLのサイトなのにデータの総量が1MBを超えてました。どこをどうみても超えそうにないので、気になって調べてみました。すると、原因はCSSの背景画像で何故か高さ「8,000px」もある画像が貼り付いてるんですよね…（サイトの構造からいけば、残念ながら高さは1pxで済みます笑）。旅先で行き場所に困って、iPhoneでアクセスでもしようものなら余裕で死ねます（というか、すぐ閉じます笑）。まぁ、そんなことも速い回線環境で作業してると気付かないんですね…。某JRのサイトご担当者さま、来年からボクが作りましょうか？（笑）
ブラウザの表示エリアの割合を可視化するBrowser Size - 2 days ago

GoogleさんがLabsのサービスとして、「Browser...
Googleさんの動きが気になる、今日この頃 - 2 weeks ago

最近Googleさんの動きがいろんな意味で活発です。Chrome OSやら日本語入力やらといった部分はもちろんですが、Webサイト制作やSEO的な部分にも深く関わりそうな動きもあります...