モバイルウェブパフォーマンスに関する５つの作り話
こんにちは、ゼノフィnakamuraです。
最近、全然正しくないモバイルHTMLパフォーマンスについての作り話をよく聞きます。良くできた都市伝説のように、もっともらしくて興味深いです。しかし、この作り話は、不正解な事や、ネイティブとウェブソフトウェアスタック関係の誤解、不正確なデータポイントを基にしています。我々がパフォーマンスについて、この何年間にも渡って集めたデータ、モバイルウェブアプリケーションパフォーマンスの最適化に対して、我々の経験を利用して、この作り話を暴くことをするのは重要だと思いました。
TL;DR(長ぇよ)
作り話 #1: モバイルウェブパフォーマンスは、ほとんどCPU上のJavaScriptパフォーマンスでドリブンされる。
実は：ほとんどのウェブパフォーマンスはレンダリングのパイプラインの最適化、DOM操作の速さ、GPUアクセラレーションのレベルで制約されています。より速いJavaScriptは役に立ちますが、最も重要ではありません。
作り話 #2: CPUにバインドしたJavaScriptはハードウェアの改善（ムーアの法則）だけのお陰で速くなった。
実は: モバイルJavaScriptの利得の50%はハードウェア改善よりソフトウェア改善から発生しています。可能な時にアプリケーション開発者はマルチスレッドを利用できるためにWeb Workersを利用している事を除いて、単一のスレッドのJavaScripパフォーマンスでもまだ改善しています。
作り話 #3: モバイルブラウザは既に完全に最適化されているので、最近は余り改善されてない。
実は: 各モバイルブラウザは10-40倍のファクタで他のブラウザに勝てる機能があります。SVGに関してはSurfaceはiPhoneに30倍勝っています。DOM操作においては、iPhoneはSurfaceに10倍勝っています。ただ現在の最高な競争的のパフォーマンスを合わせるだけでも、まだ改善できる状態です。
作り話 #4: 今後のハードウェア改善はウェブアプリケーションに対して、パフォーマンスの向上にはならない。
実は: この三年間で行ったハードウェア作成は重大なパフォーマンス改善を起こしました。モバイルの単一スレッドのパフォーマンスは向上しつつ、ブラウザメーカーはソフトウェアプラットフォームを利用して、 より素早いGPU速度、 より素早いメモリーバス 、オフローディングやマルチスレッドでマルチコアを要領よく利用します。 多くのブラウザは中心のUIスレッドをオフロードをするために並行処理を利用しています。例えば： Firefoxはコンポジットをオフロードします ；Chromeは いくつかのHTMLパースをオフロードします ； IEはJavaScript JIT コンパイルをオフロードします。
作り話 #5: JavaScriptのガーベージコレクションはモバイルアプリケーションのパフォーマンスを下げる。
実は: これは本当のようで少し古くさいです。Chromeには2011年の Chrome 17からインクリメンタル・ガーベージコレクターがあります。 Firefoxには去年からあります。 このGCでは200msから10msに停止時間が削減され、フレーム落ちやわかるような停止はなくなります。ガーベージコレクションのイベントを避けるとパフォーマンスが改善することもありますが、最初からデスクトップのweb devパターンか古いブラウザを利用している時だけに問題となります。我々のモバイルHTML5 Facebookのクローン「Fastbook」のコアテクニックの一つは、新しいDOMノードを生成するオーバーヘッド（と関連されている古いのGCコレクションのオーバーヘッド）を避ける為にDOMノードのプールを再利用することです。とてもひどいガーベージコレクターを書く可能性はあります（古いInternet Explorerを比較して下さい）、しかし、JavaScript（またはJava）のようなガーベージコレクションの言語にたいして基本的に制約的な部分はありません。
OK: 重要なポイント
まず、基本について考えましょう。空中から見ると、ブラウザはオペレーティングシステム上で動作するリッチで複雑な抽象化レイヤーです。その抽象化レイヤーをHTML、JavaScript、CSSを利用してアプリケーションのUXとします。この抽象化レイヤーはパフォーマンスに負担をかけますが、その負担は抽象化レイヤーのどの部分を利用しているかによります。 抽象化レイヤーのある部分は裏でOSを呼び出したり、システムライブラリと密接なので速くなります（ご存じMacOSのCanvas2D）。また、抽象化レイヤーのある部分は裏のOSに近くは無くて、基本的に複雑（DOMツリーの操作、プロトタイプチェーンウォーキング）なので、遅くなります。
“ Senchaでは良い開発者はモバイルウェブテクノロジーやSencha Touchの様なモダンなフレームワークを利用して、ユーザーが望むものと十分素早いアプリケーション体験を生成できることは知っています。 ”
モバイルアプリケーションはふつうガリガリ計算しません：だれもiPhoneでDNAシーケンス処理をしようとはしません。ほとんどのアプリケーションはとてもリーズナブルなレスポンスモデルがあります。ユーザーは何かして、アプリケーションが一秒当たり30フレーム、またはその以上でアプリケーションが表示で反応して、わずかな100ミリ秒でタスクを完成します。アプリケーションがこのユーザー目的がかなうと、シリコンにたどり着くまで、抽象化レイヤーの大きさは関係なくなります。これは消したい噂の一つです。
Senchaでは良い開発者はモバイルウェブテクノロジーやSencha Touchの様なモダーンなフレームワークを利用して、ユーザーが望むものと十分素早いアプリケーション体験を生成できることは知っています。それでこの３年間をかけたモバイルのパフォーマンストレンドをみて力強いです。この投稿の残りでは、そのデータを紹介しましょう。
モバイルウェブアプリケーションは常にネイティブ同等に速いこと、またはデスクトップウェブアプリケーションと比較できるようなパフォーマンスが可能と主張するのが目的ではありません。それは真実ではないでしょう。モバイルハードウェアはデスクトップと比べて5倍から10倍も遅いです：CPUがより弱い、キャッシュ階層はよりフラット、ネットワーク接続はより高いレイテンシです。その上、ソフトウェア抽象化（ブラウザの様に）は負担をかかります。これはウェブ開発者だけの問題ではありません。ネイティブiOSの開発者は、最初のRetina iPadでiOS CoreGraphicsが遅すぎたので、多くの開発者は直接OpenGLに書くようになりました。
作り話を深く掘り下げる
データドリブンアプリケーションにSencha Touchを最適化することを3年間かけて関わってきて、生のJavaScriptパフォーマンスで邪魔された事は無かったと自信をもって言えます。唯一のケースはAndroid 2.xでJavaScriptが遅すぎる事を発見した後に、Sencha TouchレイアウトシステムをFlexboxに切り替えた時です。
それよりも、DOM操作、ブラウザの描画エンジンやイベントスパムについての問題を経験しました。これは全て各ブラウザの設計者や開発者によって生成された制限なので、JavaScript、またはJavaScriptエンジンの根本的な特徴と関係ありません。一つの例として、ブラウザメーカーと一緒にパフォーマンス最適化に関わった時に、我々のスクロールリスト実装でのボトルネックだった、ブラウザ操作の一つ（色プロパティ変更）に40倍の改善を目撃しました。
iOSとAndroidのJavaScriptパフォーマンス
モバイルにJavaScriptのパフォーマンスはそこまで大切ではないと言いましたが、JavaScriptが進化していないという作り話を潰したと思います。以下にモデルとiOSバージョンで分けられている、iOS上のSunSpiderの4年間に渡る点数を表示している図です（低い方が良い）。（SunSpiderは広く利用されているテストなので、ウェブ上でより古いiOSバージョンのテストも探せばあります）。2009年にiOS3が動作していたオリジナルのiPhone 3GSは15,000のスコアでした：割と弱いパフォーマンスで、300~600点の2009年のデスクトップブラウザに対する約30倍のパフォーマンスギャップがあります。
しかし、もしそのiPhone 3GSをiOS4、5、6、にアップグレードしたら、全く同じハードウェアでJavaScriptパフォーマンスが4倍改善しました。（iOS4と5の間の大きいジャンプはNitroエンジンのお陰です）。SunSpiderの連続的な改善はiOS7でも続きますが、しかし、我々はまだ詳しい事はNDAが結ばれています。現在のデスクトップブラウザと比べて、エッジモバイルブラウザは約5倍遅いです：2009年の30倍のギャップと比べると比較的大きい改善となります。
iOSハードウェアのハードウェアやソフトウェア進行に対して、詳しくは 去年の10月のAnandtechのレビュー をご覧ください。
Androidプラットフォームでも似たようなレベルの改善がありました。我々のテストラボから、この3年間それぞれの時代で通常にハイエンドパフォーマンスを表すAndroidプラットフォームを集めました。
- Samsung Captivate Android 2.2 (2010年7月公開)
- Droid Bionic Android 2.3.4 (2011年9月公開)
- Samsung Galaxy Note 2 Android 4.1.2 (2012年９月公開)
- Samsung Galaxy S4 Android 4.2.2 (2013年４月公開)
以下でご覧になる通り、4年に渡ってSunSpiderのスコアも劇的な向上がありました。Android 2.xからAndroid 4.xのパフォーマンスジャンプは3倍の改善です。
両方の場合、この改善はムーアの法則だけで予測される改善を超えています。3年に渡って、4倍の改善を予測します（各18ヶ月で2倍）なのでソフトウェアは間違いなく、パフォーマンスの改善に貢献しています。
必要な部分をテストする
以前説明したように、SunSpiderは殆どのアプリケーションのパフォーマンスに薄いコネクションしかないため、余り面白くないベンチマークになりました。それと反対でCanvasとSVGベンチマークとともに、DOMインタラクションベンチマークはもっとユーザー体験について色々伝えてもらいます。（理想的にいうと、よくウェブアプリケーションで利用されるからCSSプロパティ変更、CSSアニメーションのfps、トランジションとトランスフォームの測定も見ますが、これをモバイルで正確に測定するフックはありません）。
最初のDOMインタラクションテスト：我々のベンチマークとして Dromaeo Core DOM テストを利用しました。以下は我々の４つのAndroidモデルでテストを行った結果です。我々は全てのCore DOMの結果をCaptivateのパフォーマンスにインデックスして、その後は4つのCore DOMの指標の平均をとりました。
ご覧の通りに、S4はNote 2に比べてマイナーな改善しかしてないのに、Android 2.xからAndroid 4.xまで3.5倍のパフォーマンス改善がありました。iOSでDromaeoの結果も見られます。残念ながらiOSのより古いバージョンのパフォーマンス比較はできませんが、いくつかiPhoneの複数のハードウェアの世代に渡った堅実な改善を表示できます。面白く、このデバイス世代に渡るiOS6だけのパフォーマンス改善でもCPU速度より良いので、メモリーバンド幅やキャッシングの改善がムーアの法則より良いパフォーマンス向上の理由でしょう。
それぞれのブラウザが他のブラウザのパフォーマンスを追いかける可能性がある事を示すために、Surface RTをベンチマークしました。IEのDOM操作の低いパフォーマンスはいつもがっかりするタネでしたが、iPhone対IE10が動作しているMicrosoft Surface RTのDOM操作パフォーマンスに関する大きいパフォーマンスギャップを指す価値があります。消したい噂の一つはモバイルソフトウェアスタックは完全に最高な状態であることです。Windows RTに対してこれは正確ではありません：まだ直すべき10倍のパフォーマンスギャップが存在しています。（後のベンチマークでiOSが不足な時を示します）。
グラフィックのベンチマーク
JavaScriptとDOM操作の相当な改善の上に、CanvasとSVGパフォーマンスの改善も示しましょう。iOS5ではiOS4と比べて、同じハードウェアでもCanvas2Dパフォーマンスは5から8倍の向上がありました。 iPad 2がiOS5にアップグレードされたら、いくつかのミクロベンチマークは80倍速く動作しました。 その他、CanvasはiPhoneのCoreGraphicsと密接なため、ネイティブのグラフィックスが速くなっていくと、Canvasもそうなります。このテストのラウンドではパフォーマンスを測定するには mindcat Canvas2Dベンチマーク を利用しました。ここで複数のiPhoneハードウェア世代上でCanvasパフォーマンスで相当な増加がみてとれ：全ては同じiOSの世代で動作しています。
それでiOS4からiOS5の大きいパフォーマンスゲインの上の事を忘れないで下さい。ご覧の通り、Canvas2Dパフォーマンスのパフォーマンス向上(7倍)は同じ期間のCPU改善（4倍）より良いので、iPhoneの時間をかけて改善したGPUとGPUソフトウェアスタックを反影しています。GPU改善とGPUアクセラレーションの進化は、モバイルウェブパフォーマンス改善に織り込む必要があります。
Androidで同じテストを見ると、面白いデータポイントが見えます：CPUとCanvasの間の相関の不足です。Android 2からの大きい違いはAndroid 2まではCanvasのGPUアクセラレーションは全くないということです。純粋にソフトウェアの変更です。GPUアクセラレーションはパフォーマンス改善の大きい刺激です。
SVG ベンチマーク
SVGはウェブパフォーマンスに関する重要な話のもう一つの部分です。Canvasより人気はありませんが、（それはCanvasがとても素早くなった理由が大きくて）、SVGもハードウェアが改善されることで、しっかりしたパフォーマンス改善も示してきました。以下は 1万セグメントのSVGパスを描くのにかかった時間 をテストするStephen Bannaschのテストを表示しています。また、このテストはCPUとGPUが改善しながら、ハードウェア世代を渡って一定している堅実な改善を表示します（これは全てiOS6なので）。
パフォーマンスの最大のギャップはソフトウェアに関するものです：Surface RTはiPhone 5 （またはiPad 4：それもテストしたけど載せていません）より30倍以上速いです。実はSurface RTは私の一年前に買ったDesktop Safari 6を利用しているMacbookよりも10倍も速いです！これがGPUアクセラレーションの影響です。Windows 8/IE10はGPUにSVGを完全にオフロードしますので、その結果はとても大きいインパクトがあります。ブラウザのメーカーさんがもっとGPUにグラフィックス操作のオフロードを続ける度に、iOSとAndroidで似ているようなステップ関数の変更が予測できます。
長いパス描画の他に、Cameron Adamsからの 1秒間に500フレームのバウンドするボール fpsを測定するテストを実行しました。また、4世代のハードウェアに渡って、一定のパフォーマンス改善が見えます。
改善より面白い事はアニメーション絶対fpsが30fpsを超えた時点で、アナログシネマのfps（24fps）を超えますので、観客が予測するパフォーマンスを上回ります。60fpsではGPUアクセラレーションの最もスムーズな状態になっています。
実際のパフォーマンス：ガーベージコレクション、動的言語とその他
我々の上記のモバイルパフォーマンスのツアーでいくつかのことを証明して、いくつかの作り話を覆したと期待しています。次のことを示したつもりです：
- JavaScriptのパフォーマンスは急速に改善し続けています
- このパフォーマンス改善はハードウェアとソフトウェア改善によってなされています
- これは「良いこと」ですが、アプリケーションパフォーマンスのほとんどはJavaScript CPUパフォーマンスとは無関係です
- うれしいことに、DOM操作、Canvas、SVGの速度など、他のパフォーマンスに影響する部分も急速に改善しています。
高速カメラテストのように表示できましたが、全てのモバイルウェブ開発者はAndroid2.1の時代からアニメーションのパフォーマンス、トランジション、プロパティ変更は大きく改善した事はご存知で、各リリースで継続して良くなっていきます。
いくつかの嘘つきドラゴンをやっつけた、今から少し本当の話に関わりましょう。最後に聞いた発言はJavaScriptは動的な言語でガーベージコレクションはパフォーマンスに悪影響があるため、モバイルウェブアプリケーションはいつも遅くなること。この話の中には、真実も確かに混ざっています。DOMが動的に生成されるSencha Touchのようなフレームワークを利用する一つの利点は、指定されたUIコンポーネント内でブラウザの上のレベルでオブジェクト生成、または破棄、とイベントを管理しているところです。こうすると、例えば、DOMコンテンツの再利用、イベントのスロットル、アクションの優先処理でデータバッキングされた無限のコンテンツ（グリッド、リスト、カルーセル）などで60fpsが可能となります。
このレベルの間接性がなかったら、簡単に低いモバイルウェブアプリケーション体験を生成することがあります：Facebookからのファーストジェネレーションのモバイルウェブアプリケーションのように。我々が思うには、背後にあるDOMに密着しすぎているjQuery MobileのようなUIフレームワークの上に作成されているアプリケーションは今後もパフォーマンスの問題がおこり続けるでしょう。
全部まとめる
このブログポストでたくさんのデータとテーマに触れましたので、一カ所で全てを収集しましょう。もしあなたが開発者でしたら、この投稿から覚えておくことはいくつかあります：
- モバイルプラットフォームはデスクトップと比べて5倍遅い：より遅いCPU、より制約されたメモリー、より低いパワーのGPU。それは変わりません。
- モバイルJavaScript + モバイルDOMアクセスは進歩的に速くなって来ましたが、iPhone 5は2008年時代のデスクトップ上でChrome 1.0のブラウザを動作しているようなものだと考えたほうが良いかもしれません（しっての通りデスクトップIE8より5倍から10倍速い）。
- グラフィックスもGPUアクセラレーションと全面的なソフトウェア最適化でだんだん速くなってきました。ほとんどの利用ケースでは30fps以上でます。
- ガーベージコレクションとプラットフォームレンダリングの制約にまだ傷つけられるので、最適なパフォーマンスを取得するにはSencha Touchのような抽象化されたフレームワークを利用することが必要です。
- 今の所はChromeとAndroidのようなモバイルウェブプラットフォームが提供しているリモートデバッグとパフォーマンスモニタリング機能を利用するべきです。有利のfpsカウンターとコンポジットボーダーはコンテンツにテクスチャーを加えてGPUに渡され、そのテクスチャーが何回ロードされたか表示してもらえます。
このパフォーマンスデータのレビューが今はやっている作り話の毒消しになったら嬉しいです。このブログポストに協力した人にお礼を申し上げます。Ariya Hidayatがブラウザパフォーマンス最適化のリンクをたくさんレビューとソーシングして頂いて、Jacky NguyenもSencha Touch抽象化とパフォーマンス最適化の内容を頂きました。
