書評:ハイパフォーマンスWebサイト

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール
Steve Souders スティーブ サウダーズ
オライリージャパン
売り上げランキング: 1047
おすすめ度の平均: 4.5
4 簡単なWebサイトの高速化
4 クライアントの表示速度を上がります
5 利用者の視点
5 フロントエンドエンジニアの執念

著者はYahoo!でフロントエンドのパフォーマンス改善を専門に担当している方であり、同氏によれば、Webサイトを使用した際のユーザ待ち時間の8割前後は、ブラウザにデータが転送される時間とレンダリングされる時間によるものだそうです。

パフォーマンスを上げようとしてバックエンドをどれだけ速くしても、それだけでは一割程度しか高速化できない現実から、フロントエンドでパフォーマンスを向上させる「フロントエンド・エンジニアリング」の重要性を説いておりその内容には裏づけされたデータや解説など納得することばかり!!

各章は、HTTPプロトコルの解説、通信時の動作、ブラウザのHTMLレンダリングの仕組み、ホワイトスクリーン現象など、14のカテゴリーから構成され、多数のパフォーマンスを上げる手法を惜しむことなく紹介しています。
最近ほとんどWebの仕事しかやっていない僕にとってはかなりうれしい内容ばかりで、第1章を読むだけでも目から鱗もんですたいよ。

実際、Webサイトのエンドユーザの応答時間のうち、HTML文書のダウンロードにかかる時間は10%から20%にすぎない。残りの80%から90%はページ内の全てのコンポーネントをダウンロードするのに消費されるとのこと。

ちょっと内容を紹介すると、レンダリングを優先する通常思いつく手法として、CSSをページの最後に置くということが思いつきますが、実はパフォーマンス的には良くないらしく、最後に置くことによってプログレッシブレンダリング(ページを除々に表示)ができなくなってしまい、レンダリング速度が遅くなってしまいます。
また、スクリプトの場合はCSSの場合と逆で、スクリプトを最初に持ってきてしまうと、スクリプトの下に配置したすべてのコンテンツがブロックされてしまい、コンテンツの並列ダウンロードが止まってしまうのでスクリプトに関してはページのなるべく下に配置したほうがよいなど、バックエンドの対応に比べたら短時間で対応できそうなところがとてもスバラシイですね。

本書で紹介されている方法で、アプリを実行した場合の計測結果を一部のせておきます。

ルール1:HTTPリクエストを減らす

アイコン等の多数の小さい画像を使用している場合、その数だけレスポンスが発生してしまい、パフォーマンス的にはよくないそうです。
この場合、イメージマップやCSSスプライトを使用すると、レスポンス数が極端にいうと1回で済むことになり、パフォーマンスが向上します。

イコン画像をそのまま単体イメージで使う場合


イメージマップを使用した場合


CSSスプライトを使用した場合


ルール4:コンポーネントgzipする

コンポーネントを圧縮することによって転送時間を短縮でき、圧縮している場合としていない場合では、以下のような違いが現れる。

gzipを使用していない場合


gzipを使用した場合