2012年6月30日（土） 、ベルサール九段で開催したCSS Nite LP, Disk 23「表示速度最適化」のフォローアップとして、こもり まさあきさんの『設計段階から実装まで、今すぐ始める高速化＋ライブデモ』のスライドなどを公開します。

• スライド（PDF、99ページ、4.2MB）
• 音声（前半）
• 音声（後半）
• 当日デモで最適化したサイト
• 最適化前（移行しただけ）のサイト
• Pingdom Toolsでチェックした結果

メッセージ

こもりです。LP23に参加された皆様、関係者の皆様、登壇者の皆様、土曜日は長丁場お疲れ様でした。表示高速化については、石本さんのお話にもあったように、それをやみくもにやるのではなく、その環境や状況にあわせて「どこからやるか（効果のある部分に手を入れる）」ということが大事です。

私のセッションでは、具体的な手法などを紹介しましたが、それはディレクターやデザイナーという立場からはいささか難しいものも含まれています。しかし、セッションの最後にも付け加えたように、この問題に関してはフロントエンドの人間だけがやるものではなく、そのWebサイト制作のプロジェクトに関わるみんなが気を配らなければ解決しません。ホスティングや運用環境の問題から自分ではバックエンドに手を入れることはできないかもしれない。でも、運用側にそういった提案をすることはできるでしょう。

多様化していくデバイス環境への配信を考えた場合、分業も結構ですがそろそろプロジェクトに関わる人たちみんなが、ネットワークの仕組みややデバイスそのものへの理解が必要な時代になってきていると私は感じています。フロントエンドの人間が力業でどうにかできることばかりではないのです。「そこは専門外だから」という考えはそろそろ終わりにしましょう。

誰のためのWebサイトなのか、今一度考えていただければと思います。今回のセッションが、一部でも皆様のお役に立てていれば幸いです。

質問へのお答え

以下、いくつかの質問にお答えします。

■jQueryを外部から読み込む、外部のDNS参照を減らす、は矛盾してないか？

たしかに矛盾はしています。しかし、たとえばGoogleなどはDNSの反応そのものに時間はかかりません。その他一般のWebサイトと異なり反応そのものが速いわけで、ルックアップコストよりもダウンロードにかかるコストが少ないといえます。特にjQueryを使う際、DOM Readyになって発動する何かがあれば、HTMLがダウンロードされてもjQueryが落ちてなければ意味がありません。そういう面も含めてネットワークの反応そのものが速いところから拾った方が、サイト全体のロードがより速くなるというわけです。ただし、先日のイベント途中にAmazonのAWSの一部が止まってしまったように（それによってまわりまわってCodeGridさんのサイトに登録できない事象が発生していたのですが）、100%のアップタイム（稼働）ということはありえません。時にそういうネットワーク事故も起こりえるので、フォールバックを含めて万全の体制にしておく方が良いでしょう。

■CSSの分割しすぎはいくつからなのか？

ブラウザの同時接続数仮に「4」とするなら、HTML1コに対して残り3つはCSSやJSにまわせるでしょう。箱作りのために必要なものを速く、と考えればその答えは出てくるはずです。たとえば、古いIE（IE6や7）の1ホストあたりの同時接続数は「2」です。つまり、分割した時点で分割しすぎになるわけです。まとめれば、それだけCSS1ファイルのデータサイズは増えてしまいますが、そこはGzipで圧縮して軽くすることもできます。数をとるかサイズを取るか、コネクション数と照らし合わせて考えていただくのが良いですね。最近ではSassやlessといったCSSコンパイラを使う制作者も増えてきました。これらは分割したファイルで作業をしつつ、最終的には1ファイルにまとめることが可能です（もちろん改行を取るとことも）。そういった手法を知っていれば、「分割する、しない」という部分はどうでもいい話になってしまうのではないでしょうか。従来の制作手法に慣れるとなかなか移行は難しいかもしれませんが、Webサイトをよりよく制作できるようにと新しい制作環境や手法が出てきているのです。今の自分の作業スタイルが果たして効率的なのか、という部分から時には自分に問いかけましょう。

■画像の使いすぎは「悪」なのか？、本体のサーバに無駄な仕事をさせないとは？

こちらは質問ではありませんが、私の「日本のサイトには画像が多すぎる」という発言をうけて、必ずしも「悪」ではないよね、という発言があったので補足しておきます。私の言うところの「画像が多い」というのは、情報として必要な画像ではなく、単なる装飾目的でしかない画像をやたらと使いたがる傾向があるよね？というニュアンスです。情報へのアクセスを良くするための目的ならともかく、ただ見た目をきれいにするためだけにあるようなものといったら良いでしょうか（imgではなく、CSSの背景画像にまわせるような）。「画像を使うな」と言ってるわけではなく、それが多いのであればCSSスプライトを使ってひとつにまとめることで全体のリクエスト数は減らせることになります。
また、「サーバには極力仕事をさせない（本来の仕事をさせる）」というのも、どちらかといえばそういった情報そのものの提示には必要ではない画像の配信にリソースを使うのではなく、ページの表示とデータのやりとりであったりという仕事に注力させた方がいいのでは？という意味です。たとえば、サイトが何かにとりあげられてアクセスが瞬間的に爆発することがあります。そういった場合に、アクセスしてきた利用者に対して都度100コネクションをさばけるでしょうか？（利用者の回線環境次第ではデータがなかなか落ちずにサーバが解放されません）、大規模なサイトで負荷分散がされているのであれば良いでしょうが、たったひとつの非力なサーバではまかなえないためすぐ落ちてしまうわけです。だったら、HTMLやCSS、JSといったものだけをパッと出してあげて、本体サーバをすぐ解放させる方向でサイトを構成しておく方が良いのではないか？と。
高速化とはちょっと話が変わってきますが、落ちない工夫という面もあるのです。

参考リンク

• GTmetrix
  YSlowやPage Speed Insightsを同時に実行できるWebサービスです。アカウントを登録すれば、過去の履歴を保存できます。また、結果はまとめてPDFに書き出すこともできます。
• Loads.in
  世界中の50ロケーションからロード時間を計測できるサービスです。ページの表示が完成されるまでを5段階ぐらいにわけてスクリーンショットを表示してくれるなど他にはないものがあります。秒数はおまけ程度に考えましょう。
• AWS-CloudDesignPattern（日本語）
  AmazonのAWSを使ったコンテンツ配信のための設計パターン集です。静的なコンテンツを、S3やCloudFrontで組み合わせて配信するなど、その構成例などが図入り（スライド）で紹介されています。CDNを使う際の参考に
• WP Booster
  WordPressを使ったサイトを簡単にCDN経由にしてくれるサービスで7月1日に公開されました。こちら日本発のサービスで、世界中のCDN拠点からデータ配信を可能にするものです。現在はクローズドβの受付中です。
• SnipEdges
  デモ中に出てきていた画面端の緑のスニペットです。
• SideFolders
  こちらもデモ中にマウスを動かしすぎて左側にちらちら見えていたものです。
• Zoom It
  ルーペ状で画面を拡大するツール。
• Sublime Text 2
  セミナー登壇者みんなが使っていたテキストエディタです。
  プラグインで拡張すれば、私がやっていたようにFTPなどに直接繋げます。また、SVNなどのようにFTPでローカルとリモートのテキストファイルの差分を表示することができます。
• ProCSSor
  CSSのMinify（コメントや改行を取る）やPrittify（Minifyされたものを逆に戻す）ができるツールです。同名のWebサイトがありますが、こちらは8月末でサービス終了で代わりにOS Xのアプリが公開されています。
• QuixApp
  デモの最初でPingom Toolsを起動したブックマークレット。ショートカットコマンドを入力することで、ブラウザに表示されているページをいろいろなサービスに放り投げたりできます。たとえば「speed」と入れればPingdom Toolsを、「gspeed」と入力すればGoogle Page Speed Insightsを開きます。
• SpriteRight
  岡部さんが紹介された「SpritePad」と同様のことができるOS Xアプリです。