スマートフォン向けWebサイトの表示速度 高速化手法

CodeZine / 2012年11月9日 14時0分

defar属性を活用することでiPhoneの通信状況が大幅に向上

 リッチで高機能なWebページなのだけど重い、待たされる、動きがモサっとなる、そんな体感性能に不満を感じたような経験はありませんか。モバイルブラウザの表現力が向上するにつれ、同時に高度化、複雑化するWebページをいかに待ち時間なくユーザに提供するか、フロントエンドの最適化が必要となるケースが増えてきています。今回は私たちが手がけているスマートフォン向けソーシャルゲームの世界で培ったノウハウの一部から、スマートフォン向けWebページの最適化手法をいくつかご紹介したいと思います。

■対象読者

スマートフォンWebサービス開発者 特に、フロントエンド周りの開発に従事する方 ■スマートフォン向けWebサイト高速化のテクニック

 スマートフォンはOS/デバイスの進化が激しく、要求される最適化の内容も半年で別物になることがあります。そのため最適化に際しては、案件ごとの状況や目的、デバイス/OSのシェアに応じて、まずターゲット端末を選定し、問題の検出を行います。

 この記事では「iPhone 4+iOS 5」を想定して話を進めます。実際に「iPhone 4+iOS 5」はよく現場でも最も動作が重い組み合わせとしてターゲット端末に挙がります。これはiPhone 4がRetinaディスプレイを採用したことで960×460ピクセルの高解像度を備えながら、CPUなどのデバイス性能が潤沢とはいえず、ボトルネックが生まれやすいためです。iOS 4ではなくiOS 5をターゲット端末として扱うのは、利用者割合においてiOS 4が極めて少ないことが理由です。

 こうした諸々の事情を考慮して実機を選定します。

 またモバイルネットワークでの利用を前提とするため、本体性能はもちろん、ネットワーク面においても限られた資源を有効に配分し、下記に挙げるようなグラフィカルな表現の実現を目指すことになります。

農園ホッコリーナ


 画面例はDeNAが提供する農園ホッコリーナのiOS版画面です。ゲーム部分は20~30ファイル程度のJavaScriptで構成されており、一部はRetinaディスプレイに合わせた倍解像度をもたせています。

 このようなリッチな表現を、待ち時間少なくユーザの手元に届けるため、フロントエンドの最適化を行なっています。

●その1 TTIにフォーカスする

 表示速度の最適化を検討する際に「TTI」という概念を用いています。

 TTI(Time to Interact)とは、ページの読み込み開始から主要なコンテンツが表示され、ユーザーが操作できると感じるまでの「ユーザにとっての待ち時間」です。

 例えば下記のゲームの場合、赤枠で囲んだ部分、動物が並んで動き始めた瞬間にユーザにとっての「待ち」が終わります。それ以外の部分、お知らせ画面や訪問履歴などは未表示であっても感覚的に待ちには含まれません。従って戦略としては、必要な部分の高速化に重点を置き、他の部分の描画やダウンロードはむしろ後回しにして速度を稼ぐといった内容になります。

 このTTI、最初の待ち時間が0.8秒を超えるとユーザに待たされる感覚が生まれることが多いようです。

 TTIを構成するプロセスを考え、そのプロセスが例えば0.8秒以内に完結する、といった目標を定めて最適化に着手します。

TTIにフォーカス


●その2 計測する

 まず、あるHTMLブロックのDOM構築処理やJavaScriptの評価実行速度など、主要原因と思われるさまざまな箇所を計測し、何がボトルネック要因であるかを突き止めます。

 原因が明確に分かれば大体は何とかできるものです。フロントエンドの最適化では要因を突き止めるための計測が最も大事な工程と言えます。

 実際の原因特定や影響範囲の測定には、次のようなツールや手法を用いています。

●1. Goole PageSpeed

 Google PageSpeedのような解析ツールを用いると、ざっくりとした問題や対策を知ることができます。

 予備調査や、そもそも最適化以前の問題を抱えていないかなど、初めて着手する案件の場合はこういった解析ツールが役立ちます。

 また過剰なリダイレクションやレスポンスヘッダといった基本的かつ見逃しがちな問題点も指摘してくれるため、大変便利です。

●2. JavaScript:実際の処理時間を計測する

 実機性能に基づくボトルネックを計測する場合は大変ベタですが、JavaScriptによる計測がやはり有効です。処理の前後にDate.now()を挟んで所要時間を計測します。

 他に、全体の所要時間を計測しておき、例えばあるHTMLブロックをコメントアウトするなど、特定の処理を取り去ることでその部分の所用コストを見極めるような方法も有効です。

●3. 実機計測

 実機のCPUやメモリ消費量も重要な情報であり、必要に応じて計測しています。

 またPCをアクセスポイントとすることで、Wi-Fiでの測定となりますが、通信データをダンプしてHTTP Archive Viewerのようなツールを通すことで通信状況の可視化が可能です。

 処理の並列性や大まかなネットワーク周りのボトルネック有無を見ることができます。

●その3 最適化する

 問題の検出と解決を繰り返し、最適化を図ります。

 実際に問題検出や最適化を行うためには、Webページやブラウザの動作に関する一定量の知識が必要となります。

 書籍であればSteve Souders著の『High Performance WebSites』、続編の『Even Faster WebSites』(Oreilly&Associates)、Web上のリソースならHTML5Rocksの良記事「How Browser Works」、やGoogle PageSpeedの提供ページから辿れる「Make the Web Faster」のコンテンツなどがお薦めです。



■関連記事
Adobe Edge Animateを触ってみよう!
【ADC MEETUP 06】インタラクティブなリッチコンテンツの制作を支援するライブラリ「CreateJS」
【ADC MEETUP 06】Webとアドビの切っても切れない関係
スマートフォン向けWebサイトの表示速度 高速化手法
「ユーザー志向」のスマートフォン向けUI/UXの作り方

■記事全文へ

CodeZine

トピックスRSS

ランキング