モバイル時代を生き抜くためのWebパフォーマンスモデル「RAIL」 ~Response,Animation,Idle,Loadから来る「速さの目安」を知って改善しよう!~

第3回 Webの「Load(読込み)」を改善しよう(前篇)

この記事を読むのに必要な時間:およそ 4 分

はじめに

Webページの読み込みは,ブラウザが生まれて以来,変わることなく持ち続けたコアの機能です。誰もが無意識のうちにその機能に触れており,もはや当たり前のようにそこに存在しています。

前回その機能の中には他のタスクをブロックするような処理が含まれており,ブラウザを複雑にしていると説明しました。ブラウザはその仕組み上,CPUやネットワークのリソースをフル活用することが難しいのです。Webのパフォーマンスモデル「RAIL」では,これらの課題をなんとかクリアし,Webページの読み込みを表すL(Load)が1,000ミリ秒未満となることを推奨しています。これは,とてもシビアな時間です。

一言にLoadとは言っても,ユーザ体験に及ぼす要因は多く,そのメトリクスは多岐に渡ります。皆さんのWebサイトの置かれている状況に合わせて,Loadの意味を適切な指標に読み替え,最適なブロック解決方法を選択し,最適化を進めていかなくてはいけません。

このあたりの理解を持つために,まずはブラウザの中でどのような処理が行われているのか,前回とは別の観点から見てみましょう。

Webページの表示には,様々なブロック要因が潜んでいる

ブラウザは,ハイパーリンクがクリックされたり,あるいはブックマークからWebサイトを指定されると,DNSによる名前解決や,サーバとのTLS鍵交換,TCPスリーウェイハンドシェイクなどを経て,HTMLドキュメントの読み込みを開始します。

図1 ブラウザでURLを開くときの処理

図1 ブラウザでURLを開くときの処理

HTMLドキュメントは,TCPを通じてブラウザ内のバッファへと徐々に蓄積されていきます。ブラウザは何も処理を行っていない場合,バッファに置かれた分のHTMLドキュメントを読み込み,パースし,レイアウトを決定し,スクリーン上へと描画します。Webページは,HTMLドキュメントが読み込まれた分に応じて,徐々にスクリーン上へと描かれていくことになります。

その際,パース処理は大きく分けて2種類の状態を持ちます。Chromeではこれらを「ドキュメントパース」「プリロードスキャン」と呼んでいます。これらの状態は,FirefoxやIE,Safariであっても共通して持っています。Web標準として決められたものではありませんが,実質的にどのブラウザも同じように振る舞います。

ブラウザは通常時は,ドキュメントパースが動き続けます。バッファから取得したHTMLドキュメントを最初から順番に解釈し,その過程でCSSや画像ファイルなどのリソースが必要だとわかると,その都度ダウンロードを開始していきます。そして淡々とレイアウトを決定し,ブラウザ上への描画を行っていきます。

図2 ドキュメントパース

図2 ドキュメントパース

しかし,JavaScriptとCSSだけは「描画ブロッキング」という特徴を持っています。これらはリソースをダウンロードし内容を解釈して実行されるまで,その先のHTMLドキュメントをパースすることができません。結果,レイアウトを決めることができないため,描画が一切行えなくなってしまいます。

ダウンロードの処理自体は平行して行うことができ,1つのドメインに対して,最大6つまで接続できます。なのに,JavaScriptやCSSが発見される都度,HTMLドキュメントのパースを止め,リソースがダウンロードされるのを待っているようでは,ネットワークの効率がとても悪くなってしまいます。どうせなら,複数平行してリソースをダウンロードしてしまいたいところです。

では,どうすればよいでしょうか? ブラウザはブロックされている間も,HTMLドキュメントは淡々とダウンロードし,バッファに置いています。その中身を覗けば,これから先ダウンロードを必要とするようなリソースを見つけることができるはずです。

そこでブラウザは,ブロック中も,バッファ内のHTMLドキュメントを常に最後までスキャンし続け,リソースだけを先にダウンロードするという動作を行います。これを,プリロードスキャンと呼びます。

図3 プリロードスキャン

図3 プリロードスキャン

プリロードスキャンは,通常時のドキュメントパースの時とは違い,あまり複雑な処理を行いません。淡々とリソースを見つけ,素直にダウンロードし続けます。CSSで非可視化され,今すぐに必要とはしないような画像ファイルであっても,それを知る術はプリロードスキャンにはなく,どんなリソースであっても無差別にダウンロードしていきます。リソース読み込みに対する制限(Content Security Policy)がHTMLドキュメント内で行われている場合,何もスキャンしないという極端な選択を行ったりもします。

プリロードスキャンはネットワークを効率的に扱うことができる反面,ブロックの要因となるリソースの特性次第では,その読み込みを遅延させてしまうリスクを持ちます。ブラウザは平行してリソースをダウンロードできる,とは言いましたが,その際に利用するネットワークは同じものを共有しており,帯域にも限界があります。他のリソースのダウンロードに帯域が逼迫され,ブロック要因となっているリソースの読み込みが遅れてしまうということは,往々にしてよくあることです。

さて,Webページの読み込みの仕組みがだいたい把握できたところで,ここからは「速さ」を決定づける3つの指標について紹介します。

  1. Speed Index
  2. Hero Image Custome Metrics
  3. ATF Time

著者プロフィール

川田寛(かわだひろし)

元NTTグループのSE。現在はピクシブ株式会社にて,テクノロジーで世の中のクリエーターをハッピーにする方法を模索しています。「ふろしき」の愛称で,「html5jパフォーマンス部」「日本Cordovaユーザーグループ」といったコミュニティを立ち上げたり,「東京 Web パフォーマンス」というコアなエンジニア向けの勉強会を主催したり,Webの標準化(W3C)の議論にほんの少しだけ横槍を入れてみたり。

Microsoft MVP 2014/2015受賞。HTML5 Experts.jpエキスパート。Developers Summit(翔泳社)ステアリングコミッティー。「Web標準技術ではじめる,Webのパフォーマンス改善(Software Design 2014年5~7月号)」他,多数の技術雑誌への寄稿も行う。

コメント

コメントの記入