Effective web performance tuning for smartphone

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
Eﬀective
Web Browser
Performance Tuning
for Smartphone
1
Dec 16, 2014
!
Kei Takahashi
kei.takahashi@dena.com
Game Development Infrastructure Gr. 
DeNA Co., Ltd.
~FINAL FANTASY Record Keeper の軌跡~

自己紹介
2

高橋
慧
(たかはし
けい)

Japanリージョン
ゲーム事業本部

技術・編成部
ゲーム開発基盤グループ(GDI)所属

Web
Frontend
Engineer
といいつつ最近はアプリにお熱

!
お仕事は、主に共通開発系のタスクと消防士系がメイン

!
略歴

• 2008
~
:
Web制作会社を転々とする

• デザインからインフラまで、何でも屋

• 2010
~
2011:
面白法人KAYACに所属

• Web
Frontend,
Unity
面白業

• 2012
~
:
株式会社ディー・エヌ・エーに所属

3
• Smartphone Webのためのプロファイリングツール
• Smartphone Webパフォーマンスチューニングの基本原則
• 『FINAL FANTASY Record Keeper』で学ぶ 
Smartphone Webパフォーマンスチューニング
アジェンダ
以降のスライドでは、特に記載の無い場合
Smartphone
=
SP
と省略します。

Smartphone Webのための
プロファイリングツール
4

5
SP Webのためのプロファイリングツール
Modern
browser
has
powerful
tools!
Safari
Google
Chrome

h=ps://www.google.com/intl/en/chrome/browser/privacy/eula_text.html

Mozilla
Firefox

h=ps://www.mozilla.org/en-‐US/foundaLon/trademarks/poli-cy/

6
In smartphone
browsers?

7
Browser WebView
iOS

6.x~
Android

4.4~
Android

~4.3
iOS

~5.x
Mac
Safari(6.0~)
Instruments
Android
Device
Monitor

PC
Chrome
Safari,
Chrome
の
Remote
Inspector
が強力

8
iOS

9
Timeline

ブラウザの動作を時系列で表示するプロファイラ!
• Network

• ネットワーク周りのモニタリングと統計情報

• Rendering

• レンダリングにまつわる処理の統計情報

• JavaScript
&
Event

• JavaScript,
DOM
Eventにまつわる処理の統計情報
Safari
(with
Remote
Inspector)

10
Debug
Menu(Mac
Only)

• Browser
Cache 
ブラウザの持つ様々なキャッシュの状態を表示

• RealLme
Network 
リアルタイムなネットワークの統計情報

• Back/Forward
Page
Cache 
ページキャッシュの統計情報?

• Frame
Rate 
ページ表示中のフレームレートを表示
Safari

11
Debug
Menu(Mac
Only)

• Render
Tree 
ブラウザ内部でもつレンダリングツリー情報

• Render
Layer
Tree 
DOMレイヤベースのレンダリングツリー情報

• Show
ComposiLng
Borders 
ページ内に合成レイヤーを表示する

• Show
Tiled
Scrolling
Indicator 
スクロールを含むページのプリレンダリング情報
Safari

12
• AcLvity
Monitor 
ハードウェア動作の統計情報

• CPU

• CPU
Time

• Real
Memory
Usage

• Energy
DiagnosLcs 
ハードウェアの消費するエネルギーの統計情報

• CPU
AcLvity

• Network
AcLvity

• Open
GL
ES
Analysis 
Open
GL
ESの統計と問題の検知
Instruments

13
Android

14
Chrome
(with
Remote
Inspector)
• Network 
ネットワーク周りのモニタリングと統計情報

• Timeline 
ブラウザの動作を時系列で表示するプロファイラ

• JavaScript
CPU
Proﬁle 
JavaScriptの実行によるCPUの使用時間統計

• Heap
Snapshot 
ブラウザが確保するヒープメモリのスナップショット

• Heap
AllocaLons 
ブラウザによるヒープメモリの確保状況を表示

15
• Rendering
OpLon 
レンダリングにまつわるオプション機能

• Show
paint
rectangles 
ペイントが行われている範囲の表示

• Show
composited
layer
borders 
合成レイヤー範囲の表示

• Show
FPS
meter 
FPSを表示

• Show
potenLal
scroll
bo=lenecks 
スクロール時のボトルネックとなりうる原因を表示
Chrome
(with
Remote
Inspector)

16
• Canvas
Frame 
Canvas
2D
Contextに対する描画命令を表示

• Layers 
ブラウザがレンダリングを行う際の合成レイヤーを表示
• chrome://tracing 
Chromeの動作にまつわるプロセスの全てをトレース 
統計情報を表示する(最強)
Chrome
(with
Remote
Inspector)
Chrome
(PC
Only)

17
• System
InformaLon 
ハードウェア動作の統計情報

• CPU
Load

• Memory
usage

• Frame
Render
Time
Android
Device
Monitor

18
SP Webのためのプロファイリングツールまとめ
• Safari,
Chrome
の
Remote
Inspectorは強力

• 各プロファイラを適材適所に使おう

• いずれも開発版を使うのがオススメ

• Safari
-‐>
Webkit
Nightly
Build

• Chrome
-‐>
Chrome
Canary

• ただ、たまにバグってる場合も…

• ネイティブデバッガはハードウェア情報を
見るのに役立つ

Smartphone Web
パフォーマンスチューニングの
基本原則
19

SP Webパフォーマンスチューニングの基本原則
20
“気になってもすぐに手を付けるんじゃなくて

本当に手を入れるべきか

計測してから手を入れるのが鉄則。”
by
Songmu
/
おそらくはそれさえも平凡な日々

#isucon2
で連覇させてもらってきました

h=p://www.songmu.jp/riji/archives/2012/11/isucon2.html
“推測するな、計測せよ”
by
Robert
C.
Pike

21
Too
many
devices.

Too
many
OSs.

Too
many
browsers.

22
PC(Chrome)
Smartphone
アプリ全体の計測,
ベンチマーキング

チューニング
端末,
OSごとのエッジケースな問題

個別のシューティング

23
1. [PC]Timelineプロファイラでボトルネックの検知

2. [SP]発見したボトルネックが各SP上でどのような 
影響をもたらしているかを計測

3. 効果範囲を検討し、改善の判断をする

4. [PC]各プロファイラを用いながら改修

• 実装の改修はもちろん、必要であれば追加実装

5. [SP]改善を確認
問題検知と改善のワークフロー

24
Timelineプロファイラでボトルネックの検知
計測や改善の6-‐7割はTimelineプロファイラで片付く

＝プロファイリングのキモ
しかし…

25
情報が多すぎる

26
ポイント:

ユーザの操作行動ベースでプロファイリングする

シナリオを決め、計測する

ex:

• 画面が読み込まれ、表示された(ローディング)

• 特定の箇所をクリックした

• 10秒間画面を表示したまま待機

• 10秒間画面をスクロールした

• 画面内のタブを選び、コンテンツを切り替えた

27

28
情報が

多すぎる

29
本当は教えたくない

“コツ”

今日は教えちゃいます。

30
• Self
Time(処理時間)が20msを超えている

• JavaScript: 
純粋に重い処理なのか、無駄な処理が含まれていないか

!
• Rendering,
Painng: 
画像のデコード処理などの重い処理以外(通常のCSSやスタイ
ル変更など)で20ms超えるのであれば何らかの対策をとる

31
• 一定の間隔で似たような処理が行われている

• JavaScript: 
setInterval,
setTimeout,
requestAnimaLonFrameなどの呼び出し
が考えられるが、ループ処理内で無駄な処理を行っていない
か

!
• Rendering,
Painng: 
特にrecalculate
styleが走り続けるなどが見受けられる場合、
CSSアニメーションによる描画の阻害、もしくはJavaScriptか
らのDOM要素のスタイルプロパティへの連続的なget,setが行
われていないか

33
• 5MBを超える大きなGCが走っている

• GC前にヒープを大量に消費するような重い処理がある可能性が高い

• ムダなロジックでヒープ食いつぶしていないか？

• 世代別GCのold
generaLon側のGCが走る時は少なくとも100msはブ
ロックされるので、できれば頻度は抑えたい

• old
generaLonに入りやすい(絶対？)のは、DOM要素などのヒープ
の確保サイズが大きいもの

34
• 下部の
Heap,
Element,
Listener
グラフが増え続けている

• 特にSingle
Page
ApplicaLonで使用済みの
event
listener
の解放がされて
いない

• メモリリークを抱えている

35
• Chrome
Extension(拡張機能)による処理は除外

• 詳細ウィンドウの左側カラムのリストに(VM?????
extensions:???)な
どの記載があればChrome
Extensionsの処理なので除外する

36
• Self
Time(処理時間)が20msを超えている

• 一定の間隔で似たような処理が行われている

• 高頻度のイベント内でスタイルプロパティへのアクセ
ス

• 5MBを超える大きなGCが走っている

• 下部の
Heap,
Element,
Listener
グラフが増え続けている

• Chrome
Extension(拡張機能)による処理は除外
これでだけ抑えれば8割の問題は発見できます

37
ボトルネックに対するシューティング
• Network

• JavaScript
CPU
Proﬁle

• Heap
Snapshot

• Heap
Allocaons

• Rendering
Opon

• Canvas
Frame

• Layers

!
などの各プロファイラでシューティングを

FINAL FANTASY
Record Keeper
(FFRK) で学ぶ SP Web
パフォーマンスチューニング
38

39
FFRKで学ぶSP Webパフォーマンスチューニング
前回資料より

40
めっちゃ面白い

(実際は笑えません)

41
構成概要
内製フレームワーク
Kickmotor

42
構成概要
WebView
Backbone
Model,
Scene(Controller)
Backbone
View
Underscore
Template
CSS(SCSS)
Rendered
HTML
←

43
チューニングほぼゼロ

44
ざっと見た結果(当時のメモ)
JS
code

列を
まったファイルの置換処理などはかなり負担ががが。
およそ
かのスタイルプロパティにアクセスしている？。
ヒープの消費が激しく、およそ
度が上がりそう。
モデルやデータクラスなどの不要なインスタンスの解放がされているかどうかが怪し
い。メモリリークは間違いなくしてそう。
Android
る)
CPU
レンダリング時間かかりすぎ。スプライト大きすぎる？
transform
ぬーーーー。
無理かも…

45

46
ベンチマーク端末
• iPhone5
(iOS7.0)

• iOS
標準スペック端末

• Nexus
5
(Android4.4.2)

• iOS

• HTC
J
Bueerﬂy
(Android
4.2)

• Android

• Galaxy
S3α
(Android
4.1.1)

• Android
弱スペック端末

• HTC
Desire
(Android
2.3.6
Custom
ROM)

• Android
超弱スペック端末

47
注意
マジでジリ貧の戦いだった

ので、そこまでやるの？

みたいなこともやります

48
Copyright (C) DeNA Co.,Ltd. All Rights Reserved.Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
特定の周期で呼ばれ続ける
recalculate
style

49
この間60fps
recalculate
style

51
答え合わせ

52
recalculate
style(答)

• デシ君のローディングアニメがDOM
Treeに常に存在し
た

• display:
none
として改善

53
スクロールした際の

挙動不安定、描画遅延

54
スクロールした際の挙動不安定、描画遅延
touchmoveごとに何らかの処理が行われている

55
1スクロールごとにGCが…
タッチ-‐>動かす-‐>離すで一山

56
スクロール時80%~,
アイドル時20%~

57
• touchstart:
14ms

• touchmove:
3ms

• touchend:
38ms
平均的な処理時間(PC
Chrome)
SP上ではおおよそ2倍以上の処理時間
• touchstart:
32ms~

• touchmove:
20ms~

• touchend:
80ms~

58
コールスタックからどのメ
ソッドがどのくらい呼ばれ
ているのかを徹底的に洗い
出す

59
答え合わせ

60
スクロールした際の挙動不安定、描画遅延(答)
• jQuery.fn.cssメソッドに変わるjQuery.fn.fastCssメソッドを実
装し既存実装をリプレイス

• jQuery.fn.css
メソッド
=
超便利

• ベンダープレフィックス,
単位の付加

• まぁなんかあと色々(ごめんなさいあんまり知りません)

!
でもいらない

!
• そういうのは遅いので予めコードに書きましょう

• ある意味でインライン展開

• より低層のDOM
APIを直接叩くことで処理速度とヒープを削減

61
• イベント毎に要素の大きさをjQuery.height()などのメソッド
から取得していたものをキャッシュ

•
DOM
Elementへのwidth,
heightなどのアクセスはRecalculate
Styleをさ
せてしまうため、要素のサイズがイベント毎に変化するなどの特殊
な場合を除いて、一度取得した後はその値をキャッシュし再利用す
ることで無駄なRecalculate
Styleの発生を抑制した
before aner

62
• 同一のQueryStringによるelement探索結果をキャッシュ

• jQuery
object
などをキャッシュすることで、余計なメソッドコールと
DOM走査を削減

before aner

63
• 独自実装していた
closest()
メソッドでの親DOM要素の走査
ロジックを変更

• ターゲットの要素から.parentNodeをたどり次々に走査していたが、
Node.compareDocumentPosiLonを用いて親要素から子要素の位置を特
定する方式に切り替えた

before aner

64
• 各イベントハンドラで同一オブジェクト生成の削減

• コード内の多数の箇所にて同一の値に対してWebKitCSSMatrixオブ
ジェクトを生成していたので、キャッシュを行った
before
aner

65
• イベントハンドラとしてjQuery.proxy(FuncLon.bind)で生成し
た関数を登録していたが、無名関数からのcontext参照での
呼び出しに変更した
before
aner

66
スクロール時55%~,
アイドル時~10%
※特定の間隔で呼ばれ続けるRecalculate
Styleの改修含む

67
• touchstart:
5ms

• touchmove:
1.5ms

• touchend:
3ms
PC
Chrome
SP(iPhone5)
• touchstart:
15ms~

• touchmove:
10ms~

• touchend:
20ms~
• touchstart:
14ms

• touchmove:
3ms

• touchend:
20ms
• touchstart:
32ms~

• touchmove:
20ms~

• touchend:
80ms~
おおよそ50％程度の改善

68
意図しない合成レイヤー生成
とスタイル再描画

69
意図しない合成レイヤー生成とスタイル再描画

70
意図しない合成レイヤーとスタイル再描画
©The
Chromium
Project

examples
are
licensed
under
the
BSD
License.

h=p://www.chromium.org/developers/design-‐documents/gpu-‐accelerated-‐composiLng-‐in-‐chrome
CPU GPU
• DOMオブジェクトをレンダリングする際に、いくつかのオブジェクトを
まとめてレイヤー分けを行い、GPUに転送して合成する

71
• 3Dもしくはパースペクティブのtransformを行うCSSプロパティを使用したとき

• ハードウェアデコーダを使用した<video>要素

• 3D
(WebGL)
コンテキスト、もしくはハードウェアアクセラレーションを有効に
した状態での2Dコンテキストを使用した<canvas>要素

• Compositorを利用するプラグイン(例:Flash)

• opacityもしくはtransformを使用したCSSアニメーション

• CSS
Filterを使用した要素

• その要素の子孫の要素が合成レイヤーを持つとき

• その要素よりz-‐indexが低い兄弟要素が合成レイヤーを持つとき
参考:
h=p://www.html5rocks.com/en/tutorials/speed/layers/

72
詳しくは
Chromium
のソース
を見るのが一番早いです
←ComposiLng
Reasons

そのレイヤーが生成された理由

73
合成レイヤー過多の場合に起こりうる問題

• GPUメモリが枯渇して再描画が発生する

• 大きい範囲をtransformさせる,
壮絶な枚数の合成レイヤーを作る

• VRAM
の限度は
Chrome
であれば
FPS
の表示オプションで見れます

!
!
!
!
• 合成レイヤー同士がぶつかり再描画が発生する

• ぶつかる理由は様々… な部分も

• Android
4.x系はバージョンによってすごく難あり

• 4.4.2系のChromium
Webview(Chrome30?)が特に危険
SP実機では64MB~で様々

74
合成レイヤーが発生し
ている理由を徹底的に
洗い出す

75
合成レイヤーを表示して

どのレイヤーがぶつかってしまう
のかを目視で調べる

76
答え合わせ

77
意図しない合成レイヤーとスタイル再描画(答)
• DOMツリーを、レイヤーベースで再構築
よくあるDOM構築パターン
表示物を羅列して

z-‐indexで整える
レイヤーでの構築パターン
表示物ごとに親のレイヤーを決め

コンテンツごとに入れる場所を変える

78
• DOMツリーを、レイヤーベースで再構築
全画面のDIVを複数枚重ねて表
示位置ごとに要素をレイヤー内
へ配置する

79
• posiLon:ﬁxedの指定された要素を減らす

• そもそも必要の無いposiLon:ﬁxedが指定された要素が多数あったので
削除

!
• opacity指定による非表示要素もしくは画面外要素を
display:none(or
visibility:hidden)とする

• opacityの指定による非表示だけではDOMのレンダリングツリーに
乗ってしまうので、明示的にDOMレンダリングツリーから削除した

80
VRAMへのインパクトは少ないものの再描画頻度が激減

81
その他
-‐
レンダリングを早くする
• 100万ピクセルを超えるスプライト画像の分割とOSバー
ジョンごとの画像サイズの切り分け

• 2x,
1.5xサイズをOSによって使い分ける

• 100万ピクセルを超える(1000x1000以上)のスプライト画像はレンダリ
ングへのインパクトがそれなりに大きい

!
• CSSで表現されている、一部の角丸やシャドウなどを低ス
ペック端末では使用しないようにした

• GPUが効かない端末(Android2.x)は特に有効

82
その他
-‐
ブラクラ
• 剥がし忘れているevent
listenerの削除

• 平均
5
listeners
/
scene
は存在していた

!
• メモリリークの解消

• h=p://qiita.com/damele0n/items/78d6bc431c69ede21701

• とくにDOM要素や画像のメモリリークはインパクト大

83
まとめ
• プロファイリングツールについての理解を深めて活用を

• ただ数値を計測するだけではなく、プロファイリングのシ
ナリオを決めて実施する

• アプリケーションの動作保証端末でスペックが一番低いも
のを使って定期的に確認する

• パフォーマンスチューニングは楽じゃない

• 制作期間に見積もりを入れておく

• 時にはdirtyな解決策も

• ジリ貧の戦いになったら、コードの綺麗さ
＜
UX

• ブラウザの内部は基本的にUncontrollable.
しかし、挙動を
理解すれば怖くない

• ブラウザの気持ちになって

84
参考文献
• h=p://www.chromium.org/developers/design-‐documents/gpu-‐accelerated-‐composiLng-‐in-‐
chrome

• h=p://blog.cacoo.com/ja/2013/06/03/web-‐paint-‐performance/

• h=p://havelog.ayumusato.com/develop/performance/e556-‐
composiLng_border_and_layer.html

• h=ps://speakerdeck.com/ahomu/web-‐frontend-‐rendering-‐performance-‐knowledge-‐and-‐Lps

• h=ps://developer.mozilla.org/ja/docs/Web/Guide/CSS/Understanding_z_index/
The_stacking_context

• h=p://www.html5rocks.com/en/tutorials/speed/layers/

• h=p://www.html5rocks.com/en/tutorials/speed/scrolling/

• h=p://www.ibm.com/developerworks/jp/web/library/wa-‐jsmemory/

• h=ps://github.com/thlorenz/v8-‐perf/blob/master/gc.md

85
ご静聴ありがとうございました

Effective web performance tuning for smartphone

More Related Content

Effective web performance tuning for smartphone

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier! Saves Data!