パフォーマンスの基礎

最終的には、ユーザーが知覚したパフォーマンスが唯一のパフォーマンスとなります。ユーザーは、触ったり、動かしたり、話したりして、システムに入力を与えます。その代わり、ユーザーは視覚、触覚、聴覚を通じて出力を知覚します。パフォーマンスとは、ユーザーの入力に応じてシステムが出力するものの品質のことです。

他の条件が同じであれば、ユーザーが知覚するパフォーマンス (以下、UPP) 以外のターゲットに最適化されたコードは、 UPP に最適化されたコードと競合すると負けてしまいます。ユーザーは、例えば、 1 秒間に 1,000 件しかデータベーストランザクションを処理しないが応答性の高いスムーズに動くアプリの方を、 1 秒間に 100,000,000 件のデータベーストランザクションを処理するカクカクした応答性の低いアプリよりも好みます。もちろん、他の指標を最適化することは決して無意味ではありませんが、実際の UPP ターゲットが最優先です。

以下の節では、必須のパフォーマンス指標を指摘し、説明します。

応答性とは、ユーザーの入力に応じてシステムがどれだけ速く出力 (複数の場合もある) を行うかを意味します。例えば、ユーザーが画面をタップすると、ピクセルが特定の方法で変化することを期待します。この操作の場合、応答性の指標は、タップしてからピクセルが変化するまでの経過時間となります。

応答性には、複数の段階のフィードバックが含まれることがあります。アプリケーションの起動は、特に重要なケースの一つで、詳しくは後述します。

応答性が重要なのは、人は無視されるとイライラしたり怒ったりするからです。アプリはユーザーの入力に応答しない間、ユーザーを無視していることになります。

フレームレートとは、システムがユーザーに表示するピクセルを変化させる速度のことです。例えば、毎秒 10 フレームのゲームよりも、毎秒 60 フレームのゲームの方が好きだというのは、理由を説明できなくても、誰もが知っている概念です。

フレームレートは「サービスの質」の指標としても重要です。コンピューターのディスプレイは、現実を模倣した光子をユーザーの目に届けることで、ユーザーの目を「欺く」ように設計されています。例えば、文字が印刷された紙は、光子をあるパターンでユーザーの目に反射させます。リーダーアプリは、ピクセルを操作することで、同じようなパターンで光子を放出し、ユーザーの目を「騙す」のです。

脳は考えるとき、動きはギクシャクしたバラバラなものではなく、滑らかに連続して更新されるものだと考えます。 (ストロボはそれを逆手に取り、脳の入力を奪って離散的な現実を錯覚させるから面白いのです）。コンピューターのディスプレイでは、フレームレートが高ければ高いほど、より忠実に現実を再現することができます。

メモリーの使用量も重要な指標です。応答性やフレームレートとは異なり、ユーザーはメモリー使用量を直接知覚することはありませんが、メモリー使用量は「ユーザーの状態」に近いものです。理想的なシステムでは、ユーザーの状態を常に 100% 維持することができます。システム内のすべてのアプリケーションは同時に実行され、すべてのアプリケーションは、ユーザーが最後にアプリケーションを操作したにユーザーが設定した状態を維持します (アプリケーションの状態はコンピューターのメモリーに保存されているため、近似値になるのです)。

このことから、重要ではあるが直感的ではない副産物が得られます。設計の優れたシステムは、空きメモリー量を最大化しません。メモリーは資源であり、空きメモリーは使われていない資源であるからです。むしろ、設計の優れたシステムは、ユーザーの状態を維持するために可能な限り多くのメモリーを使用し、かつ他の UPP 目標を満たすように最適化されています。

これは、システムがメモリーを浪費すべきだという意味ではありません。システムがある特定のユーザーの状態を維持するために必要以上のメモリーを使用すると、システムは他のユーザーの状態を維持するために使用できる資源を浪費していることになります。実際には、すべてのユーザーの状態を維持できるシステムはありません。ユーザーの状態に賢くメモリーを割り当てることは、以下で詳しく説明する重要な問題です。

ここで解説する最後の指標は、電力使用量です。メモリー使用量と同様に、ユーザーは、端末が他のすべての UPP 目標を維持できる時間という形で、電力使用量を間接的にしか認識しません。 UPP 目標を達成するためには、システムは必要最小限の電力しか使用しないようにする必要があります。

この文書の残りの部分では、これらの指標の観点からパフォーマンスについて説明します。

この節では、 Firefox/Gecko が、すべてのアプリケーションのレベルよりも下位で、一般的にどのようにパフォーマンスに貢献しているかを簡単に説明します。開発者やユーザーの視点から、「プラットフォームは何をしてくれるのか？」という問いに答えます。

ウェブプラットフォームには多くのツールが用意されていますが、中には特定の仕事に適したものもあります。アプリケーションロジックはすべて JavaScript で書かれています。グラフィックの表示には、 (高水準の宣言型言語である) HTML や CSS を使用するか、低レベルの命令型インターフェースである <canvas> 要素 (WebGL を含む) を使用します。 HTML/CSS と Canvas の「中間」に位置するのが SVG で、両者の利点を兼ね備えています。

HTML や CSS は、フレームレートやピクセルレベルでのレンダリング制御を犠牲にして、生産性を大幅に向上させます。テキストや画像は自動的に再フローされ、 UI 要素には自動的にシステムのテーマが適用されます。また、このシステムは、様々な解像度のディスプレイや右書きの言語など、開発者が最初に思いつかないような使用方法に「組み込み」で対応します。

canvas 要素は、開発者が直接描画できるピクセルバッファーを提供します。これにより、開発者はピクセルレベルでレンダリングを制御し、フレームレートを正確に制御することができますが、複数の解像度や方向、右書きの言語などに対応する必要があります。開発者は、おなじみの 2D 描画 API か、 OpenGL ES 2.0 をほぼ踏襲した「金属に近い」バインディングである WebGL を使用してキャンバスに描画します。

Gecko の JavaScript エンジンは、実行時 (JIT) コンパイルに対応しています。これにより、アプリケーションロジックは、Java 仮想マシンのような他の仮想マシンと同等の性能を発揮し、場合によっては「ネイティブコード」に近い性能を発揮します。

HTML、CSS、Canvas を支える Gecko のグラフィックパイプラインは、いくつかの方法で最適化されています。 Gecko の HTML/CSS レイアウトおよびグラフィックコードは、スクロールなどの一般的なケースでは、無効化や再描画を削減しますが、開発者はこのサポートを「無料」で受けることができます。 Gecko が「自動的に」描画したり、 canvas へアプリケーションが「手動で」描画したりするピクセルバッファーは、ディスプレイのフレームバッファーに描画される際のコピーを最小限に抑えます。これは、中間サーフェスがオーバーヘッドになるような場所 (他の多くのオペレーティングシステムにおけるアプリケーションごとの「バックバッファー」など) を避け、コンポジターハードウェアが直接アクセスできるグラフィックバッファー用の特別なメモリーを使用することで実現されています。複雑なシーンのレンダリングには、端末の GPU を使用して最大のパフォーマンスを発揮します。電力消費を抑えるために、シンプルなシーンは専用の合成ハードウェアを使ってレンダリングし、 GPU はアイドルまたはオフにしています。

リッチアプリケーションでは、完全な静的コンテンツは例外です。リッチアプリケーションでは、アニメーション (animation) やトランジション (transition) 効果のある動的コンテンツを使用します。トランジションやアニメーションは、アプリケーションにとって特に重要です。開発者は、 CSS を使用することで、複雑な動作をシンプルで高レベルな構文で宣言することができます。また、 Gecko のグラフィックパイプラインは、一般的なアニメーションを効率的に描画するように高度に最適化されています。良くあるアニメーションは、システムコンポジターにオフロードされ、パフォーマンスと電力効率に優れた方法でレンダリングされます。

アプリの起動時のパフォーマンスは、実行時のパフォーマンスと同じくらい重要です。 Gecko は、 Web 全体を含むさまざまなコンテンツを効率的に読み込むように最適化されています。並列 HTML 解析、再フローと画像デコーディングのインテリジェントなスケジューリング、巧妙なレイアウトアルゴリズムなど、コンテンツを対象とした長年の改良は、Firefox でのウェブアプリケーションの改良にも同様に反映されます。

この節では、「どうしたらアプリを高速にできるのか」という開発者の問いのためのものです。

アプリケーションの起動は、一般的に 3 つのイベントで構成されています。

• 1 つ目は、アプリケーションのファーストペイント (最初のフレームを描くのに十分なアプリケーションリソースが読み込まれた時点) です。
• 2 つ目は、アプリケーションが操作可能になった時点です。例えば、ユーザーがボタンをタップすると、アプリケーションが反応するようになります。
• 最後のイベントは完全読み込みです。たとえば、音楽プレイヤーにユーザーのアルバムをすべて表示された時点です。

高速な起動の鍵となるのは、 2 つのことを念頭に置くことです。 UPP がすべてであること、そして上記のユーザーが知覚する各イベントには「クリティカルパス」が存在することです。クリティカルパスとは、まさに、そのイベントを発生させるために実行しなければならないコードのことです。

例えば、アプリケーションの最初のフレームを視覚的に描くためには、いくつかの HTML と、その HTML にスタイル付けする CSS で構成されます。

1. HTML を解釈する必要がある
2. その HTML の DOM を構築する必要がある
3. DOM の一部にある画像などのリソースを読み込み、デコードする必要がある
4. CSS のスタイルをその DOM に適用する必要がある
5. スタイル付けした文書を再フローさせる必要がある

このリストのどこにも、「一般的でないメニューに必要な JS ファイルの読み込み」や「ハイスコアリスト用の画像の取得とデコード」などは含まれていません。これらの作業項目は、最初のフレームを描くためのクリティカルパスには含まれていません。

当たり前のようですが、ユーザーが認識する起動イベントに早く到達するためには、クリティカルパス上のコードだけを実行することが主な「コツ」です。その場面を単純化することで、クリティカルパスを短縮します。

ウェブプラットフォームは非常にダイナミックです。 JavaScript は動的に型付けされる言語であり、ウェブプラットフォームではコード、HTML、CSS、画像などのリソースを動的に読み込むことができます。これらの機能を利用して、起動後しばらくしてから不要なコンテンツを「遅延して」読み込むことで、クリティカルパスから外れた作業を先送りすることができます。

起動を遅らせるもう 1 つの問題は、リクエストに対するレスポンス (データベースのロードなど) を待つことで発生するアイドルタイムです。この問題を避けるために、アプリケーションは起動時にできるだけ早くリクエストを発行する必要があります (これを「フロントローディング」と呼びます)。そうすれば、後でデータが必要になったとき、うまくいけばすでに利用可能で、アプリケーションは待つ必要がありません。

また、ローカルにキャッシュされた静的なリソースは、高レイテンシー、低帯域幅のモバイルネットワークを介して取得された動的なデータよりもはるかに速く読み込まれることに注意してください。ネットワークへのリクエストは、アプリケーションの早期起動のためのクリティカルパスであってはなりません。ローカルキャッシュ／オフラインアプリケーションは、サービスワーカーによって実現できます。オフラインおよびバックグラウンド同期機能のサービスワーカーの使用については、オフラインおよびバックグラウンド処理 (en-US)を参照してください。

高フレームレートを実現するためにまず重要なのは、適切な道具を選ぶことです。静止画やスクロール、アニメーションの頻度が少ないコンテンツの実装には、 HTML と CSS を使用します。レンダリングを厳密にコントロールする必要があり、テーマ性を必要としないゲームのように、高度に動的なコンテンツを実装する場合は、キャンバスを使用します。

キャンバスで使用される中身については、フレームレートの目標を達成できるかどうかは開発者次第であり、描画する内容を直接コントロールすることができます。

HTML と CSS のコンテンツでは、適切なプリミティブを使用することが高フレームレートへの道となります。 Firefox は任意のコンテンツをスクロールするために高度に最適化されているため、通常はこの点を気にする必要はありません。しかし、 CSS の放射状グラデーションの代わりに静的なレンダリングを使用するなど、速度のために汎用性や品質を犠牲にすると、スクロールのフレームレートが目標値を超えてしまうことがよくあります。 CSS のメディアクエリーを使えば、こうした妥協を必要とする端末だけに制限することができます。

多くのアプリケーションでは、「ページ」や「パネル」を使ったトランジションやアニメーションが使われています。例えば、ユーザーが「設定」ボタンをタップすると、アプリケーションの設定画面に遷移したり、設定メニューが「ポップアップ」したりします。 Firefox は、以下のようなシーンの遷移やアニメーションに高度に最適化されています。

• 端末の画面サイズ以下のページ/パネルを使用する
• CSS 変換や不透明度のプロパティを使った遷移やアニメーションを使用する

これらのガイドラインに従った遷移やアニメーションは、システムコンポジターにオフロードされ、最大限効率的に動作します。

メモリーと電力使用量の改善は、スタートアップの高速化と同じような問題です。必要のない作業をしたり、普段使わない UI リソースをダラダラとロードしたりしてはいけません。効率的なデータ構造を使用し、画像などのリソースをしっかりと最適化しましょう。

最近の CPU は、ほとんどアイドル状態の時に低消費電力モードに入ることができます。常にタイマーを作動させたり、不要なアニメーションを実行し続けるアプリケーションは、 CPU が低電力モードに入るのを妨げます。電力効率の良いアプリケーションは、そのようなことをしてはいけません。

アプリケーションがバックグラウンドに送られると、その文書に対して visibilitychange イベントが発行されます。このイベントは開発者の味方です。アプリケーションはこのイベントを待ち受けするべきです。

以下の実用的なヒントは、前述のアプリケーションのパフォーマンス要因の 1 つまたは複数を改善するのに役立ちます。

CSS アニメーションとトランジションを使用する

一部のライブラリーの animate() 関数は、おそらく現在、パフォーマンスが悪い数多くの技術 (例えば setTimeout() や top/left による位置指定) を使用しています。代わりに CSS アニメーションを使用してください。多くの場合、実際には CSS トランジションを使って実現することができます。ブラウザーはこれらの効果を最適化するように設計されており、 GPU を使用してプロセッサーのパフォーマンスへの影響を最小限に抑えながらスムーズに処理することができるため、うまく機能します。もう一つの利点は、標準化された構文を使って、アプリの他のルック＆フィールと一緒に CSS でこれらの効果を定義できることです。

CSS アニメーションでは、 キーフレームを使って効果を細かく制御することができます。また、アニメーション処理中に発生するイベントを監視して、アニメーション処理中の特定のポイントで実行する必要のある他のタスクを処理することもできます。これらのアニメーションは、 :hover, :focus, :target を使ったり、親要素に動的にクラスを追加したり削除したりすることで、簡単に起動することができます。

アニメーションをその場で作成したり、 JavaScript で修正したりしたい場合は、 James Long 氏が CSS-animations.js というシンプルなライブラリーを作成していますので、そちらをご利用ください。

CSS 座標変換を使用する

コンテンツの位置やスケールなどを調整するのに、絶対位置を調整したり、すべての計算を自分で行ったりする代わりに、 CSS の transform プロパティを使用しましょう。あるいは、translate, scale, rotate の各変換プロパティを使用することもできます。その理由は、繰り返しになりますが、ハードウェアアクセラレーションです。ブラウザーはこれらの作業を GPU で行い、 CPU に他の処理をさせることができます。

さらに、変換は、他では得られない機能を提供します。 2D 空間の要素を変換するだけでなく、 3 次元に変換したり、斜めにしたり、回転させたりすることができます。 Paul Irish 氏は、パフォーマンスの観点から見た translate() の利点を詳しく分析 (2012) しています。しかし、一般的には、 CSS アニメーションを使用する場合と同じメリットがあります。つまり、仕事に適したツールを使用し、最適化はブラウザーに任せることができるのです。また、要素の位置を簡単に拡張できる方法を使用しています。 top と left の位置指定で座標変換をシミュレートする場合は、多くの追加コードが必要になります。もうひとつの利点は、 canvas 要素で作業するのと同じだということです。

requestAnimationFrame() を setInterval() の代わりに使用する

setInterval() の呼び出しは、現在の状況下で可能かどうかわからない推定フレームレートでコードを実行します。このコードは、ブラウザーが実際に描画していない間、つまりビデオハードウェアが次の表示サイクルに達していない間にも、結果をレンダリングするようブラウザーに指示します。これはプロセッサー時間を浪費し、ユーザーの端末のバッテリー寿命を縮めることにもつながります。

その代わりに、 window.requestAnimationFrame() を使うようにしましょう。これは、ブラウザーがアニメーションの次のフレームを作り始める準備ができるまで待機し、ハードウェアが実際に何も描画しない場合は無視します。この API のもう一つの利点は、アプリが画面上に表示されていない間はアニメーションが実行されないことです (バックグラウンドで他のタスクが動作している場合など)。これにより、バッテリーの消費を抑え、ユーザーが夜空に向かってあなたの名前を罵るのを防ぐことができます。

イベントを即時にする

アクセシビリティに配慮した古いタイプのウェブ開発者は、キーボード入力にも対応する click イベントが大好きです。モバイル端末では、これらのイベントは遅すぎます。代わりに touchstart と touchend を使うべきです。これらのイベントには、アプリの操作を鈍くする遅延がないからです。最初にタッチ対応のテストを行えば、アクセシビリティも犠牲にすることはありません。例えば、 Financial Times は、そのために fastclick というライブラリーを使用しており、これを利用することができます。

インターフェイスをシンプルに保つ

HTML アプリのパフォーマンスに関する大きな問題のひとつに、たくさんの DOM 要素を移動させるとすべてが遅くなるということがあります。見た目をシンプルにして、ドラッグ＆ドロップでプロキシー要素を移動させるようにすると非常に有効です。

たとえば、長い要素のリスト (ツイートとします) がある場合、それらをすべて移動させてはいけません。代わりに、表示されているものと、現在表示されているツイートのセットの両側にいくつかあるものだけを DOM ツリーに残します。残りは隠すか削除します。データを DOM にアクセスするのではなく、 JavaScript のオブジェクトに保持することで、アプリのパフォーマンスが大幅に向上します。表示は、データそのものではなく、データのプレゼンテーションだと考えてください。だからといって、 HTML をそのままソースとして使ってはいけないというわけではありません。 HTML を一度読み込んでから 10 個の要素をスクロールさせ、表示されていない 100 個の要素を動かすのではなく、結果リストの中の自分の位置に応じて最初と最後の要素の内容を変えればいいのです。ゲームでは、スプライトにも同じことが言えます。その代わりに、画面外にスクロールした要素を新しいものが入ってきたときに再利用します。

Firefox や Chrome などのブラウザーには、ページの表示速度が遅いことを診断するためのツールが組み込まれています。特に、 Firefox のネットワークモニターは、ページ上のそれぞれのネットワークリクエストがいつ発生し、どれくらいの規模で、どれくらいの時間がかかっているかを正確に時系列で表示します。

ページに実行に時間がかかる JavaScript コードが含まれている場合、 JavaScript プロファイラーは最も遅いコードの行を特定します。

Gecko 内蔵のプロファイラーは、プロファイラーの実行中にブラウザーのコードのどの部分がゆっくりと動作しているかについて、さらに詳細な情報を提供する非常に便利なツールです。これは使用方法が少し複雑ですが、多くの有用な詳細情報を提供してくれます。

特に、モバイルブラウザーでは、数十から数百のネットワークリクエストに時間がかかります。また、大きな画像や CSS グラデーションの描画にも時間がかかることがあります。大きなファイルのダウンロードは、高速なネットワークであっても時間がかかることがあります。これは、モバイルハードウェアの速度が遅すぎて、利用可能なすべての帯域幅を活用できない場合があるためです。モバイルウェブのパフォーマンスに関する一般的なヒントについては、 Maximiliano Firtman 氏の Mobile Web High Performance の談話をご覧ください。

Firefox や Chrome の開発者ツールで問題が解決しない場合や、ウェブブラウザーが原因と思われる場合は、問題を最大限に分離した縮小版のテストケースを提供してみてください。それが問題の診断に役立つことがよくあります。

HTML ページの静的なコピー (埋め込まれている画像、スタイルシート、スクリプトを含む) を保存、読み込みすることで問題を再現できるかどうかを確認してください。問題が再現できれば、静的ファイルを編集して個人情報を削除し、他の人に送って助けを求めてください (例えば、 Bugzilla レポートを提出するか、サーバーでホスティングして URL を共有してください)。また、上述のツールを使って収集したプロファイリング情報も共有してください。