effective web performance tuning for smartphone

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.

Effective Web Browser Performance Tuning for Smartphone

1

Dec 16, 2014 !Kei Takahashi [email protected] 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 ~ : 株式会社ディー・エヌ・エーに所属

3Copyright (C) DeNA Co.,Ltd. All Rights Reserved.

• Smartphone Webのためのプロファイリングツール • Smartphone Webパフォーマンスチューニングの基本原則 • 『FINAL FANTASY Record Keeper』で学ぶSmartphone Webパフォーマンスチューニング

アジェンダ

以降のスライドでは、特に記載の無い場合 Smartphone = SP と省略します。

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



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/policy/

https://www.google.com/intl/en/chrome/browser/privacy/eula_text.html

https://www.mozilla.org/en-US/foundation/trademarks/policy/



In smartphone browsers?


7


Browser WebViewiOS 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


iOSCopyright (C) DeNA Co.,Ltd. All Rights Reserved.



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

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

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

• JavaScript, DOM Eventにまつわる処理の統計情報

Safari (with Remote Inspector)



Debug Menu(Mac Only) • Browser Cacheブラウザの持つ様々なキャッシュの状態を表示

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

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

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

Safari



Debug Menu(Mac Only) • Render Treeブラウザ内部でもつレンダリングツリー情報

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

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

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

Safari



• AcLvity Monitorハードウェア動作の統計情報 • CPU • CPU Time • Real Memory Usage

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

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

Instruments

13


AndroidCopyright (C) DeNA Co.,Ltd. All Rights Reserved.



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

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

• JavaScript CPU ProfileJavaScriptの実行によるCPUの使用時間統計

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

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



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

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

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

• Show FPS meterFPSを表示

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

Chrome (with Remote Inspector)



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

• Layers ブラウザがレンダリングを行う際の合成レイヤーを表示

• chrome://tracingChromeの動作にまつわるプロセスの全てをトレース

統計情報を表示する(最強)

Chrome (with Remote Inspector)

Chrome (PC Only)



• System InformaLon ハードウェア動作の統計情報 • CPU Load • Memory usage • Frame Render Time

Android Device Monitor


SP Webのためのプロファイリングツールまとめ

• Safari, Chrome の Remote Inspectorは強力

• 各プロファイラを適材適所に使おう • いずれも開発版を使うのがオススメ

• Safari -‐> Webkit Nightly Build • Chrome -‐> Chrome Canary • ただ、たまにバグってる場合も…

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

Smartphone Web パフォーマンスチューニングの

基本原則


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

20


“気になってもすぐに手を付けるんじゃなくて

本当に手を入れるべきか

計測してから手を入れるのが鉄則。”by Songmu / おそらくはそれさえも平凡な日々 #isucon2 で連覇させてもらってきました h=p://www.songmu.jp/riji/archives/2012/11/isucon2.html

“推測するな、計測せよ”by Robert C. Pike

http://www.songmu.jp/riji/archives/2012/11/isucon2.html


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]改善を確認

問題検知と改善のワークフローSP Webパフォーマンスチューニングの基本原則


24

Timelineプロファイラでボトルネックの検知SP Webパフォーマンスチューニングの基本原則

計測や改善の6-‐7割はTimelineプロファイラで片付く

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

しかし…


25


情報が多すぎる

Timelineプロファイラでボトルネックの検知


26


ポイント:

ユーザの操作行動ベースでプロファイリングするシナリオを決め、計測する

ex: • 画面が読み込まれ、表示された(ローディング) • 特定の箇所をクリックした • 10秒間画面を表示したまま待機

• 10秒間画面をスクロールした • 画面内のタブを選び、コンテンツを切り替えた



27




28



情報が多すぎる


29



本当は教えたくない

“コツ” 今日は教えちゃいます。


30


Timelineプロファイラでボトルネックの検知• Self Time(処理時間)が20msを超えている

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

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


31


Timelineプロファイラでボトルネックの検知• 一定の間隔で似たような処理が行われている

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

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


33


Timelineプロファイラでボトルネックの検知• 5MBを超える大きなGCが走っている

• GC前にヒープを大量に消費するような重い処理がある可能性が高い • ムダなロジックでヒープ食いつぶしていないか？

• 世代別GCのold generaLon側のGCが走る時は少なくとも100msはブロックされるので、できれば頻度は抑えたい • old generaLonに入りやすい(絶対？)のは、DOM要素などのヒープの確保サイズが大きいもの


34


Timelineプロファイラでボトルネックの検知• 下部の Heap, Element, Listener グラフが増え続けている

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

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


35


Timelineプロファイラでボトルネックの検知• Chrome Extension(拡張機能)による処理は除外

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


36



• Self Time(処理時間)が20msを超えている • 一定の間隔で似たような処理が行われている • 高頻度のイベント内でスタイルプロパティへのアクセス

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

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

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

これでだけ抑えれば8割の問題は発見できますCopyright (C) DeNA Co.,Ltd. All Rights Reserved.

37


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

• Network • JavaScript CPU Profile • Heap Snapshot • Heap Alloca\ons • Rendering Op\on • Canvas Frame • Layers

!

などの各プロファイラでシューティングをCopyright (C) DeNA Co.,Ltd. All Rights Reserved.

FINAL FANTASY Record Keeper

(FFRK) で学ぶ SP Web パフォーマンスチューニング



FFRKで学ぶSP Webパフォーマンスチューニング

前回資料より

http://www.slideshare.net/dena_study/20141111-seminar-eisuke



めっちゃ面白い (実際は笑えません)



構成概要

内製フレームワーク Kickmotor



構成概要

WebView

Backbone Model, Scene(Controller)

Backbone View

Underscore TemplateCSS(SCSS)

⇔

Rendered HTML

←



チューニングほぼゼロ



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

JS code

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

る) CPU

レンダリング時間かかりすぎ。スプライト大きすぎる？transform

ぬーーーー。

無理かも…



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

• iOS 標準スペック端末

• Nexus 5 (Android4.4.2) • iOS 標準スペック端末

• HTC J Bueerfly (Android 4.2) • Android 標準スペック端末

• Galaxy S3α (Android 4.1.1) • Android 弱スペック端末

• HTC Desire (Android 2.3.6 Custom ROM) • Android 超弱スペック端末



注意

マジでジリ貧の戦いだったので、そこまでやるの？みたいなこともやります

48Copyright (C) DeNA Co.,Ltd. All Rights Reserved.Copyright (C) DeNA Co.,Ltd. All Rights Reserved.


特定の周期で呼ばれ続けるrecalculate style



この間60fps

特定の周期で呼ばれ続ける recalculate style



答え合わせ



特定の周期で呼ばれ続ける recalculate style(答)

• デシ君のローディングアニメがDOM Treeに常に存在した • display: none として改善



スクロールした際の挙動不安定、描画遅延




touchmoveごとに何らかの処理が行われている




1スクロールごとにGCが…

タッチ-‐>動かす-‐>離すで一山




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




• touchstart: 14ms • touchmove: 3ms • touchend: 38ms

平均的な処理時間(PC Chrome)

SP上ではおおよそ2倍以上の処理時間• touchstart: 32ms~ • touchmove: 20ms~ • touchend: 80ms~



スクロールした際の挙動不安定、描画遅延コールスタックからどのメソッドがどのくらい呼ばれているのかを徹底的に洗い出す



答え合わせ



スクロールした際の挙動不安定、描画遅延(答)

• jQuery.fn.cssメソッドに変わるjQuery.fn.fastCssメソッドを実装し既存実装をリプレイス • jQuery.fn.css メソッド = 超便利

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

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

!でもいらない

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

• ある意味でインライン展開 • より低層のDOM APIを直接叩くことで処理速度とヒープを削減




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

before aner




• 同一のQueryStringによるelement探索結果をキャッシュ • jQuery object などをキャッシュすることで、余計なメソッドコールと

DOM走査を削減

before aner




• 独自実装していた closest() メソッドでの親DOM要素の走査ロジックを変更 • ターゲットの要素から.parentNodeをたどり次々に走査していたが、

Node.compareDocumentPosiLonを用いて親要素から子要素の位置を特定する方式に切り替えた

before aner




• 各イベントハンドラで同一オブジェクト生成の削減 • コード内の多数の箇所にて同一の値に対してWebKitCSSMatrixオブジェクトを生成していたので、キャッシュを行った

before

aner




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

before

aner



スクロール時55%~, アイドル時~10%


※特定の間隔で呼ばれ続けるRecalculate Styleの改修含む



• 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％程度の改善



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



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

©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に転送して合成する

http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome




• 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/

http://www.html5rocks.com/en/tutorials/speed/layers/




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

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

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/graphics/CompositingReasons.cpp



意図しない合成レイヤーとスタイル再描画合成レイヤー過多の場合に起こりうる問題

• GPUメモリが枯渇して再描画が発生する • 大きい範囲をtransformさせる, 壮絶な枚数の合成レイヤーを作る

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

!!!

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

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

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

• 4.4.2系のChromium Webview(Chrome30?)が特に危険

SP実機では64MB~で様々



意図しない合成レイヤーとスタイル再描画合成レイヤーが発生している理由を徹底的に洗い出す




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



答え合わせ



意図しない合成レイヤーとスタイル再描画(答)

• DOMツリーを、レイヤーベースで再構築よくあるDOM構築パターン表示物を羅列して z-‐indexで整える

レイヤーでの構築パターン表示物ごとに親のレイヤーを決めコンテンツごとに入れる場所を変える




• DOMツリーを、レイヤーベースで再構築

全画面のDIVを複数枚重ねて表示位置ごとに要素をレイヤー内へ配置する




• posiLon:fixedの指定された要素を減らす • そもそも必要の無いposiLon:fixedが指定された要素が多数あったので削除

!• opacity指定による非表示要素もしくは画面外要素をdisplay:none(or visibility:hidden)とする • opacityの指定による非表示だけではDOMのレンダリングツリーに乗ってしまうので、明示的にDOMレンダリングツリーから削除した




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



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

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

!• CSSで表現されている、一部の角丸やシャドウなどを低スペック端末では使用しないようにした • GPUが効かない端末(Android2.x)は特に有効



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

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

!• メモリリークの解消

• h=p://qiita.com/damele0n/items/78d6bc431c69ede21701 • とくにDOM要素や画像のメモリリークはインパクト大

http://qiita.com/damele0n/items/78d6bc431c69ede21701


まとめ

• プロファイリングツールについての理解を深めて活用を • ただ数値を計測するだけではなく、プロファイリングのシナリオを決めて実施する

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

• パフォーマンスチューニングは楽じゃない • 制作期間に見積もりを入れておく

• 時にはdirtyな解決策も

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

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


参考文献

• 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

http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome

http://blog.cacoo.com/ja/2013/06/03/web-paint-performance/

http://havelog.ayumusato.com/develop/performance/e556-compositing_border_and_layer.html

https://speakerdeck.com/ahomu/web-frontend-rendering-performance-knowledge-and-tips

https://developer.mozilla.org/ja/docs/Web/Guide/CSS/Understanding_z_index/The_stacking_context

http://www.html5rocks.com/en/tutorials/speed/layers/

http://www.html5rocks.com/en/tutorials/speed/scrolling/

http://www.ibm.com/developerworks/jp/web/library/wa-jsmemory/

https://github.com/thlorenz/v8-perf/blob/master/gc.md


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

effective web performance tuning for smartphone

Engineering