パフォーマンスチューニング – HTML5Experts.jp

Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(3/3)

川田寛 — Fri, 09 May 2014 00:00:31 +0000

いよいよHTMLドキュメントのダウンロードと、画面上への表示です。この動作の仕組みから、TATの「終了」がいつなのかを追ってみましょう。「終了」についてはかなり奥が深く、Web標準でもそのプロセスを「The End」として定義はしていますが、それだけでは語りきれない難しさがあります。

4. TCP接続、5. HTTPリクエスト/レスポンス

名前解決で得られたIPアドレスを使って、HTMLドキュメントが置かれたサーバへ「4. TCP接続」します。いわゆる、3ウェイハンドシェークというものです。サーバとの接続交渉が終わると、HTTPリクエストをサーバへ送信し、HTTPレスポンスを受け取ります。

HTTPレスポンスの結果からリダイレクトであることが発覚した場合、「2. キャッシュ確認」からやり直しです。この、リダイレクト動作にかかった時間もNavigation Timingでは取得でき、「redirectStart」「redirectEnd」の各プロパティを通じて取得することができます。

HTTPレスポンスから得られたデータは、いったん蓄積され、この後のDOMの生成で利用されることになります。

6. DOM生成

さて、ここからがブラウザの一番の見せ場、サーバから受信したHTMLドキュメントからDOMを生成し、描画を行うフェーズです。

HTML5のスペック「8.2章 Parsing HTML documents」に内部的な動作が定義されており、これに従い計測値が取得されます。このフェーズで意識すべきなのが、「①. HTMLドキュメント自体の読み込みを行っている段階(domLoading)」と「②. HTMLドキュメントの読み込みが完了し非同期に取得できる画像などのリソースを読み込んでいる段階(domInteractive)」の、2段階のステージです。

1段回目、domLoadingの段階。HTMLドキュメントの読み込みには、8KBというマジックナンバーが隠されています。これは、ブラウザがHTMLドキュメントの内容をパースする際に、一括で読み込みを行う単位と考えると良いでしょう。ブラウザはサーバから受信したHTMLドキュメントを、8KBずつ逐次パースし、DOM Contentを作っていきます。

JavaScript/CSSのような即時で反映する必要があるファイルの参照があった場合、HTMLドキュメントの受信は継続しますが、HTMLパース処理は停止し、JavaScript/CSSのコンパイルと実行を優先します。

DOM Contentの生成が終わった状態を、HTML5のスペックでは「interactive」と定義しています。JavaScriptにて「DOMContentLoadedイベント」を登録していた場合は、このタイミングで発火します。

7. リソース読み込み

ここからは、2段階目の説明に入ります。HTMLドキュメントが全て読み込まれ、画像などの非同期で読み込めるリソースを読み込んでいる段階です。先ほども説明しましたが、Web標準ではこの段階のことをinteractive(対話可能)と呼んでおり、名前の通り、画像の読み込み完了を待たずしてユーザからの入力を受付けることができます。

実は、ブラウザはHTMLドキュメントを読み込みつつリアルタイムに画面上へ表示する(ChromeはHTMLドキュメントのダウンロード完了時に表示する)という実装なため、「6. DOM生成」の段階でも既に入力可能だったりします。どちらをTATの開始と呼ぶべきか、非常に悩ましいところです。

画像の読み込みが完了し、Webページが完成したタイミングで「complete」という状態に推移します。completeへ推移すると、JavaScriptのloadイベントが発火します。ここで再び、ブラウザはJavaScriptの処理を動かすために、入力をブロックさせたりします。場合によっては、この段階でユーザからの入力を受け付けるために必要な、初期化処理を行なったりもします。例えば、jQueryの有名なプラグインであるDatePickerなんかは、loadイベント内で設定することが多く、ここに来るまでフォーカスを当ててもカレンダが表示されません。interactiveなんて言われていますが、実際にはloadイベントを実行するまではTATの終了とは言えないような気もしますね。ここまでくると、もはや終了の概念そのものをどう定義すべきかが、だんだんわからなくなってきました。

loadイベントの処理が完了すると、Navigation Timingで計測できる全ての処理が完了です。

なお、ここまでの過程で、JavaScriptやCSS、画像などの外部ファイルの読み込みを行っていますが、これら単独リソースごとの性能計測は、Web標準として少し扱いが異なります。詳しくは、「Resource Timing」を参照すると良いでしょう。

何をもってTATとするか？

ブラウザの仕組みについて一通り紹介したところで、TATを構成する要素が以下に分類できることが理解頂けたでしょう。この中のどこかに開始を作り、どこかに終了を作れば、あなたの求めるTATになるはずです！

開始候補、終了候補、なんて言葉を使ってみましたが、ここまでくるともはや、TATを取得することに意味があるのか？なんて思われても仕方ありません。実際のところ本当にその通りで、TATだけをピンポイントで取得しても、あまり役に立たなかったりします。

Navigation Timingはそもそも、ナビゲーションの動作の中から、性能のボトルネックを探すためのものです。生きた計測値を得るためのものです。ブラウザはナビゲーションを開始すると、様々なキャッシュを駆使して最小限で動作することを追求し、そして終了に向けて、DOM生成やリソースの取得、JavaScriptの初期実行を行い、最大限のポテンシャルを発揮しようとします。こうしたブラウザのメカニズムの中から、ボトルネックを探さなくてはいけないのですから、Navigation TimingはWebページの特性に合わせて、有用な情報を拾えるようにしなくてはいけません。

リソースの取得については「Resource Timing」、JavaScriptの性能に影響を与えるような処理に対しては、「High Resolution Time」のnow()なんかを利用して、計測を行うことが求められるでしょう。

パフォーマンスの改善は、まさに総合競技です。JavaScriptやCSS単独の高速化手法だけ知っててもダメだし、DBのパラメータチューニングだけできてもダメです。JavaやASP.NETやRuby On Railsも、全体から見ればほんの一部でしかありません。DNSやWebサーバ、APミドルなどのインフラも重要な構成要素ですし、私のようにイントラ向けのシステム開発を行なっている方はネットワーク装置の一台まで面倒を見ていることもあるでしょう。最近はクラウドも絡んできたりして、バックプレーンを共有する他社のWebアプリが性能に影響を与えるなんてのも聞いたことがあります。複雑化が進んでおり、ますます全体を見る目が求められているように思えます。

ところが、パフォーマンスの問題にぶつかると、どうしても自分の専門分野で見てしまい、DBだけを良くしようとしたり、JavaScriptだけを高速化しようと先走ってしまうことがあります。

Navigation Timingを入り口にして、生の測定値に基づき分析し、ブレークダウンしてみて下さい。きっとそれは、改善の近道となり、費用対効果の高い手段を見つけるヒントとなるでしょう。そしてWebアプリは、最高のパフォーマンスを得ることができるはずです。

Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(2/3)

川田寛 — Thu, 08 May 2014 00:00:27 +0000

連載：パフォーマンスチューニング (10)

前回の記事でもお伝えしたとおり、ブラウザのメカニズムが、TATの計測を複雑にしています。その事情について、まずTATの「開始」をどこにするかについて考え、紐解いてみましょう。Web標準で定義するところのブラウザの動作について、少しだけデフォルメさせた処理モデルを使って、全体の流れを解説します。以下の図の赤字はtimingオブジェクト配下にあるプロパティ、数字が振ってある矢印は処理の流れです。

0. ナビゲーション開始

Webページの読み込み動作を、「ナビゲーション」と呼びます。ブラウザは、ネットワーク上のHTMLドキュメントにアクセスすると、Webページを構成する様々な情報を削除(アンロード)します。そして、新しくHTMLドキュメントを読み込み、DOMを構成し、JavaScriptやCSS、画像などのリソースを取得しながらWebページの描画を進めていきます。この一連の動作が、ナビゲーションです。

近年は、「SPA(Single-page Application)」と呼ばれるアーキテクチャがあり、DOM操作により画面遷移を擬似的に表現する手法もありますが、この仕組みではナビゲーションを開始できません。あくまで、JavaScript APIやプラグインの力を借りず、ブラウザの機能を使ってWebページを遷移させることで、ナビゲーションは開始されます。

ナビゲーションは、ハイパーリンクのクリックもあれば、Formを使ってサブミットすることでも発生します。戻る/進むボタンやリロードボタンを押下した際も、同様です。こうした、様々なナビゲーションを発生させるアクションは、ブラウザのキャッシュの動作、ナビゲーション全体の動作への影響が大きいため、Navigation Timingを扱う際に理解することが求められます。

Web標準では、こうしたナビゲーションの種類を「PerformanceNavigation」として以下のように分類しています。まずは、この定義を中心としてその違いを把握してみましょう。

TYPE_NAVIGATE : ハイパーリンクのクリック、ブックマーク等。
TYPE_RELOAD : ブラウザのリロードボタン押下。
TYPE_BACK_FORWARD : ブラウザの戻る/進むボタン押下。
TYPE_RESERVED : 未定義のWebページ読み込みアクション。

「TYPE_NAVIGATE」は、ハイパーリンクをクリックした際や、フォームをサブミットした際に発生する、一般的なナビゲーション動作です。ナビゲーションバーへURLを入力しEnterキーを押下した際、ブックマークを開いた際もこの動作であり、基本はこのアクションが選択されると想定すべきでしょう。後に説明する、「RFC 2616」のHTTP Cacheが最大限に活用されるのも、このナビゲーション動作です。

「TYPE_BACK_FORWARD」は、基本的には「戻る/進む」ボタンを押下した際に発生します。Web標準で言うところの「履歴移動(History Traversal)」により発生したナビゲーションです。ただ、「フラグメント識別子(Fragment Identifier)」を利用したURLを扱った場合、ナビゲーションを伴わないWebページ内の移動を行うことがあります。また、Webページが一定の条件を満足すると、ナビゲーション発生時に、前のWebページ全体をそのままキャッシュさせることで、戻るボタンのパフォーマンスを改善しようとします。このような動作を行なった場合、戻るボタンを押下してもナビゲーションは発生しません。

「TYPE_RELOAD」は、「リロードボタン(再読み込み)」を押下した際に発生します。ブラウザによってCtrl/Shiftとリロードボタンを同時押しすることで、HTTP Cacheの一切を破棄しWebページの再読み込みを行う「スーパーリロード(強制再読み込み)」と呼ばれる機能があります。Navigation Timingではこれを区別することなく「TYPE_RELOAD」として扱いますが、実際のキャッシュの動作は大きく異なるものとなるため、明確に区別する必要があります。

「TYPE_RESERVED」については未定義であり、ブラウザでWebページを扱っている範囲では、あまり意識する必要はありません。

1. アンロード

ナビゲーションが開始され、標準的なブラウザはまず「1. アンロード」という処理を行います。ブラウザは、今表示しているWebページのリソースを破棄し、次のWebページを表示する準備をするわけです。DOMの情報を持つDOM Contentや、JavaScriptの機能の初期化を行います。

Web標準では、この処理を「unloadイベント」として捕捉でき、Navigation Timingを利用してイベント発生前後の時間を取得することができます。ただ、このタイミングは常に一定しているとは限りません。^{(※ 注１)}表面的には、アンロードはこのタイミングで発生しているように見せてはいますが、実装ではブラウザのレンダリングエンジンによってバラツキがあり、この処理の負荷が、この後説明するDOM読み込みのタイミングに大きな影響を与えることがあります。

また、「戻る/進む」ボタンを押下した場合の動作も独特です。先ほども少し説明しましたが、Webページは一定の条件を満足すると、アンロードを行わずメモリ上にWebページをまるごとキャッシュさせます。この動作は、例えばIE11だとデベロッパーセンター、FirefoxだとMDNのドキュメントに仕組みが掲載されており、ブラウザごとにやや異なる思想を持っていることも把握できるはずです。HTML5の「pageshow/pagehide」イベントで捕捉でき、ある程度の制御が可能なわけですが、基本的にこの動作、ナビゲーションが発生しないのですから、Navigation Timingのプロパティの値も更新されません。

2. キャッシュ確認

標準的なブラウザがアンロードを終わらせると、「2. キャッシュ確認」を行います。Webページの表示に必要なHTMLドキュメントを、キャッシュの中から探すわけです。キャッシュと言っても、ブラウザのみで有効性判断ができるものあれば、サーバに問い合わせを行わないと判断できないものもります。ここでチェックされるのは、あくまで前者のみです。HTML5の「AppCache」や、「RFC 2616(13.5)」で定義されたHTTPヘッダのプロパティ「Expires(14.2)」「Cache-Control max-age(14.9)」によるHTTP Cacheなんかは古くから活用されているため、ご存知の方も多いでしょう。

AppCacheは、常にこの段階で読み込みが行われます。しかし、HTTP Cache(Expires)により得られるゆるいキャッシュは、TYPE_NAVIGATEの場合のみ、ブラウザ内のキャッシュを利用します。この仕様は動作チェックの際に問題となることがあり、誤ってリロードボタンを押下してテストしようものなら、テスト担当者は一日を無駄に過ごすことになります。(※ アドレスバーにフォーカスを当ててEnterキーを押下、がキャッシュのテストの鉄則です！)

Chromeだけは、やや動作が例外的です。Chromeは、HTMLドキュメント内から参照されるJS/CSS/画像ファイルのようなリソースでも無い限り、HTTP Cacheによるブラウザ内のキャッシュを利用してくれません。XHR(XMLHTTPRequest)についても同様で、Chromeだけは必ずサーバへのアクセスを伴います。そもそも、Webページはサーバサイドのプログラムで動的に生成するのが殆どなので、HTMLドキュメントのキャッシュは期待できないものと見なすべきでしょう。

3. 名前解決

標準的なブラウザは、有効なキャッシュを発見できなかった場合、HTMLドキュメントが置かれているサーバの場所を特定するため「3. 名前解決」を行います。

名前解決については、Linux/OS X/iOS上のブラウザについては、基本的にDNS名として扱い名前解決を行います。しかし、Windows OS上のブラウザは、微妙に同じ動作にはなりません。Windows OS上のブラウザは、ドメイン名をフルコンピュータ名というやや特殊な概念として扱い、NetBIOS(WINS)名とDNS名の2つの名前の概念を扱うハイブリッドな名前解決を行います。

これは、ブラウザの仕様というより、OSの持つTCP/IPモジュールの仕様の違いです。IEとFirefox/Chromeとで異なるAPIをコールしていますが、どちらも最終的には同じWinSock2の名前解決のメカニズムを利用します。名前解決を行うリゾルバにも、OSによる動作の違いがありますが、DNSを使っている限り、機能面において、ブラウザからはあまり意識する必要がありません。

インターネット向けでは、各プロバイダが提供するDNSサーバの性能が関わってくることもあります。DNSもやはり、キャッシュが要です。DNSを構成する各ノードのキャッシュの動作次第で、性能は大きく変化します。TTL設定のチューニング、DNS Prefetchを活用して対策してみると良いでしょう。

キャッシュだらけ！

ナビゲーションの動作のうち、どこをTATの開始とすべきか？もうお分かりと思いますが、キャッシュだらけで、前提条件から疑いにかからなくてはいけません！Webページ自体の(アンロード絡み)のキャッシュ、HTML5 AppCacheやRFC 2616によるブラウザ側のキャッシュ、名前解決絡みのキャッシュと、まだWebサーバにアクセスしていないというのに、これだけのキャッシュが絡んでいます。

最初にご紹介した「navigationStart」は、こうした前の画面の動作を含んだ計測値です。アンロードや、この後説明するリダイレクトを含めるとなると、開始をどこに置くのかというのもまた難しくなってきます。

TATの本当に難しさはここだけではありません。TATの「終了」の扱い、これも難しかったりします。ブラウザのメカニズムを掘り下げて追ってみましょう。

「Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(3/3)」に続きます。(※5/9公開予定)

※注1 : 実装では、Chromeのアンロードはこのタイミングには行われていません。気になる方は、Chronium35であれば./core/loader/DocumentLoader.cpp(startLoadingMainResource)を確認してみると良いでしょう。PerformanceTiming::markNavigationStart()の後にPerformanceTiming::markFetchStart()を呼び出しており、アンロードは遅延して実行していることが読み取れます。なお、Chromeのアンロードは、HTMLドキュメントのHTTP受信完了時に発生します。このあたりは、./core/loader/DocumentLoader.cpp(finishedLoading)あたりが動作を理解するのに適しており、commitIfReady()の実装を掘っていくと、./core/loader/FrameLoader.cpp FrameLoader::commitProvisionalLoad→FrameLoader::closeURL…と進み、最終的にunloadイベント発火のタイミングをマークしている処理に到達します。

Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(1/3)

川田寛 — Fri, 02 May 2014 03:00:11 +0000

連載：パフォーマンスチューニング (9)

こんにちは、html5jパフォーマンス部、スタッフの川田です。5月8日ですが、私たちのコミュニティ主催で勉強会を開催することになりました！！

そして、残念なお知らせです。募集した直後に、席が埋まってしまいました！せっかく、これだけ多くの方にパフォーマンスへ興味を持っていただいたのに、このままじゃもったいない！

なので本記事では、この勉強会で語られない、別の切り口からパフォーマンスについて語ってみようかと思います。内容は、私が技術評論社「Software Design 2014年5〜7月号」にて連載しております、「Web標準技術で行う、Webアプリのパフォーマンス改善」で扱っているテーマの一部を、Web向けに書き直したものです。

Webアプリのパフォーマンス計測は簡単なのか？

パフォーマンスは、メモリを節約するものからCPUコストを下げるものまで、様々な種類があります。本記事では「ターンアラウンドタイム(TAT)」という指標値について考えてみましょう。

TATとは、アプリケーションの応答速度を表す指標の一つです。厳密には、あるアプリケーション・サーバに対して、ユーザが何かしらの操作・入力を行ってから、アプリが反応し終わり、ユーザが再び入力を受け付けることができるような状態になるまでの時間、と定義されています。Webページが遷移する時間を、定量的に評価できる指標値ということになります。

このTATという考え方、そんなにマニアックなものというものでもなく、レスポンスタイムやスループット、アベイラビリティなどと同様に、古くから存在する非機能要求の項目です。IPAの情報処理試験でもよく見かける、有名なキーワードに思えるでしょう。ところが、これをWebを検索しても、なかなかしっくりくる計測手段が見つかりません！この問題、特にWebに限定した話というものでもないはずです。GUIレベルでの性能計測は、昔からある悩みの一つで、アナログにストップウォッチの力を借りるなんてことも割とよく聞く話です。筆者もIE6全盛のWebアプリ開発で、同じ悩みを抱えたことがあります。

今回、そんなTATをめぐる悩みに対して、ちょっとしたヒントをご紹介します。ブラウザの仕組みを探り、WebアプリのTATとは何かを探り、そして標準的な手段の中からその計測方法について探ってみましょう。「そもそも、そんな指標で評価することに価値があるのか！？」なんて議論も生じていたりするのですが、その点は一番最後に触れるとして、今回はTATという切り口からWebページの性能について考えてみます。

TATの計測で、Webサーバのログはアテになるのか？

SPDYなどの新しいプロトコルのことは一旦忘れて、シンプルなHTTP1.Xを前提に考えてみて下さい。HTTP1.Xは、HTMLドキュメント取得し、HTMLドキュメント内で参照されている必要なJavaScript/CSS/画像などの外部リソースを、逐次取得し表示していくという仕組みです。サーバサイドで動的にHTMLを生成するようなアプリだと、画面を遷移する都度、最低でもHTMLドキュメント程度はサーバ側から取得することになります。

この動きに注目し、計測で非常によく利用されるのが、Webサーバログの「リクエスト処理時間(Time taken to process the request)」です。Apache HTTP Serverのアクセスログのフォーマットオプション「%D」あたりは有名でしょう。このオプションは、HTTPリクエストを受け付けた瞬間から、サーバで処理が行われ、データを出力し終わるまでの時間を、マイクロ秒単位で計測する機能です。TomcatやJBossのようなJavaミドル、MicrosoftのIIS(Internet Information Services)でも、リクエスト処理時間をミリ秒で計測できる機能を実装しており、大抵のWebアプリでは活用できるコモディティ化した機能と言えます。

リクエスト処理時間は、実際にサーバ上の問題を発見するのに価値が高い計測値です。運用時には、キャパシティプランニングの目安や、障害発生時の解析に活用されたりします。また、お客様と品質保証の明確な基準を決める「SLA(Service-Level Agreement)」でも、アクセスの何％を保障するかという「パーセンタイル」を配慮した形で活用することがあります。どこにでも目にするこの計測値、一見すると使い道が広く、万能な値に見えるでしょう。

ところが残念なことに、リクエスト処理時間は、キャッシュされていないごく一部のファイル/プログラム単位の性能しか評価できません。サーバがどの程度のリクエストを捌けるのかを判断する「スループット(＝処理能力)」の指標値として扱うには高い価値を発揮しますが、TATの指標値として扱うには、対象が局所的で、不足が大きすぎます。サーバから見ると性能は高いのに、クライアントで見ると画面はいつになっても白いまま！なんてことになりかねません。

では、TATを計測するにはどうすればよいのでしょうか？画面を表示する際のもっさり感の原因は、どのように探ればよいのでしょうか？このあたり、最近のWeb標準がかなり力を入れています。2012年12月にW3C勧告となった「Navigation Timing(ver.1)」がまさにその代表的なスペックです。

Navigation Timingを含むWebのパフォーマンスに関する仕様は、2010年にW3Cで設立された「Web Performance Working Group(WebPerf WG)」で議論され、IE9+、Firefox、Chromeなどのブラウザにその成果が反映されています。Facebookのザッカーバーグ氏がHTML5に失望し、同社のアプリをネイティブに書き換えるという有名な事件がありますが、そんな彼らも同WGの設立直後すぐに反応し、WGの議論に参加しています。2013年には「Web vs ネイティブ」という議論が盛り上がりましたが、WebPerf WGの取り組みは、現在のWebが抱える性能という問題を見つめていく上で、注目すべき重要なポイントと言えるでしょう。

Navigation Timingの使い方、TATの計測方法

Navigation Timingでは、ハイパーリンクをクリックした瞬間からWebページが利用できるようになるまでを、ブラウザの内部的な動作である「処理モデル(Processing Model)」として定義し、その経過時間を取得することができます。

ブラウザ自体にも「開発者ツール」として計測のためのツールが備わっていますが、ブラウザごとに考え方も違うし、活用できる場も開発時のみと非常に限定的です。Navigation TimingはWeb標準なので、ブラウザに依存しない共通の考え方で計測値を扱え、また運用時にもJavaScript上で生のデータを収集することができる点で、開発者ツールより高いポテンシャルを得ています。

実際のJavaScriptの仕様を見ながら確認してみましょう。

windowオブジェクト配下にある「performance」は、パフォーマンス関連のJavaScript APIにアクセスするための入り口となるオブジェクトです。そのさらに下に、WebPerf WGの成果である様々なスペックの実装が分類別で並んでいます。そのうちのひとつである「timing」の配下には、ハイパーリンクをクリックしてから応答するまでの間に発生する、様々な動作発生時のタイムスタンプを取得できるプロパティが並んでいます。

TATを取得しコンソールに表示させる、シンプルなコードを確認し、使い方を掴んでみましょう。

/* timingオブジェクトの取得 */
var timing = ( window.performance || {} ).timing;
/* TATの計測 */
timing && window.addEventListener( "load", function() {
    setTimeout( function() {
        var tat = timing.loadEventEnd - timing.navigationStart;
        console.log( "TAT = " + tat );
    },1);
},false);

「timing.navigationStart」はハイパーリンクがクリックされた直後の時間、「timing.loadEventEnd」はWebページが表示されJavaScriptのloadイベントの処理が完了した直後の時間が取得できるプロパティです。サンプルでは、この2つの単純な差分を、仮にTATとしてみました。setTimeoutで実行時間を遅延させているのは、loadEventEndがloadイベント中だと未計測の状態「0」を返してしまうという問題への対策です。

このサンプルで得られる計測値が、TATとして「ほぼ正解」の値ということになります。ただ、ほぼ正解であって、完全な正解とは言えません。このあたりの理由については、ブラウザの内部のメカニズムによるところが大きかったりします。具体的には何が原因なのか、これから見ていきましょう。

※ 修正 2014.5.11：矢倉眞隆さんからのご指摘により、サンプルのwindow.performanceのベンダプレフィクスは削除しました。IE9+を含む近年のブラウザでは、3年近く前にベンダプレフィクスが消えており、無意味であると判断できたためです。

Webアニメーションを高速化するために知っておくべき10のこと（後編）

斉藤祐也 — Thu, 26 Sep 2013 22:00:07 +0000

連載：パフォーマンスチューニング (8)

前編から引き続き、後編でも最適化のために知っておきたいレンダリングプロセス、計測方法、そして最適化を妨げるよくあるアクシデントとその回避方法について紹介していきます。

アニメーションを高速化するために知っておきたいレンダリングプロセス

ブラウザがどのようにウェブサイトを表示しているのかを知ることは、アニメーションだけに限らず、Webのパフォーマンス全体の高速化を行うために大切なステップです。イスラエルの開発者であるTali Garsiel氏が公開した『How Browsers Work』は、HTML5 Rocksに転載され、複数の日本語訳も提供されている、ブラウザの内部動作を学ぶために読んでおきたいリソースの1つです。そのリソースを参考に、レンダリングエンジンのメインフローについて見ていきましょう。

ブラウザはまずHTMLドキュメントを解析し、HTMLタグをコンテント・ツリーと呼ばれるDOMノードに変換します。そして外部CSSやスタイル要素に含まれるスタイルに関するデータを解析し、レンダーツリーを作成します。
このレンダーツリーが色や大きさのような情報を持つ矩形を持っています。

ここから先が特にアニメーションのパフォーマンスに関わりの深いフローになりますが、レンダーツリーが作成された後、レイアウト(リフロー)と呼ばれるプロセスに入り、そしてペイントがそれに続きます。

ここでは非常に大まかな流れしか解説しませんが、Paul Irish氏が言うとおり、ブラウザがHTMLやCSSを画面に表示するまでのフローを理解することは、開発におけるベストプラクティスの背後にある根拠を理解する手助けとなります。少々慣れない用語が多いかもしれませんが、ぜひ先ほど紹介した記事を一読ください。

アニメーション・ボトルネック: レイアウト(リフロー)

Google ChromeやSafariなどのWebKit系ブラウザではレイアウト、FirefoxなどのGecko系ブラウザではリフローと呼ばれるプロセスは、パフォーマンス向上において大きな障害となるプロセスの1つです。
Satoshi Ueyama氏が2007年に『出張 Shibuya.js 24』にて発表した際に使用した以下の動画で見ることができます。様々な大きさの矩形が徐々に配置されていくプロセスがレイアウト/リフローです。

Gecko Reflow Visualization

このレイアウトのプロセスを、どのように最小限に抑えることができるかが、アニメーションの高速化において大切なポイントになります。レイアウトを引き起こす原因について、詳しくはTony Gentilcore氏による「How (not) to trigger a layout in WebKit」を参考にしてください。
記事のタイトルにもある通り、あくまでWebKit系ブラウザのみに限定されていますし、2011年の記事でもありますので、必ずレイアウトの発生を確認できるツールを利用して確認することをおすすめします。
（執筆時点ではGoogle Chrome、Safariの開発者ツール、そして紹介記事から得た情報でしかありませんが、IE11の開発者ツールでもレイアウトの発生を確認できます）

アニメーション・ボトルネック:ペイント

やや乱暴ではありますが、ブラウザで何かを表示するということは、HTMLやCSSから得た情報を画像化して表示しているのと大きな差はないと言えます。　

CSS3がプロダクションレベルで利用されはじめた今、角丸やシャドウなどを画像を利用せずに表現することが当たり前になってきているかと思います。読み込む画像が少なくなれば、その画像を制作するコストも減り、画像の読み込みにかかるコストも減りますが、その代わりにブラウザがそのコストを背負ってくれているわけです（もちろん1対1の割合ではありませんが）。
この後の段でアクシデントとして紹介しますが、すべてのスタイルが同じコストでペイントを行うわけではなく、また組み合わせによってコストが甚大になるケースもあるので注意が必要になります。

ブラウザは、表示領域をいくつかのタイルとしてレンダリングを行います。それぞれの個別のタイルごとにレンダリングをし、その結果をキャッシュしていきます。
そのため、大きな領域でペイントを行うことを避ける必要があります。レイアウトと同様に、ペイントを行う範囲を最低限にしておくことがポイントになります。

アニメーションのパフォーマンスの計測、デバッグツール/ワークフロー

パフォーマンス最適化において、最も大事なことは計測することです。私自身もよく陥る失敗ですが、どこかで読んだから、以前はうまく回避できた問題だからと盲目的にそれらの情報を頼りにするのではなく、計測する方法をきちんと学び、計測を日々続けることがベストプラクティスです。

開発者ツールについての詳しい記事は今後本サイトで紹介される予定ですので、ここでは私が実際にアニメーションのパフォーマンスについて計測するのに利用しているツールとワークフローを、ほんの一部ですが紹介していきます。

パフォーマンス計測を行う上で欠かすことができないのが、Google Chrome Canaryの開発者ツールです。Chromeではなく、日々更新を続けていくCanaryを利用する理由は、計測ツールとしての機能の多さと深さがChromeとは異なるからです。

アニメーションの最適化という文脈においてタイムラインパネルは、エディタとブラウザの描画エリアと同じくらい見る画面です。

まずは上図の1、Framesタブに切り替えて、上図2のRecordボタンをクリックし、計測を行いたいアニメーションを実行します。

すると、上図のような棒グラフが記録されていきます。その下にある表は棒グラフをより詳細にしたものです。
棒グラフは、背が高ければ高いほど処理に時間がかかっているということになります。計測対象にもよりますが、グラフ上にある2本の線は30FPSと60FPSを示しています。60FPSを目指すのであれば、それ以上の高さになっている棒グラフの周りをドラッグすることで、下にある表にその選択したタイミング内の詳細情報を表示させることができるようになります。

表にある横グラフは、マウスオーバーさせることでその特定の処理についての詳細を見ることができます。
レイアウトやペイントがどの範囲で行われているか、そしてそれにかかっている時間がどのくらいか、などの情報を確認することが可能です。
これらの情報と最前にも紹介したレンダリングの仕組みの情報を踏まえて、トライアル&エラーを繰り返し、最適化を図っていくのが大まかなワークフローとなります。

アニメーションを遅くするよくあるアクシデント

最後にアニメーションのパフォーマンス最適化を妨げる、よくある3つのアクシデントを紹介します。

1つ目は本連載の前編でも少し触れたGPUにまつわるアクシデントです。
GPUを使ってRenderLayerを作成し、そのレイヤー上でアニメーションを行うことそのものはベストプラクティスと言えます。しかしCPUからGPUへのデータ転送にはコストがかかり、特にモバイルデバイスなどCPUもGPUも非力である場面で問題になります。

この問題については、Phamtom.jsの作者としてよく知られるAriya Hidayat氏によるデモが非常にわかりやすいです。デモそのものはこちらのcodepenで実際に動作しているので、参考にしてください。

Ariya Hidayat氏によるGPUへのデータアップロードデモ

それぞれのボックスの右上に数字があり、カウントされているのが確認できたでしょうか？　このカウントがCPUからGPUへのデータの転送数を示しています。このデータ転送が少ないほうがパフォーマンスはよくなります。
ですが、実際にデータ転送を行わないプロパティは非常に少なく、Ariya Hidayat氏によれば、opacity、transform、filterの3つのみと言われています。
アニメーションの表現としてデータ転送が回避できない場面が多いのも事実ですが、同時にデータ転送には相応のコストがかかることを知っておくことも大切です。

GPU関連でもう1つの落とし穴があります。GoogleのJake Archibald氏によるデモをご覧ください。

オレンジ色の矩形が、GPUによって処理されるComposited Layerを示しています。実際にComposited Layerを生成したかったのは左上の緑のボックスだけなのにも関わらず、どういうわけか見出しにもComposited Layerが生成されてしまいます。デスクトップ上であれば、このComposited Layerの生成にかかるコストは気にするほどのことでもありませんが、モバイルデバイスにおいては大きなコストになってしまいます。
この問題を回避するのにはシンプルな解決があります。

先ほどのデモ内においてはアニメーションする要素そのものに、z-index: 1を付与することで回避できます。
このアクシデントは、カルーセルのようなUIパターンによく見られます。自作する際も、すでにあるライブラリを利用する際も、思っていない場面でComposited Layerが生成されていないか確認し、z-indexを使って回避できるか試してみてください。

Ariya Hidayat氏によるW3Confでのプレゼンテーション『Fluid User Interface with Hardware Acceleration』はハードウェア・アクセラレーションを使った最適化を行うのにあたり、見ておくべきリソースの1つです。またThe Chromium ProjectsにてドキュメントされているGPU Accelerated Compositing in Chromeも参考になりますので、ぜひ一読してください。

ここで紹介する最後のよくあるアクシデントが、CSSプロパティの組み合わせによるペイントコストの増大です。このアクシデントはモバイルデバイスでよく見かけるものです。例えば、角丸とシャドウを組み合わせたボックス、非常によくあるスタイルにも関わらず、これらのスタイルがあると、とたんにスクロールが引っかかるように感じてしまうことがあります。この「引っかかる感じ」の原因の多くがペイントです。

どのプロパティの組み合わせがどれくらいのペイントコストとなるかを計測するためのツールは存在はしますが、ここでは紹介しきれませんので割愛します(チャレンジしてみたい方はこちらのドキュメントを参考にしてください。また取得方法は異なりますが、Colt McAnlis氏によるHTML5 Rocksの記事『CSS Paint Times and Page Render Weight』も合わせて参考にしてください。)。しかし前段で紹介したタイムラインパネルでもペイントコストを確認できますので、トライ&エラーを繰り返すことで、最適化を進められるでしょう。

前後編にわたってWebアニメーションの最適化について紹介してきました。
いずれブラウザや端末そのものも賢くなり、これらの知識やテクニックも早晩時代遅れになっていくだろうと思います。しかし、我々はその過渡期にいる最中です。「使いやすさ」を向上する上で欠かすことができない最適化は多くの苦難があっても報われるものです。

モバイルブラウザでもサクサクに動作する最適化6つのノウハウ

城戸総史 — Thu, 19 Sep 2013 22:00:56 +0000

連載：パフォーマンスチューニング (6)

「Webサイト・アプリ高速化テクニック徹底解説」第8回は、モバイルブラウザに向けた最適化について紹介します。モバイル端末はPCに比べ、CPUやネットワークなどの性能面で劣ることからボトルネックの影響が出やすく、またゲーム開発など突き詰めたチューニングを行う場面では、特殊なノウハウも必要になります。

しかしきちんと最適化を行えば、その効果もその分著しく、比較的低スペックな端末や3G回線であっても、サクサク軽量なサービス提供が可能です。今回の記事では、その勘所をお伝えしたいと思います。

1. ボトルネックを取り除く

まずはやってしまいがちなボトルネックの事例について、挙げていきたいと思います。前述のようにモバイル端末では、その性能からPCよりも顕著に、未最適化箇所が体感に影響を及ぼします。

仕事がらそこそこの数のアプリケーションを見てきましたが、モバイル向けに特化したチューニングができていないのではなく、一般に求められる最適化がなされておらず、それがボトルネックとなって遅いといった事例をよく目にします。

以下では、特にモバイルで問題となる一般的な最適化項目を挙げてみました。個々の詳細な解説については、本連載シリーズの中でより詳細にレポートしていきます。ぜひ、目を通してみてください。

よくありがちな例としては、

JavaScriptファイルの取り扱いが最適化されておらず、不要なブロッキングが発生している
適切なレスポンスヘッダが設定されておらず、ブラウザキャッシュが機能していない（もしくはConditional GETのリクエストを飛ばしている）
過剰な数のHTTPリクエストが発生している

といったものがあります。

JavaScriptファイルの取り扱いに注意する

まず影響が大きいのは、JavaScriptファイルの取り扱いです。
script要素はブラウザの他の処理をブロックします。HTML文中にscript要素があると、ブラウザはパース処理など他の仕事を停止し、script要素の評価を優先して実行します。
普段は様々な仕事が並列で走っているのですが、script要素だけは特別扱いで、これはブラウザにとって最も重い仕事のひとつとなります。もちろん、モバイル端末においても顕著に影響を与えます。

script要素の数を減らすか、非同期化しましょう。
defer、async属性を用いることで、上記のブロッキングがなくなります。
非同期化を行わない（行えない）場合はブロッキングの影響を最小限に抑えるよう配慮します。
具体的にはファイル結合を行い、script要素の数を減らし、またbody要素の最下部に置くなど、ブラウザの処理をできるだけ阻害しないようにします

ブラウザキャッシュを有効に機能させる

また、ブラウザキャッシュも重要です。
画像、CSSファイルなどの全アセットがキャッシュに入り、DOMContentLoadedまでにHTTPリクエストが全く発生しない状況では体感速度が大幅に向上します。サクッとファーストビューが表示されるなど、明らかに体感が変わります。「HTTPリクエストが全く発生しない」ことが重要です。Conditional GET（304）を見かけた場合もきっちり摘み取りましょう。

またサーバ側で画像合成を行うなど、動的なアセットを持つ場合にレスポンスヘッダの付け忘れが起こりやすいようです。こういった動的なアセットはファーストビューに含まれることも多く、キャッシュの可否で体感速度が変わってきます。反対に毎回動的に生成するようなものは、もしファーストビューなど重要な箇所に含まれないようなものは遅延ロードに回してやるのもよいでしょう。

例: cache validator（この場合はLast-Modified）が設定されているので正しくキャッシュされる。

例: cache validator に相当するヘッダがなく、キャッシュ不可として扱われる。

HTTPのリクエスト数を削減する

モバイル端末では、PCよりも顕著にHTTPのリクエスト数が性能面に現れます。

理想はファーストビューの表示までに20本未満程度だと思います。
30本以上のリクエスト数を見ると、多いなと感じます。これらにはリクエスト本数を削減するにはスプライトシートを使う、base64 encodeで文字列化して埋め込む、遅延ロードを行う等々、その時々に応じた方法があります。

上記に挙げたボトルネックはどれもGoogle Page Speed等のツールを用いたチェックが可能です。
特殊なノウハウではなく、検出もしやすく改善もしやすいので、ぜひ活用＆対応してみましょう。

2. チューニングの為の知識と準備

大まかな流れを掴む

JavaScriptヘビーなアプリケーションなど通常の最適化だけでは十分に軽量化できないものがあります。
そのような場合は、より突っ込んだ測定と最適化のチューニング作業が必要です。

モバイルでのチューニング作業は、ざっくり例えると買い物に近い感覚です。
まずコンテンツの表示にかけてよい時間、つまり予算を定め、DOMContentLoadedまでの所要時間やJavaScriptの処理時間といったパートごとのコスト計測を行い、予算内にそれらが収まるよう、値切ったり（高速化）、予算外に回したり（遅延評価）といったやりくりを行う、といったノリです。

まず予算を決めます。
予算を決めるには、そのコンテンツやアプリケーションがユーザの目から見て使えるようになったと思えるポイント、待ち時間が終わったと感覚的に思えるポイントを定めます。
これはコンテンツによって様々です。ファーストビューが表示されるまでの場合もあれば、メインアプリケーション部分をユーザが操作可能になるまでの場合、アニメーションが再生を開始するまでの場合など、そのアプリケーションの特性によって決まります。
ここまでに要する時間をもって、予算として定めます。

経験則的には、アセットがブラウザキャッシュに収まった状態で、この感覚的待ち時間が大体800ms以下に収まるとサクサクである、読み込みが軽量であると利用者にも感じてもらえることが多いようです。
大体の予算感の参考にしてください。

さて、次に計測を行うのですが、計測にあたってはターゲット環境の選定が重要になります。
これは端末、OS、ブラウザによって実効性能や動作特徴が変わるので、結果として高速化のために解決するべき問題が環境にひも付いて変わるためです。
ここでは端末、OS、ブラウザ、回線種別の組み合わせを指して「環境」と呼んでいます。特に端末とブラウザの違いについて、下記で見ていきましょう。

ターゲット端末を定める

モバイルで発生する大半の問題は実はCPUやGPU、もしくはネットワーク性能の向上で簡単に解決できてしまいます。

端末性能は日々向上を見せており、今日の課題は明日の課題となり得ないことがあります。
端末の買い換えサイクルは2年程度とよく言われますが、実際にベンチマークを取ると2年前の端末と現在の端末では5～8倍近い性能差が発生します（さらに極端な例もあります）。
本当に解決すべき問題を見定めるためには、その時の状況に即したターゲット端末の選定が重要になります。

本原稿の執筆時点は、低スペック端末が世間から消えるか消えないかのちょうど過渡期です。
シェアを広げつつある性能の良い端末に向けて体験も豊かに補強しつつ、多少年数の経った低スペック端末でも円滑にサービスが動作するような、両方取りのチューニングが求められている時期だと思います。

今回は低スペック端末向けのチューニングも視野に入れましょう。
低スペック端末の代表格としては、例えばiPhone 4があります。iPhone 4はディスプレイサイズに比べてCPU/GPUの性能が十分と言えない、問題を見つけやすいチューニング向きの端末です。
iPhone 4は発売から年数も経過していますが、iOS7がカバーしていることもあり、まだサポートが必要だと思います。
また比較的新しい端末であっても、例えばGalaxy S3など一昨年に発売されたものでも、CPU/GPUの負荷軽減処理が効果的にはたらく低スペック端末に近い挙動のものがあります。
やはりまだ、高速化には端末性能を考慮した作り込みが必要となる、低スペック端末への配慮が必要な時期だと言えるでしょう。

ブラウザ間の差異について

モバイルブラウザは様々な種類が存在しますが、ここではシェアの高いMobile SafariとAndroid Browser、Chrome for Androidといったブラウザに絞って話を進めます。

Mobile SafariとAndroid BrowserはOSのバージョンによっても挙動に違いがあるため、選定時には気をつけてください。

まずブラウザキャッシュの取り扱いは各ブラウザで異なり、体感や最適化に影響を与えます。

Mobile Safariはオンメモリのキャッシュしか持たず、このためOSの都合で頻繁なキャッシュアウトが発生しやすく、また本体やブラウザの再起動など、プロセスの寿命に伴ってキャッシュが破棄されます。

キャッシュ領域のサイズ自体は100MB前後だと言われていますが、状況によってブレがあり、確定した値を持っていません。
ひとつのサイトを訪れ継続して操作を行う場合はキャッシュ効果を期待できますが、サイトを再訪した時など、時間を置いて訪れた際は、以前のキャッシュはもうないものと思った方がよいでしょう。

Android 2.2や2.3といった2系のAndroid Browserでは、キャッシュ領域が8MBとそもそも小さく、キャッシュ効果自体があまり期待できません。
吉報としてはAndroid2系のシェアが下がりつつあることでしょうか。

Android 4系のAndroid BrowserやChrome for Androidになると、85MBのファイルキャッシュ（Persistent Cache）を持つため、比較的良好な効果が期待できます。
max-ageやETagといったキャッシュ寿命の設定も、この辺りから効果を持ち始めます。

このようにモバイル端末では、キャッシュの取り扱いに諸々問題があります。
より詳しい説明が Guy’s Podのエントリに掲載されているため、興味のある方は目を通されるとよいでしょう。

ほかにもHTTPの同時接続数やJavaScriptの実行パフォーマンスなど細かな点が変わります。
例えばiOS5とiOS6では、局所的なJavaScriptの実行パフォーマンスの違いからアニメーション描画に差異があり、体感的な差異をもたらすといったことが実際にありました。
また、iOS7がリリースされたため、既にiOS5の性能劣化はあまり重要な問題とは言えなくなりました。
このように細かなチューニングや性能測定を行う際はOSバージョン、ブラウザによる性能変化に注意し、その時に適切なものを選ぶよう注意が必要です。

計測に際して

計測を行う場合はざっくり、以下の三つのパートから計測を開始することが多いでしょうか。
尚、計測を行う際はMobile SafariのWeb Inspectorなど、結果に影響を与えるデバッガ類を走らせないよう注意が必要です。

DOMContentLoadedまでの所要時間を計る
JavaScriptのメインルーチンが呼び出されるまでの所要時間を計る
感覚的待ち時間に該当する関数の実行完了までの所要時間を計る

それぞれの計測区結果を基に、さらに絞り込み問題の検出と改善を進めます。
上記それぞれの所要時間に応じた具体的なチューニング方法を次に解説します。

3. DOMContentLoadedまでを高速化する

意外と重くなりがちなのが、DOMContentLoadedまでの所要時間です。
経験則ですが、divやul、liなどHTMLタグの入れ子を深めると、その部分の処理が重くなる傾向があります。
疑わしい部分はコメントアウトして計測してみる、といった方法で特定を行います。
特に低スペック端末が影響を受けやすく、複雑なHTMLで組まれたメニュー部分を排除すると80ms近くDOMContentLoadedが改善した例もあります。

対応としてはHTMLの記述を見直すか、対象箇所を遅延評価にくくり出すのがよいでしょう。遅延評価の方法はいくつかあり、XHRで取得する、または

このコードでは、head要素にscript要素で3つのJavaScriptファイルを読み込んでいます。この場合、すべてのJavaScriptの実行が終わるまで画面の描画が行われず、これらのJavaScriptの実行に時間が掛ると、その分だけ何もコンテンツが表示されない時間が長くなります。このコードを実行した結果をChromeのデベロッパーツールで解析してみると次のようになります。

Chromeのデベロッパーツールで解析したタイムライン（Timelineパネルで記録）

図を見るとわかる通り、1.js～3.jsの読込みと実行が順番に行われ、それが終わるまでの間は、body要素以下の表示が行われません。これは、JavaScript内でdocument.write()メソッドによってHTMLの内容が書き換わる可能性があるため、JavaScriptの実行が終わるまでページの表示がブロックされるためです。では、どのようにして素早くページを表示させるのかというと、次のような位置にscript要素を記述します。

:html:

よく利用されるテクニックですが、このようにbody要素の最後にscript要素を記述すると、先に表示できるコンテンツを表示し、コンテンツの表示が終わったあとにJavaScriptを実行するようになります。このようにして、ページがすぐに閲覧できるようになり、ユーザーの体感速度を向上することができます。ただし、これらのJavaScriptでユーザーのクリック動作などを設定している場合は、コンテンツが表示されているのにクリックしても反応がない時間などができてしまうので、状況に合わせて使い分けていきましょう。

その他の方法として、script要素にdefer属性とHTML5で追加されたasync属性というものを利用する方法もあります（defer属性は、HTML4で標準化されています）。まずは、先ほどのコードとまったく同じ効果を持つdefer属性について解説します。defer属性は次のように記述します。

:html:

script要素にdefer属性をつけると、コンテンツの表示が終わったあとに、そのJavaScriptを実行するようになります（正確にはDOMContentLoadedイベントの前になります）。そのため、body要素の最後にscript要素を記述したコードとほぼ同じ結果になりますが、ファイルの読込みは非同期で行われるため、こちらのほうが若干早くなる可能性があります。このdefer属性は、すべてのモダンブラウザ（Chrome、Safari、Opera、Firefox、IEなど）で利用することができます。元々は、IEの独自実装であったため、IEはバージョン4の時代から利用できます。

また、もうひとつのasync属性では、JavaScriptの実行でページの表示をブロックせずに、JavaScriptを非同期で実行することができるようになります。script要素にasync属性をつけると、そのままscript要素以降のコンテンツが表示されていきますが、JavaScriptファイルのダウンロードが終わり次第、そのJavaScriptが実行されます。注意として、async属性をつけたscript要素は、実行順序が保障されていないため、他のJavaScriptと依存関係がないものに限って利用する必要があります。また、実行タイミングも保障されないため、まだ読み込まれていない要素に対するDOM操作をしてしまう可能性もありますので注意しましょう（その場合、onloadイベントなどを利用しましょう）。もし、サンプルで利用している1.js～3.jsがお互いに依存していない場合は、次のように記述することができます。

:html:

1.js～3.jsはasync属性によって、同時にダウンロードが始まり（ブラウザの同時接続数などにもよります）、完了次第実行されます。そのため、高速に動作するのですが、実行される順番がバラバラになる可能性があります。依存関係があるJavaScript要素には、script要素をそのままで利用するか、defer属性を使いましょう。例えば、2.jsと3.jsに依存関係がある場合には、1.jsにのみasync属性を追加するようにします。async属性は、すべてのモダンブラウザ利用することができますが、IEは9以降の対応となります。といっても、async属性が無視されたとしてもJavaScriptはそのまま実行されるので、非対応のブラウザについてそれほど気にする必要はないでしょう。

async属性とdefer属性を付けたscript要素では、document.write()メソッドが利用できないことと、インライン（script要素に中に直接記述する）でJavaScriptを記述することができませんので注意しましょう。これらの、script要素の位置やasync属性、defer属性などを利用して、なるべくすばやくページが表示されるように気をつけてみましょう。

ユーザーに素早くインタラクションを返す

ユーザーの体感速度を向上させるには、ユーザーの行動に対して、素早く何らかのインタラクションを返すことが重要です。例えば、Gmailのメールスレッドにスターを付けるインターフェースを見てみましょう。

Gmailのスター

Gmailでは、メールスレッドにあるブランクのスターをクリックした瞬間にスターが黄色くなるようになっています。実際にスターを付ける処理は、バックグラウンドで非同期に実行されます。このように、他の操作に影響が少ない部分であれば、素早くレスポンスを表示することでアプリがサクサク動いているように見せることができます（もちろん、エラーがあった場合には、適切な通知を行うことが必要です）。

この例では、ユーザーの行動に対して先に結果を表示するというものでしたが、処理に時間がかかるものであれば、プログレスバーやローディングアイコンを表示することも、当然ユーザーに素早くインタラクションを返す一例になります。これは、ユーザーに何もレスポンスがないという状態をなるべく減らすということです。基本的な設計に関わる部分なのでユースケースに合わせて考えてみましょう。

次回の内容について

今回は、ユーザーの体感速度を向上させるための手法として「ページを素早く表示する」と「ユーザーに素早くインタラクションを返す」の2つを解説しました。次回は、残りのひとつ「ユーザーの操作を阻害しない」について、JavaScriptのシングルスレッドやイベントループを絡めつつ、HTML5のWeb Workersなどについても解説していきます。

[注]　defer属性は、HTML5ではなくHTML4で標準化されているというご指摘を受け、2013/7/22に修正しました。

「Webサイト・アプリ高速化テクニック徹底解説（第1回 Webサイト・アプリの高速化ファーストステップ）」を読む