HTTPリクエストの削減とWebサイト高速化まわり

/web/html-css

Note: この記事は、3年以上前に書かれています。Webの進化は速い！情報の正確性は自己責任で判断してください。

メモ書き。社内説得用。「HTTPリクエストを減らすと高速化できるよ！」てのはよく聞くけど、それが「どうしてか」ってのを(読込待機時間まわりで)具体的な数字を出してることが意外と少なかったので。詳しくは参考リンクにGo!

Webサイトを分析するWebアプリ
参考資料など

まずHTTPリクエストがコストが高い理由ですが、まあ同時読込できないからですよね。読込に1秒掛かる画像A,B,Cがあるとして、いっせーのーで！で読込開始できるなら1秒で終わるけど、リレー方式で先発がバトン運んでくるのを待たないといけないからA→B→Cで3秒は掛かっちゃうと。しかもバトンを受け取るタイムラグもあるから3.5秒くらい掛かるかもしれない。

Koji ISHIMOTOが比較用のファイルAとファイルBを用意してくれました。一目瞭然ですねThx!

  • ブラウザの同時接続数は2-6くらい
  • 細かい画像ファイルがたくさんあると、長い待ち時間が発生する
  • CSSで使う画像はCSS Spriteに。CSSそのものも1ファイルに

関連して@importがダメな理由。これは単純にHTTPリクエストが増える、てのもあるんですが、<link>要素と@importで読込方法が分散している時点でシーケンシャルロード(順番に読み込む)になってしまうのでコストが大きいと。

  • HTTPリクエストが増える
  • @importで指定したCSSは、順番に読み込まれる
  • ページ読込開始後に割り込むこともありうる？
  • CSS読込完了を待ってレンダリングされる？
  • いずれにせよレンダリングが遅くなる。

前提そのいち。ページのレンダリングは<head>内に書かれたCSSの、読込完了を待って行われます。前提そのに。@importを使用すると、シーケンシャルロードになってしまいます。結果。レンダリングが全CSSの読込完了まで待ってくれるのか、んなもん関係なしにレンダリング開始しちゃってリフロー発生あぼーんなのかは知りませんが、いずれにせよ遅くなるわけですね。この辺、資料に心当たりあるかたいたら教えて欲しいです。

総括

Yahoo!レベルのアクセスあれば、そりゃ何やっても効果でるだろーHA-HA-HA! ...みたいに考えてた時期が、俺にもありました。

最近スクラッチでスマホサイト作る機会に恵まれたので、改めて調べ直しているわけですが、先のby Koji ISHIMOTOの参考ファイルとか、けっこうハッキリ効果わかりますよね。猛省しております。せめてアイコン画像だけでもSpriteにきっちり纏めるとか、Webフォント・アイコンを導入するなりでHTTPリクエストを節約することには、コストに見合う価値があると認めましょう。

Webフォントアイコンに使用される文字はHTML的には無意味なので、そのまま使うのは難あり。
ですが ::before/::after 内で content で使う分には問題ないですよね。

あと運用に任せたJS/CSSとか、あらためて解析すると肥大しすぎた感があったりして、しかし触るのは怖すぎたりしてたのですけど... せめてYUI compressorで圧縮・統合するとか、元ファイルに触らないでclosure-compilerに掛けるだけでも検討する価値はあるのかなー、とかとか。

Note: スパム対策が面倒なので、コメント投稿を廃止しました。以前のコメントは残します。
ご意見・ご要望はtwitter@sigwygかはてブコメントにて。