diff options
| author | Masahiro FUJIMOTO <mfujimot@gmail.com> | 2021-08-04 10:22:00 +0900 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-08-04 10:22:00 +0900 |
| commit | cf9a876f3e270f665cddddb2a6b75f2be64f8895 (patch) | |
| tree | 0192cede03ff290a218698e51bf6304024644ead /files/ja | |
| parent | b1fdb94830bee8ed169ec9c6c20e535a7d6524fa (diff) | |
| download | translated-content-cf9a876f3e270f665cddddb2a6b75f2be64f8895.tar.gz translated-content-cf9a876f3e270f665cddddb2a6b75f2be64f8895.tar.bz2 translated-content-cf9a876f3e270f665cddddb2a6b75f2be64f8895.zip | |
Web/Performance 以下のいくつかの文書を更新 (#1686)
下記の文書を 2021/07/25 時点の英語版に同期更新
- Web/Performance
- Web/Performance/How_browsers_work
また、下記の文書を新規翻訳
- Web/Performance/Fundamentals
Diffstat (limited to 'files/ja')
| -rw-r--r-- | files/ja/web/performance/fundamentals/index.html | 219 | ||||
| -rw-r--r-- | files/ja/web/performance/how_browsers_work/index.html | 82 | ||||
| -rw-r--r-- | files/ja/web/performance/index.html | 208 |
3 files changed, 364 insertions, 145 deletions
diff --git a/files/ja/web/performance/fundamentals/index.html b/files/ja/web/performance/fundamentals/index.html new file mode 100644 index 0000000000..eec0ddf96f --- /dev/null +++ b/files/ja/web/performance/fundamentals/index.html @@ -0,0 +1,219 @@ +--- +title: パフォーマンスの基礎 +slug: Web/Performance/Fundamentals +tags: + - Apps + - Firefox + - Gecko + - Guide + - Performance +translation_of: Web/Performance/Fundamentals +--- +<div class="summary"> +<p><span class="seoSummary">パフォーマンスとは、効率性を意味します。この文書では、オープンウェブアプリの観点から、パフォーマンスとは何か、ブラウザープラットフォームでどのようにパフォーマンスを向上させるか、テストや改善にどのようなツールやプロセスを使用できるかについて一般的な説明をします。.</span></p> +</div> + +<h2 id="What_is_performance">パフォーマンスとは</h2> + +<p>最終的には、ユーザーが知覚したパフォーマンスが唯一のパフォーマンスとなります。ユーザーは、触ったり、動かしたり、話したりして、システムに入力を与えます。その代わり、ユーザーは視覚、触覚、聴覚を通じて出力を知覚します。パフォーマンスとは、ユーザーの入力に応じてシステムが出力するものの品質のことです。</p> + +<p>他の条件が同じであれば、ユーザーが知覚するパフォーマンス (以下、UPP) 以外のターゲットに最適化されたコードは、 UPP に最適化されたコードと競合すると負けてしまいます。ユーザーは、例えば、 1 秒間に 1,000 件しかデータベーストランザクションを処理しないが応答性の高いスムーズに動くアプリの方を、 1 秒間に 100,000,000 件のデータベーストランザクションを処理するカクカクした応答性の低いアプリよりも好みます。もちろん、他の指標を最適化することは決して無意味ではありませんが、実際の UPP ターゲットが最優先です。</p> + +<p>以下の節では、必須のパフォーマンス指標を指摘し、説明します。</p> + +<h3 id="Responsiveness">応答性</h3> + +<p>応答性とは、ユーザーの入力に応じてシステムがどれだけ速く出力 (複数の場合もある) を行うかを意味します。例えば、ユーザーが画面をタップすると、ピクセルが特定の方法で変化することを期待します。この操作の場合、応答性の指標は、タップしてからピクセルが変化するまでの経過時間となります。</p> + +<p>応答性には、複数の段階のフィードバックが含まれることがあります。アプリケーションの起動は、特に重要なケースの一つで、詳しくは後述します。</p> + +<p>応答性が重要なのは、人は無視されるとイライラしたり怒ったりするからです。アプリはユーザーの入力に応答しない間、ユーザーを無視していることになります。</p> + +<h3 id="Framerate">フレームレート</h3> + +<p>フレームレートとは、システムがユーザーに表示するピクセルを変化させる速度のことです。例えば、毎秒 10 フレームのゲームよりも、毎秒 60 フレームのゲームの方が好きだというのは、理由を説明できなくても、誰もが知っている概念です。</p> + +<p>フレームレートは「サービスの質」の指標としても重要です。コンピューターのディスプレイは、現実を模倣した光子をユーザーの目に届けることで、ユーザーの目を「欺く」ように設計されています。例えば、文字が印刷された紙は、光子をあるパターンでユーザーの目に反射させます。リーダーアプリは、ピクセルを操作することで、同じようなパターンで光子を放出し、ユーザーの目を「騙す」のです。</p> + +<p>脳は考えるとき、動きはギクシャクしたバラバラなものではなく、滑らかに連続して更新されるものだと考えます。 (ストロボはそれを逆手に取り、脳の入力を奪って離散的な現実を錯覚させるから面白いのです）。コンピューターのディスプレイでは、フレームレートが高ければ高いほど、より忠実に現実を再現することができます。</p> + +<div class="note"> +<p><strong>注</strong>: 人間は通常、60Hz以上のフレームレートの違いを知覚することができません。そのため、最近の電子ディスプレイは、60Hzで更新するように設計されています。例えばハチドリには、テレビが途切れ途切れで非現実的に見えることでしょう。</p> +</div> + +<h3 id="Memory_usage">メモリーの使用</h3> + +<p><strong>メモリーの使用量</strong>も重要な指標です。応答性やフレームレートとは異なり、ユーザーはメモリー使用量を直接知覚することはありませんが、メモリー使用量は「ユーザーの状態」に近いものです。理想的なシステムでは、ユーザーの状態を常に 100% 維持することができます。システム内のすべてのアプリケーションは同時に実行され、すべてのアプリケーションは、ユーザーが最後にアプリケーションを操作したにユーザーが設定した状態を維持します (アプリケーションの状態はコンピュータのメモリーに保存されているため、近似値になるのです)。</p> + +<p>このことから、重要ではあるが直感的ではない副産物が得られます。設計の優れたシステムは、<strong>空き</strong>メモリー量を最大化しません。メモリーは資源であり、空きメモリーは使われていない資源であるからです。むしろ、設計の優れたシステムは、ユーザーの状態を維持するために可能な限り多くのメモリーを使用し、かつ他の UPP 目標を満たすように最適化されています。</p> + +<p>これは、システムがメモリーを<strong>浪費</strong>すべきだという意味ではありません。システムがある特定のユーザーの状態を維持するために必要以上のメモリーを使用すると、システムは他のユーザーの状態を維持するために使用できる資源を浪費していることになります。実際には、すべてのユーザーの状態を維持できるシステムはありません。ユーザーの状態に賢くメモリーを割り当てることは、以下で詳しく説明する重要な問題です。</p> + +<h3 id="Power_usage">電力使用量</h3> + +<p>ここで解説する最後の指標は、<strong>電力使用量</strong>です。メモリー使用量と同様に、ユーザーは、端末が他のすべての UPP 目標を維持できる時間という形で、電力使用量を間接的にしか認識しません。 UPP 目標を達成するためには、システムは必要最小限の電力しか使用しないようにする必要があります。</p> + +<p>この文書の残りの部分では、これらの指標の観点からパフォーマンスについて説明します。</p> + +<h2 id="Platform_performance_optimizations">プラットフォームのパフォーマンスの最適化</h2> + +<p>この節では、 Firefox/Gecko が、すべてのアプリケーションのレベルよりも下位で、一般的にどのようにパフォーマンスに貢献しているかを簡単に説明します。開発者やユーザーの視点から、「プラットフォームは何をしてくれるのか？」という問いに答えます。</p> + +<h3 id="Web_technologies">ウェブ技術</h3> + +<p>ウェブプラットフォームには多くのツールが用意されていますが、中には特定の仕事に適したものもあります。アプリケーションロジックはすべて JavaScript で書かれています。グラフィックの表示には、 (高水準の宣言型言語である) HTML や CSS を使用するか、低レベルの命令型インターフェースである {{ htmlelement("canvas") }} 要素 (<a href="/ja/docs/Web/API/WebGL_API">WebGL</a> を含む) を使用します。 HTML/CSS と Canvas の「中間」に位置するのが <a href="/ja/docs/Web/SVG">SVG</a> で、両者の利点を兼ね備えています。</p> + +<p>HTML や CSS は、フレームレートやピクセルレベルでのレンダリング制御を犠牲にして、生産性を大幅に向上させます。テキストや画像は自動的に再フローされ、 UI 要素には自動的にシステムのテーマが適用されます。また、このシステムは、様々な解像度のディスプレイや右書きの言語など、開発者が最初に思いつかないような使用方法に「組み込み」で対応します。</p> + +<p><code>canvas</code> 要素は、開発者が直接描画できるピクセルバッファーを提供します。これにより、開発者はピクセルレベルでレンダリングを制御し、フレームレートを正確に制御することができますが、複数の解像度や方向、右書きの言語などに対応する必要があります。開発者は、おなじみの 2D 描画 API か、 OpenGL ES 2.0 をほぼ踏襲した「金属に近い」バインディングである WebGL を使用してキャンバスに描画します。</p> + +<div class="note"> +<p><strong>注</strong>: Firefox OS は、 <a href="/ja/docs/Web/HTML">HTML</a>、<a href="/ja/docs/Web/CSS">CSS</a>、<a href="/ja/docs/Web/JavaScript">JavaScript</a> などのウェブ技術で作られたアプリに最適化されています。一握りの基本的なシステムサービスを除いて、 Firefox OS で動作するすべてのコードはウェブアプリと Gecko エンジンから来ています。 OS のウィンドウマネージャも HTML、CSS、JavaScript で書かれています。コアとなる OS とアプリケーションは同じウェブ技術で構築されているため、これらの技術がどのように機能するかが重要になります。そこには「逃げ道」はありません。これは開発者にとって大きなメリットです。なぜなら、サードパーティのアプリケーションは、 OS が独自に行ったすべての最適化の恩恵を受けることができるからです。プリインストールされたコードだけが利用できる「魔法のパフォーマンスソース」はありません。 Firefox OS に関する詳細は、 <a href="/ja/docs/Archive/B2G_OS/Firefox_OS_apps/Performance/Firefox_OS_performance_testing">Firefox OS のパフォーマンステスト</a>をご覧ください。</p> +</div> + +<h3 id="Gecko_rendering">Gecko のレンダリング</h3> + +<p>Gecko の JavaScript エンジンは、実行時 (JIT) コンパイルに対応しています。これにより、アプリケーションロジックは、Java 仮想マシンのような他の仮想マシンと同等の性能を発揮し、場合によっては「ネイティブコード」に近い性能を発揮します。</p> + +<p>HTML、CSS、Canvas を支える Gecko のグラフィックパイプラインは、いくつかの方法で最適化されています。 Gecko の HTML/CSS レイアウトおよびグラフィックコードは、スクロールなどの一般的なケースでは、無効化や再描画を削減しますが、開発者はこのサポートを「無料」で受けることができます。 Gecko が「自動的に」描画したり、 <code>canvas</code> へアプリケーションが「手動で」描画したりするピクセルバッファーは、ディスプレイのフレームバッファーに描画される際のコピーを最小限に抑えます。これは、中間サーフェスがオーバーヘッドになるような場所 (他の多くのオペレーティングシステムにおけるアプリケーションごとの「バックバッファー」など) を避け、コンポジターハードウェアが直接アクセスできるグラフィックバッファー用の特別なメモリーを使用することで実現されています。複雑なシーンのレンダリングには、端末の GPU を使用して最大のパフォーマンスを発揮します。電力消費を抑えるために、シンプルなシーンは専用の合成ハードウェアを使ってレンダリングし、 GPU はアイドルまたはオフにしています。</p> + +<p>リッチアプリケーションでは、完全な静的コンテンツは例外です。リッチアプリケーションでは、アニメーションやトランジション効果のある動的コンテンツを使用します。トランジションやアニメーションは、アプリケーションにとって特に重要です。開発者は、 CSS を使用することで、複雑な動作をシンプルで高レベルな構文で宣言することができます。また、 Gecko のグラフィックパイプラインは、一般的なアニメーションを効率的に描画するように高度に最適化されています。良くあるアニメーションは、システムコンポジターにオフロードされ、パフォーマンスと電力効率に優れた方法でレンダリングされます。</p> + +<p>アプリの起動時のパフォーマンスは、実行時のパフォーマンスと同じくらい重要です。 Gecko は、 Web 全体を含むさまざまなコンテンツを効率的に読み込むように最適化されています。並列 HTML 解析、再フローと画像デコーディングのインテリジェントなスケジューリング、巧妙なレイアウトアルゴリズムなど、コンテンツを対象とした長年の改良は、Firefox でのウェブアプリケーションの改良にも同様に反映されます。</p> + +<div class="note"> +<p><strong>注</strong>: 起動時のパフォーマンスをさらに向上させるための Firefox OS の仕様についての詳細は、 <a href="/ja/docs/Archive/B2G_OS/Firefox_OS_apps/Performance/Firefox_OS_performance_testing">Firefox OS パフォーマンステスト</a>を参照してください。</p> +</div> + +<h2 id="Application_performance">アプリケーションのパフォーマンス</h2> + +<p>この節では、「どうしたらアプリを高速にできるのか」という開発者の問いのためのものです。</p> + +<h3 id="Startup_performance">起動時のパフォーマンス</h3> + +<p>アプリケーションの起動は、一般的に 3 つのイベントで構成されています。</p> + +<ul> + <li>1 つ目は、アプリケーションの<strong>ファーストペイント</strong> (最初のフレームを描くのに十分なアプリケーションリソースが読み込まれた時点) です。</li> + <li>2 つ目は、アプリケーションが操作可能になった時点です。例えば、ユーザーがボタンをタップすると、アプリケーションが反応するようになります。</li> + <li>最後のイベントは<strong>完全読み込み</strong>です。たとえば、音楽プレイヤーにユーザーのアルバムをすべて表示された時点です。</li> +</ul> + +<p>高速な起動の鍵となるのは、 2 つのことを念頭に置くことです。 UPP がすべてであること、そして上記のユーザーが知覚する各イベントには「クリティカルパス」が存在することです。クリティカルパスとは、まさに、そのイベントを発生させるために実行しなければならないコードのことです。</p> + +<p>例えば、アプリケーションの最初のフレームを視覚的に描くためには、いくつかの HTML と、その HTML にスタイル付けする CSS で構成されます。</p> + +<ol> + <li>HTML を解釈する必要がある</li> + <li>その HTML の DOM を構築する必要がある</li> + <li>DOM の一部にある画像などのリソースを読み込み、デコードする必要がある</li> + <li>CSS のスタイルをその DOM に適用する必要がある</li> + <li>スタイル付けした文書を再フローさせる必要がある</li> +</ol> + +<p>このリストのどこにも、「一般的でないメニューに必要な JS ファイルの読み込み」や「ハイスコアリスト用の画像の取得とデコード」などは含まれていません。これらの作業項目は、最初のフレームを描くためのクリティカルパスには含まれていません。</p> + +<p>当たり前のようですが、ユーザーが認識する起動イベントに早く到達するためには、<em>クリティカルパス上のコードだけ</em>を実行することが主な「コツ」です。その場面を単純化することで、クリティカルパスを短縮します。</p> + +<p>ウェブプラットフォームは非常にダイナミックです。 JavaScript は動的に型付けされる言語であり、ウェブプラットフォームではコード、HTML、CSS、画像などのリソースを動的に読み込むことができます。これらの機能を利用して、起動後しばらくしてから不要なコンテンツを「遅延して」読み込むことで、クリティカルパスから外れた作業を先送りすることができます。</p> + +<p>起動を遅らせるもう 1 つの問題は、リクエストに対するレスポンス (データベースのロードなど) を待つことで発生するアイドルタイムです。この問題を避けるために、アプリケーションは起動時にできるだけ早くリクエストを発行する必要があります (これを「フロントローディング」と呼びます)。そうすれば、後でデータが必要になったとき、うまくいけばすでに利用可能で、アプリケーションは待つ必要がありません。</p> + +<div class="note"> +<p><strong>注</strong>: 起動時のパフォーマンスを向上させるための詳しい情報は、<a href="/ja/docs/Web/Performance/Optimizing_startup_performance">起動時のパフォーマンスを最適化する</a>をご覧ください。</p> +</div> + +<p>また、ローカルにキャッシュされた静的なリソースは、高レイテンシー、低帯域幅のモバイルネットワークを介して取得された動的なデータよりもはるかに速く読み込まれることに注意してください。ネットワークへのリクエストは、アプリケーションの早期起動のためのクリティカルパスであってはなりません。ローカルキャッシュ／オフラインアプリケーションは、<a href="/ja/docs/Web/API/Service_Worker_API">サービスワーカー</a>によって実現できます。その方法については、 <a href="/ja/docs/Web/Progressive_web_apps/Offline_Service_workers">サービスワーカーで PWA をオフライン対応させる</a> を参照してください。</p> + +<h3 id="Framerate_2">フレームレート</h3> + +<p>高フレームレートを実現するためにまず重要なのは、適切な道具を選ぶことです。静止画やスクロール、アニメーションの頻度が少ないコンテンツの実装には、 HTML と CSS を使用します。レンダリングを厳密にコントロールする必要があり、テーマ性を必要としないゲームのように、高度に動的なコンテンツを実装する場合は、キャンバスを使用します。</p> + +<p>キャンバスで描かれたコンテンツでは、フレームレートの目標値を達成できるかどうかは、開発者次第です。</p> + +<p>HTML と CSS のコンテンツでは、適切なプリミティブを使用することが高フレームレートへの道となります。 Firefox は任意のコンテンツをスクロールするために高度に最適化されているため、通常はこの点を気にする必要はありません。しかし、 CSS の放射状グラデーションの代わりに静的なレンダリングを使用するなど、速度のために汎用性や品質を犠牲にすると、スクロールのフレームレートが目標値を超えてしまうことがよくあります。 CSS の<a href="/ja/docs/Web/CSS/Media_Queries/Using_media_queries">メディアクエリー</a>を使えば、こうした妥協を必要とする端末だけに制限することができます。</p> + +<p>多くのアプリケーションでは、「ページ」や「パネル」を使ったトランジションやアニメーションが使われています。例えば、ユーザーが「設定」ボタンをタップすると、アプリケーションの設定画面に遷移したり、設定メニューが「ポップアップ」したりします。 Firefox は、以下のようなシーンの遷移やアニメーションに高度に最適化されています。</p> + +<ul> + <li>端末の画面サイズ以下のページ/パネルを使用する</li> + <li>CSS 変換や不透明度のプロパティを使った遷移やアニメーションを使用する</li> +</ul> + +<p>これらのガイドラインに従った遷移やアニメーションは、システムコンポジターにオフロードされ、最大限効率的に動作します。</p> + +<h3 id="Memory_and_power_usage">メモリーと電力の使用量</h3> + +<p>メモリーと電力使用量の改善は、スタートアップの高速化と同じような問題です。必要のない作業をしたり、普段使わない UI リソースをダラダラとロードしたりしてはいけません。効率的なデータ構造を使用し、画像などのリソースをしっかりと最適化しましょう。</p> + +<p>最近の CPU は、ほとんどアイドル状態の時に低消費電力モードに入ることができます。常にタイマーを作動させたり、不要なアニメーションを実行し続けるアプリケーションは、 CPU が低電力モードに入るのを妨げます。電力効率の良いアプリケーションは、そのようなことをしてはいけません。</p> + +<p>アプリケーションがバックグラウンドに送られると、その文書に対して {{event("visibilitychange")}} イベントが発行されます。このイベントは開発者の味方です。アプリケーションはこのイベントに耳を傾けるべきです。バックグラウンドに送られたときに、アプリケーションが読み込まれたリソースをできるだけ多く手放すと、メモリー使用量が少なくて済み、 Firefox OS の場合、廃棄される可能性も低くなります (以下のメモを参照)。これはつまり、 (すでに実行されているため) 「起動」が速く、 UPP が良いことを意味します。</p> + +<div class="note"> +<p><strong>注</strong>: 前述のとおり、 Firefox OS はできる限り多くのアプリケーションを同時に実行するようにしていますが、通常は端末のメモリーが不足したときにアプリケーションを破棄しなければならないことがあります。Firefox OS がどのようにメモリー使用量を管理し、メモリー不足の問題が発生したときにアプリケーションを終了するかについての詳細は、「<a href="/ja/docs/Archive/B2G_OS/Debugging/Debugging_OOMs">Debugging out of memory errors on Firefox OS</a>」を参照してください。</p> +</div> + +<h3 id="Specific_coding_tips_for_application_performance">アプリケーションのパフォーマンスのためのコーディングのコツ</h3> + +<p>以下の実用的なヒントは、前述のアプリケーションのパフォーマンス要因の 1 つまたは複数を改善するのに役立ちます。</p> + +<h4 id="Use_CSS_animations_and_transitions">CSS アニメーションとトランジションを使用する</h4> + +<p>一部のライブラリーの <code>animate()</code> 関数は、おそらく現在、パフォーマンスが悪い数多くの技術 (例えば {{domxref("WindowOrWorkerGlobalScope.setTimeout")}} や <code>top</code>/<code>left</code> による位置指定) を使用しています。代わりに <a href="/ja/docs/Web/CSS/CSS_Animations/Using_CSS_animations">CSS アニメーション</a>を使用してください。多くの場合、実際には <a href="/ja/docs/Web/CSS/CSS_Transitions/Using_CSS_transitions">CSS トランジション</a>を使って実現することができます。ブラウザーはこれらの効果を最適化するように設計されており、 GPU を使用してプロセッサーのパフォーマンスへの影響を最小限に抑えながらスムーズに処理することができるため、うまく機能します。もう一つの利点は、標準化された構文を使って、アプリの他のルック＆フィールと一緒に CSS でこれらの効果を定義できることです。</p> + +<p>CSS アニメーションでは、 <a href="/ja/docs/Web/CSS/@keyframes">キーフレーム</a>を使って効果を細かく制御することができます。また、アニメーション処理中に発生するイベントを監視して、アニメーション処理中の特定のポイントで実行する必要のある他のタスクを処理することもできます。これらのアニメーションは、 {{cssxref(":hover")}}, {{cssxref(":focus")}}, {{cssxref(":target")}} を使ったり、親要素に動的にクラスを追加したり削除したりすることで、簡単に起動することができます。</p> + +<p>アニメーションをその場で作成したり、 <a href="/ja/docs/Web/JavaScript">JavaScript</a> で修正したりしたい場合は、 James Long 氏が <a href="https://github.com/jlongster/css-animations.js/">CSS-animations.js</a> というシンプルなライブラリーを作成していますので、そちらをご利用ください。</p> + +<h4 id="Use_CSS_transforms">CSS 変換を使用する</h4> + +<p>コンテンツの位置やスケールなどを調整するのに、絶対位置を調整したり、すべての計算を自分で行ったりする代わりに、 CSS の {{cssxref("transform")}} プロパティを使用しましょう。その理由は、繰り返しになりますが、ハードウェアアクセラレーションです。ブラウザーはこれらの作業を GPU で行い、 CPU に他の処理をさせることができます。</p> + +<p>さらに、変換は、他では得られない機能を提供します。 2D 空間の要素を変換するだけでなく、 3 次元に変換したり、斜めにしたり、回転させたりすることができます。 Paul Irish 氏は、パフォーマンスの観点から見た <a href="https://paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/"><code>translate()</code> の利点を詳しく分析</a>しています。しかし、一般的には、 CSS アニメーションを使用する場合と同じメリットがあります。つまり、仕事に適したツールを使用し、最適化はブラウザーに任せることができるのです。また、要素の位置を簡単に拡張できる方法を使用しています。 <code>top</code> と <code>left</code> の位置指定で変換をシミュレートする場合は、多くの追加コードが必要になります。もうひとつの利点は、 <code>canvas</code> 要素で作業するのと同じだということです。</p> + +<div class="note"> +<p><strong>注</strong>: プラットフォームによっては、 CSS アニメーションでハードウェアアクセラレーションを利用したい場合、 <code>translateZ(0.1)</code> 変換を割り当てる必要があります。前述のとおり、パフォーマンスが向上しますが、メモリー消費の問題もあります。テストをして、自分のアプリケーションに最適な方法を見つけてみてはいかがでしょうか。</p> +</div> + +<h4 id="Use_requestAnimationFrame_instead_of_setInterval"><code>requestAnimationFrame()</code> を <code>setInterval()</code> の代わりに使用する</h4> + +<p>{{domxref("WindowOrWorkerGlobalScope.setInterval")}} の呼び出しは、現在の状況下で可能かどうかわからない推定フレームレートでコードを実行します。このコードは、ブラウザーが実際に描画していない間、つまりビデオハードウェアが次の表示サイクルに達していない間にも、結果をレンダリングするようブラウザーに指示します。これはプロセッサー時間を浪費し、ユーザーの端末のバッテリー寿命を縮めることにもつながります。</p> + +<p>その代わりに、 {{domxref("window.requestAnimationFrame()")}} を使うようにしましょう。これは、ブラウザーがアニメーションの次のフレームを作り始める準備ができるまで待機し、ハードウェアが実際に何も描画しない場合は無視します。この API のもう一つの利点は、アプリが画面上に表示されていない間はアニメーションが実行されないことです (バックグラウンドで他のタスクが動作している場合など)。これにより、バッテリーの消費を抑え、ユーザーが夜空に向かってあなたの名前を罵るのを防ぐことができます。</p> + +<h4 id="Make_events_immediate">イベントを即時にする</h4> + +<p>アクセシビリティに配慮した古いタイプのウェブ開発者は、キーボード入力二も対応する click イベントが大好きです。モバイル端末では、これらのイベントは遅すぎます。代わりに {{event("touchstart")}} と {{event("touchend")}} を使うべきです。これらのイベントには、アプリの操作を鈍くする遅延がないからです。最初にタッチ対応のテストを行えば、アクセシビリティも犠牲にすることはありません。例えば、 Financial Times は、そのために <a href="https://github.com/ftlabs/fastclick">fastclick</a> というライブラリーを使用しており、これを利用することができます。</p> + +<h4 id="Keep_your_interface_simple">インターフェイスをシンプルに保つ</h4> + +<p>HTML5 アプリのパフォーマンスに関する大きな問題のひとつに、たくさんの <a href="/ja/docs/Web/API/Document_Object_Model">DOM</a> 要素を移動させるとすべてが遅くなるということがあります。見た目をシンプルにして、ドラッグ＆ドロップでプロキシー要素を移動させるようにすると非常に有効です。</p> + +<p>たとえば、長い要素のリスト (ツイートとします) がある場合、それらをすべて移動させてはいけません。代わりに、表示されているものと、現在表示されているツイートのセットの両側にいくつかあるものだけを DOM ツリーに残します。残りは隠すか削除します。データを DOM にアクセスするのではなく、 JavaScript のオブジェクトに保持することで、アプリのパフォーマンスが大幅に向上します。表示は、データそのものではなく、データのプレゼンテーションだと考えてください。だからといって、 HTML をそのままソースとして使ってはいけないというわけではありません。 HTML を一度読み込んでから 10 個の要素をスクロールさせ、表示されていない 100 個の要素を動かすのではなく、結果リストの中の自分の位置に応じて最初と最後の要素の内容を変えればいいのです。ゲームでは、スプライトにも同じことが言えます。その代わりに、画面外にスクロールした要素を新しいものが入ってきたときに再利用します。</p> + +<h2 id="General_application_performance_analysis">一般的なアプリケーションのパフォーマンス分析</h2> + +<p>Firefox や Chrome などのブラウザーには、ページの表示速度が遅いことを診断するためのツールが組み込まれています。特に、 <a href="/ja/docs/Tools/Network_Monitor">Firefox のネットワークモニター</a>は、ページ上のそれぞれのネットワークリクエストがいつ発生し、どれくらいの規模で、どれくらいの時間がかかっているかを正確に時系列で表示します。</p> + +<p><img alt="Firefox のネットワークモニターが、リクエストの取得、複数のファイル、各リソースの読み込みにかかった時間をグラフで表示しているところ。" src="network-monitor.jpg" style="display: block; margin: 0px auto;"></p> + +<p>ページに実行に時間がかかる JavaScript コードが含まれている場合、 <a href="/ja/docs/Tools/Performance">JavaScript プロファイラー</a>は最も遅いコードの行を特定します。</p> + +<p><img alt="Firefox の JavaScript プロファイラーが完成したプロファイル 1 を表示しているところ。" src="javascript-profiler.png" style="display: block; margin: 0px auto;"></p> + +<p><a href="/ja/docs/Performance/Profiling_with_the_Built-in_Profiler">Gecko 内蔵のプロファイラー</a> は、プロファイラーの実行中にブラウザーのコードのどの部分がゆっくりと動作しているかについて、さらに詳細な情報を提供する非常に便利なツールです。これは使用方法が少し複雑ですが、多くの有用な詳細情報を提供してくれます。</p> + +<p><img alt="Gecko 内蔵プロファイラーウィンドウが多くのネットワーク情報を表示しているところ。" src="gecko-profiler.png" style="display: block; margin: 0px auto;"></p> + +<div class="note"> +<p><strong>注</strong>: Android のブラウザーで Firefox を起動し、<a href="/ja/docs/Tools/Remote_Debugging">リモートデバッグ</a>を有効にすることで、これらのツールを使用することができます。</p> +</div> + +<p>特に、モバイルブラウザーでは、数十から数百のネットワークリクエストに時間がかかります。また、大きな画像や CSS グラデーションの描画にも時間がかかることがあります。大きなファイルのダウンロードは、高速なネットワークであっても時間がかかることがあります。これは、モバイルハードウェアの速度が遅すぎて、利用可能なすべての帯域幅を活用できない場合があるためです。モバイルウェブのパフォーマンスに関する一般的なヒントについては、 Maximiliano Firtman 氏の <a href="https://www.slideshare.net/firt/mobile-web-high-performance">Mobile Web High Performance</a> の談話をご覧ください。</p> + +<h3 id="Test_cases_and_submitting_bugs">テストケースとバグの報告</h3> + +<p>Firefox や Chrome の開発者ツールで問題が解決しない場合や、ウェブブラウザーが原因と思われる場合は、問題を最大限に分離した縮小版のテストケースを提供してみてください。それが問題の診断に役立つことがよくあります。</p> + +<p>HTML ページの静的なコピー (埋め込まれている画像、スタイルシート、スクリプトを含む) を保存、読み込みすることで問題を再現できるかどうかを確認してください。問題が再現できれば、静的ファイルを編集して個人情報を削除し、他の人に送って助けを求めてください (例えば、 <a href="https://bugzilla.mozilla.org/">Bugzilla</a> レポートを提出するか、サーバーでホスティングして URL を共有してください)。また、上述のツールを使って収集したプロファイリング情報も共有してください。</p> diff --git a/files/ja/web/performance/how_browsers_work/index.html b/files/ja/web/performance/how_browsers_work/index.html index f936eb14a7..9483fed99b 100644 --- a/files/ja/web/performance/how_browsers_work/index.html +++ b/files/ja/web/performance/how_browsers_work/index.html @@ -1,5 +1,5 @@ --- -title: ページの生成：ブラウザーはどのように動作するか +title: 'ページの生成: ブラウザーの動作の仕組み' slug: Web/Performance/How_browsers_work tags: - Browsers @@ -15,27 +15,27 @@ tags: - render translation_of: Web/Performance/How_browsers_work --- -<p>ユーザーは、読み込みが速く、スムーズにインタラクションできるコンテンツを、ウェブで体験することを求めています。したがって、<span class="seoSummary">開発者はこれらふたつの目標を達成するために努力しなければいけません。</span></p> +<p>ユーザーは、読み込みが速く、スムーズに操作できるコンテンツを、ウェブで体験することを求めています。したがって、<span class="seoSummary">開発者はこれらふたつの目標を達成するために努力しなければいけません。</span></p> <p><span class="seoSummary">どうやって性能そして体感性能を改善するか理解するためには、ブラウザーがどのように動作するかを理解することが役に立ちます。</span></p> -<h2 id="Overview" name="Overview">概要</h2> +<h2 id="Overview">概要</h2> -<p>速いサイトはより良いユーザー体験をもたらします。ユーザーは読み込みが速く、スムーズにインタラクションできるコンテンツを体験することを求め、期待しています。</p> +<p>速いサイトはより良いユーザー体験をもたらします。ユーザーは読み込みが速く、スムーズに操作できるコンテンツを体験することを求め、期待しています。</p> <p>ウェブの性能における 2 つの主要な課題は、レイテンシーに関する諸問題と、多くの場合ブラウザーはシングルスレッドであるという事実に関する諸問題を理解することです。</p> <p>レイテンシーは、速い読み込みを実現するために克服しなければいけない一番の脅威です。読み込みを速くしようとする開発者のゴールは、リクエストされた情報をできる限り速く送信すること、または少なくともとても速いように見せることです。ネットワークのレイテンシーは、バイト情報をコンピューターまで送信するのにかかる時間のことです。ウェブの性能は、ページの読み込みを出来る限り速くするよう私たちが何をするかにかかっています。</p> -<p>多くの場合、ブラウザーはシングルスレッドだと考えられます。スムーズなインタラクションを実現しようとする開発者のゴールは、滑らかなスクロール、タッチ操作への反応など、期待通りのサイトのインタラクションを実現することです。メインスレッドが全ての処理を時間内に完了し、その上でユーザーのインタラクションを常にハンドリングできるよう保証するために、描画時間が鍵となります。ブラウザーがシングルスレッドであることによる特性を理解し、メインスレッドの責務を最小限に抑え、可能かつ適切な場合に、描画のスムーズさとインタラクションへの即時の反応を実現することで、ウェブの性能が改善されます。</p> +<p>多くの場合、ブラウザーはシングルスレッドだと考えられます。スムーズな操作を実現しようとする開発者のゴールは、滑らかなスクロール、タッチ操作への反応など、期待通りのサイトの操作を実現することです。メインスレッドが全ての処理を時間内に完了し、その上でユーザーの操作を常にハンドリングできるよう保証するために、描画時間が鍵となります。ブラウザーがシングルスレッドであることによる特性を理解し、メインスレッドの責務を最小限に抑え、可能かつ適切な場合に、描画のスムーズさと操作への即時の反応を実現することで、ウェブの性能が改善されます。</p> -<h2 id="Navigation" name="Navigation">ナビゲーション</h2> +<h2 id="Navigation">ナビゲーション</h2> <p><em>ナビゲーション</em>はウェブページを読み込むための最初の一歩です。ユーザーが URL をアドレスバーに入力したり、リンクをクリックしたり、またはフォームを送信したり、ページをリクエストするたびごとにナビゲーションが発生します。</p> <p>ウェブの性能における目標の 1 つは、ナビゲーションが完了するまでの時間を最小限にすることです。理想的な条件下において、一般的にこの時間が長すぎることはありませんが、レイテンシーと帯域幅が遅延を引き起こす邪魔者になる場合があります。</p> -<h3 id="DNS_Lookup" name="DNS_Lookup">DNS ルックアップ</h3> +<h3 id="DNS_Lookup">DNS ルックアップ</h3> <p>ウェブページへのナビゲーションの最初の一歩は、ページのアセットがどこにあるか見つけることです。<code>https://example.com</code> へアクセスする場合、その HTML のページは IP アドレスが <code>93.184.216.34</code> のサーバーに存在します。これまでに一度もそのサイトを訪れたことがなかった場合、DNS ルックアップが必要になります。</p> @@ -43,27 +43,27 @@ translation_of: Web/Performance/How_browsers_work <p>DNS ルックアップは、一般的に、1 回のページ読み込みの中でホスト名ごとに 1 回だけ必要になります。しかし、DNS ルックアップは要求されたページが参照するユニークなホストネームそれぞれに対して実行が必要です。必要なフォントや画像、スクリプト、広告、メトリクスのそれぞれが異なるホスト名を持っている場合は、それぞれに対して DNS ルックアップが必要です。</p> -<p><img alt="Mobile requests go first to the cell tower, then to a central phone company computer before being sent to the internet" src="https://mdn.mozillademos.org/files/16743/latency.jpg" style="height: 281px; width: 792px;"></p> +<p><img alt="携帯電話のリクエストは、まずセルタワーに送られ、次に電話会社の中央コンピューターに送られた後、インターネットに送信される" src="latency.jpg"></p> <p>これはとくにモバイルネットワークにおいて性能上の問題になる可能性があります。ユーザーがモバイルネットワークを利用している場合、DNS ルックアップは、権威 DNS サーバーへ到達するために、電話機から基地局へ送信される必要があります。電話機と基地局、そしてネームサーバー間の距離によって重大な遅延が発生する場合があります。</p> -<h3 id="TCP_Handshake" name="TCP_Handshake">TCP ハンドシェイク</h3> +<h3 id="TCP_Handshake">TCP ハンドシェイク</h3> <p>IP アドレスが判明すると、ブラウザーは {{glossary('TCP handshake','TCP 3 ウェイハンドシェイク')}}を通じてサーバーとのコネクションを設定します。この仕組みは、通信を意図する 2 つの主体が—この場合はブラウザーとウェブサーバーが—、データを送信する前に、多くの場合 {{glossary('HTTPS')}} を用いて、ネットワーク TCP ソケットコネクションのパラメーターを交換できるよう設計されています。</p> <p>TCP の 3 ウェイハンドシェイクは、しばしば、"SYN-SYN-ACK"、より正確には SYN、SYN-ACK、ACK と呼ばれます。これは 2 つのコンピューターの間で TCP のセッションを開始するために、TCP によって 3 つのメッセージが送受信されることを表します。つまり、これはそれぞれのサーバーの間で 3 回以上のメッセージのやりとりが必要であり、そのためのリクエストが生成されなければいけないことを意味しています。</p> -<h3 id="TLS_Negotiation" name="TLS_Negotiation">TLS ネゴシエーション</h3> +<h3 id="TLS_Negotiation">TLS ネゴシエーション</h3> <p>HTTPS によって確立される安全なコネクションでは、もう 1 つのハンドシェイクが必要です。このハンドシェイク、より正確に言うと {{glossary('TLS')}} ネゴシエーションは、通信の暗号化に使用する暗号の種類を決定し、サーバーを認証し、実際のデータ送信が始まる前に安全な通信の準備を整えます。この処理は、コンテンツのリクエストを実際に送信する前に、さらに 3 回のラウンドトリップを必要とします。</p> -<p><img alt="The DNS lookup, the TCP handshake, and 5 steps of the TLS handshake including clienthello, serverhello and certificate, clientkey and finished for both server and client." src="https://mdn.mozillademos.org/files/16746/ssl.jpg" style="height: 412px; width: 729px;"></p> +<p><img alt="DNS ルックアップ、TCP ハンドシェイク、そして TLS ハンドシェイクの 5 つのステップ (clienthello、serverhello、証明書、clientkey、サーバーとクライアントの両方の完了)。" src="ssl.jpg"></p> <p>通信を安全にするためにページ読み込みの時間が追加されますが、ブラウザーとサーバーの間で送信されるデータが第三者に解読されないという安全な通信は、レイテンシーに見合う価値があるものです。</p> <p>8 回のラウンドトリップを経て、ブラウザーはようやくリクエストを送ることができます。</p> -<h2 id="Response" name="Response">レスポンス</h2> +<h2 id="Response">レスポンス</h2> <p>ウェブサーバーへのコネクションが確立されると、ブラウザーはユーザーに代わって最初の <a href="/ja/docs/Web/HTTP/Methods">HTTP <code>GET</code> リクエスト</a>を送信します。ウェブサイトであれば、多くの場合その対象は HTML ファイルです。リクエストを受け取ったサーバーは、適当なレスポンスヘッダーと HTML のコンテンツを返します。</p> @@ -89,21 +89,21 @@ translation_of: Web/Performance/How_browsers_work <p>上記のサンプルコードでは、リクエストされたコンテンツは明らかに 14kB より小さいですが、後述するように、リンクされたリソースは、ブラウザーのパース処理がそのリンクにたどり着くまでリクエストされることはありません。</p> -<h3 id="TCP_Slow_Start_14kb_rule" name="TCP_Slow_Start_14kb_rule">TCP スロースタート / 14kB ルール</h3> +<h3 id="TCP_Slow_Start_14kb_rule">TCP スロースタート / 14kB ルール</h3> <p>最初の応答パケットは 14kB になります。これは、{{glossary('TCP slow start','TCP スロースタート')}}の一部で、ネットワークコネクションの速度を制御するアルゴリズムの影響です。スロースタートは、ネットワークの最大の帯域幅が確定するまで徐々に送信するデータ量が増やします。</p> <p>{{glossary('TCP slow start','TCP スロースタート')}}において、サーバーは最初のパケットを受信した後、次のパケットのサイズを 28kB に倍増させます。さらに後続のパケットについて事前に決めた上限に達するか、ネットワークの輻輳を検知するまでサイズを増やします。</p> -<p><img alt="TCP slow start" src="https://mdn.mozillademos.org/files/16754/congestioncontrol.jpg" style="height: 412px; width: 729px;"></p> +<p><img alt="TCP スロースタート" src="congestioncontrol.jpg"></p> <p>最初のページ読み込みに関する 14kB ルールを聞いたことがあった場合、それは TCP スロースタートが理由です。そしてこれはウェブの性能の最適化が最初の 14kB にフォーカスする理由でもあります。TCP スロースタートは、ネットワークの輻輳を防ぎ、ネットワーク性能に対して適正なデータ転送速度を徐々に探り出します。</p> -<h3 id="Congestion_control" name="Congestion_control">輻輳制御</h3> +<h3 id="Congestion_control">輻輳制御</h3> <p>サーバーが TCP パケットとしてデータを送信する一方で、ユーザー側のクライアントは確認応答、ACK を返してデータが配送されたことを確認します。コネクションには、ハードウェアやネットワークの条件によって許容量上の制限があります。サーバーが大きすぎるパケットを速すぎる速度で送信した場合、破棄されるでしょう。つまり、確認応答がない場合があるということです。サーバーはこれを missing ACK として処理します。輻輳制御アルゴリズムは、パケットを送信して確認応答を受け取るこのフローを使って送信レート (send rate) を決定します。</p> -<h2 id="Parsing" name="Parsing">パース処理</h2> +<h2 id="Parsing">パース処理</h2> <p>データの最初のかたまりを受け取ると、ブラウザーは受信した情報のパース処理を始めることができます。{{glossary('speculative parsing', 'パース処理')}}は、ネットワークから受信したデータを {{glossary('DOM')}} と {{glossary('CSSOM')}} に変換するステップです。DOM と CSSOM は、レンダラーがページを画面へ描画するために利用されます。</p> @@ -111,7 +111,7 @@ translation_of: Web/Performance/How_browsers_work <p>ブラウザーは、リクエストしたページの HTML が最初の 14kB のパケットより大きかった場合でも、手元にあるデータに基づいてパース処理を開始し、サイトを描画しようとします。これは、ウェブの性能を最適化する時にに、ブラウザーがページの描画を始めるために必要なすべてのデータ、あるいは少なくともページのテンプレート (最初の描画に必要となる CSS と HTML) を最初の 14kB に含めることが重要となる理由です。何か 1 つでも画面に描画を行うには、その前に HTML と CSS、JavaScript がパースされなければいけません。</p> -<h3 id="Building_the_DOM_tree" name="Building_the_DOM_tree">DOM ツリーの構築</h3> +<h3 id="Building_the_DOM_tree">DOM ツリーの構築</h3> <p><a href="/ja/docs/Web/Performance/Critical_rendering_path">クリティカルレンダリングパス</a>の 5 つのステップを説明します。</p> @@ -119,11 +119,11 @@ translation_of: Web/Performance/How_browsers_work <p>DOM ツリーはドキュメントのコンテンツを表します。<code><a href="/ja/docs/Web/HTML/Element/html"><html></a></code> 要素は最初のタグであり、ドキュメントツリーのルートノードとなります。ツリーには、異なるタグ同士の関係と階層構造が反映されます。他のタグの中にネストされたタグは子要素となります。DOM ノードの数が増えるほど、DOM ツリーの構築にかかる時間は長くなります。</p> -<p><img alt="The DOM tree for our sample code, showing all the nodes, including text nodes." src="https://mdn.mozillademos.org/files/16759/DOM.gif" style="height: 689px; width: 754px;"></p> +<p><img alt="サンプルコードの DOM ツリーで、テキストノードを含むすべてのノードが表示されています。" src="dom.gif"></p> <p>パーサーが画像のようなノンブロッキングリソースを発見した場合、ブラウザーはそのリソースをリクエストし、そのままパース処理を継続します。CSS ファイルに遭遇した場合もパース処理を継続できます、しかし <code><a href="/ja/docs/Web/JavaScript/Reference/Statements/async_function">async</a></code> または <code>defer</code> 属性がない <code><script></code> タグはレンダリングをブロックし、HTML のパース処理を停止します。ブラウザーのプリロードスキャナーがブロックの時間を減らしますが、それでも過度のスクリプトの使用は重大なボトルネックになり得ます。</p> -<h3 id="Preload_scanner" name="Preload_scanner">プリロードスキャナー</h3> +<h3 id="Preload_scanner">プリロードスキャナー</h3> <p>ブラウザーが DOM ツリーを構築する間はそのプロセスがメインスレッドを占有します。その間に<em>プリロードスキャナー</em>が処理可能なコンテンツをパースし、CSS や JavaScript、ウェブフォントのような優先度の高いリソースのリクエストを行います。プリロードスキャナーのおかげで、リクエストするべき外部リソースへの参照をパーサーが見つけるのを待たなくて良くなります。バックグラウンドでリソースを取得するため、メインの HTML パーサーが該当のアセットにたどり着いた時には、すでにそれらのリソースが転送中あるいはダウンロード済みになっています。プリロードスキャナーによる最適化によりブロッキングを減らすることができます。</p> @@ -137,7 +137,7 @@ translation_of: Web/Performance/How_browsers_work <p>CSS の取得は HTML のパース処理あるいはダウンロードをブロックしません。しかし JavaScript の実行をブロックします。その理由は、しばしば JavaScript が CSS プロパティの要素への影響を問い合わせるために使われるからです。</p> -<h3 id="Building_the_CSSOM" name="Building_the_CSSOM">CSSOM の構築</h3> +<h3 id="Building_the_CSSOM">CSSOM の構築</h3> <p>クリティカルレンダリングパスの 2 つめのステップは CSS を処理して CSSOM ツリーを構築することです。CSS のオブジェクトモデルは DOM によく似ています。DOM と CSSOM はどちらもツリー構造です。この 2 つは独立したデータ構造を持ちます。ブラウザーは、CSS のルールをブラウザーが理解できるスタイルのマップに変換します。ブラウザーは CSS のルールセットを読み取り、CSS セレクターにもとづいて、親、子、兄弟の関係から構成されるノードのツリーを生成します。</p> @@ -147,23 +147,23 @@ translation_of: Web/Performance/How_browsers_work <p>CSSOM の構築はとても高速であるため、現在の開発者ツールはそれ自体をユニークな色で表示しません。その代わりに、開発者ツールの「スタイルの再計算」は、CSS を解析して CSSOM ツリーを構築し、再帰的にスタイルを計算するトータルの時間を表示します。ウェブの性能の最適化の観点から言うと、CSSOM を生成するトータルの時間は一般的に１回の DNS ルックアップにかかる時間よりも少ないため、それほどの苦労はないと言えます。</p> -<h3 id="Other_Processes" name="Other_Processes">その他の処理</h3> +<h3 id="Other_Processes">その他の処理</h3> -<h4 id="JavaScript_Compilation" name="JavaScript_Compilation">JavaScript のコンパイル</h4> +<h4 id="JavaScript_Compilation">JavaScript のコンパイル</h4> <p>CSS がパースされ、CSSOM が生成される間、JavaScript ファイルを含む他のアセットが（プリロードスキャナーによって）ダウンロードされます。JavaScript は、インタープリターに処理され、コンパイル、パース処理を経て実行されます。スクリプトはパース処理によって抽象構文木に変換されます。いくつかのブラウザーエンジンは、{{glossary('Abstract Syntax Tree', '抽象構文木')}}をインタープリターへ引き渡し、メインスレッドで実行されるバイトコードを出力します。これが JavaScript のコンパイル処理に当たります。</p> -<h4 id="Building_the_Accessibility_Tree" name="Building_the_Accessibility_Tree">アクセシビリティツリーの構築</h4> +<h4 id="Building_the_Accessibility_Tree">アクセシビリティツリーの構築</h4> <p>ブラウザーはコンテンツを理解し翻訳する補助機器で使用される<a href="/ja/docs/Learn/Accessibility">アクセシビリティ</a>ツリーも構築します。アクセシビリティオブジェクトモデル (AOM) は補助機器向けの DOM のようなものです。ブラウザーは、DOM が更新されるとアクセシビリティツリーも更新します。アクセシビリティツリーは補助機能それ自体からは変更できません。</p> <p>AOM が構築されるまで、<a href="/ja/docs/Web/Accessibility/ARIA/ARIA_Screen_Reader_Implementors_Guide">スクリーンリーダー</a>でコンテンツにアクセスできません。</p> -<h2 id="Render" name="Render">レンダリング</h2> +<h2 id="Render">レンダリング</h2> -<p>レンダリングのステップは、スタイル、レイアウト、ペイント、そしてコンポジットで構成されます。パースのステップで作成された CSSOM と DOM のツリーはレンダーツリーの形式へと組み合わされ、すべてのビジュアル要素のレイアウトを計算するために使用されてスクリーンに描画されます。いくつかのケースでは、CPU の代わりに GPU を使用してスクリーンの一部を描画し、メインスレッドを解放してパフォーマンスを改善するために、コンテンツ自身をレイヤーに昇格し、コンポジットを行います。</p> +<p>レンダリングのステップは、スタイル、レイアウト、描画、そして合成で構成されます。パースのステップで作成された CSSOM と DOM のツリーはレンダーツリーの形式へと組み合わされ、すべてのビジュアル要素のレイアウトを計算するために使用されてスクリーンに描画されます。いくつかのケースでは、CPU の代わりに GPU を使用してスクリーンの一部を描画し、メインスレッドを解放してパフォーマンスを改善するために、コンテンツ自身をレイヤーに昇格し、合成を行います。</p> -<h3 id="Style" name="Style">スタイル</h3> +<h3 id="Style">スタイル</h3> <p>クリティカルレンダリングパスの 3 番目のステップは DOM と CSSOM をレンダーツリーの形式へと組み合わせることです。計算されたスタイルのツリー、あるいはレンダーツリー、の構築は DOM ツリーのルートからスタートし、目に見える (Visible) ノードをトラバースします。</p> @@ -171,45 +171,45 @@ translation_of: Web/Performance/How_browsers_work <p>それぞれの目に見えるノードには、CSSOM のルールが適用されます。レンダーツリーはすべての目に見えるノードをコンテンツと計算されたスタイルを合わせて保持します。すべての関連するスタイルと DOM 上の目に見えるノードをマッチングし、<a href="/ja/docs/Web/CSS/Cascade">CSS カスケード</a>に基づいて、それぞれのノードに対応する計算されたスタイルを決定します。</p> -<h3 id="Layout" name="Layout">レイアウト</h3> +<h3 id="Layout">レイアウト</h3> -<p>クリティカルレンダリングパスの 4 番目のステップは各ノードの平面状の位置を計算するためにレイアウト処理を実行することです。<em>レイアウト</em>はレンダーツリーに含まれるすべてのノードの幅と高さ、位置を決める処理です。さらにページ上のそれぞれオブジェクトのサイズと位置を決定します。<em>リフロー</em>は、続いて発生するドキュメント全体、あるいはページの一部分のサイズと位置を決める処理です。</p> +<p>クリティカルレンダリングパスの 4 番目のステップは各ノードの平面状の位置を計算するためにレイアウト処理を実行することです。<em>レイアウト</em>はレンダーツリーに含まれるすべてのノードの幅と高さ、位置を決める処理です。さらにページ上のそれぞれオブジェクトのサイズと位置を決定します。<em>再フロー</em>は、続いて発生するドキュメント全体、あるいはページの一部分のサイズと位置を決める処理です。</p> <p>レンダーツリーが構築されるとすぐにレイアウトが始まります。レンダーツリーは計算されたスタイルを踏まえてどのノードが表示されるか (非表示であっても) 特定しますが、寸法や位置は特定しません。各オブジェクトの正確なサイズと位置を決めるために、ブラウザーがレンダーツリーのルートからトラバースを行います。</p> <p>ウェブページ上では、ほとんどすべての要素はボックスです。異なるデバイス、異なるデスクトップの設定は、ビューポートのサイズの数が無制限に存在することを示しています。このフェーズにおいて、ビューポートのサイズを考慮して、ブラウザーはすべての異なるボックスのスクリーン上の寸法を決定します。ビューポートのサイズを基本として、レイアウトは一般的にボディからスタートし、すべてのボディの子孫をそれぞれの要素のボックスモデルプロパティに合わせてレイアウトし、画像のように寸法がわからない代替要素のためのプレースホルダースペースを作成します。</p> -<p>ノードのサイズとポジションが決められる最初のタイミングをレイアウトと呼びます。続いて発生するノードのサイズと位置の再計算をリフロー呼びます。私たちの例では、画像が返される前に最初のレイアウトが発生すると考えられます。画像のサイズを宣言していなかったため、画像のサイズがわかるとすぐにリフローが発生します。</p> +<p>ノードのサイズとポジションが決められる最初のタイミングをレイアウトと呼びます。続いて発生するノードのサイズと位置の再計算を再フロー呼びます。私たちの例では、画像が返される前に最初のレイアウトが発生すると考えられます。画像のサイズを宣言していなかったため、画像のサイズがわかるとすぐに再フローが発生します。</p> -<h3 id="Paint" name="Paint">ペイント</h3> +<h3 id="Paint">描画</h3> -<p>クリティカルレンダリングパスの最後のステップは個別のノードをスクリーンにペイントすることです。最初に発生するペイントを <a href="/ja/docs/Glossary/first_meaningful_paint">first meaningful paint</a> と呼びます。ペイントまたはラスタライゼーションのフェーズにおいて、ブラウザーはレイアウトフェーズで計算されたそれぞれのボックスをスクリーン上の実際のピクセルに変換します。ペイントは、テキスト、色、ボーダー、シャドウ、ボタンや画像のような置換要素を含む、要素のすべての視覚的な部分をスクリーンに描くことを含みます。ブラウザーはこれを超高速で実行する必要があります。</p> +<p>クリティカルレンダリングパスの最後のステップは個別のノードをスクリーンに描画することです。最初に発生する描画を <a href="/ja/docs/Glossary/first_meaningful_paint">first meaningful paint</a> と呼びます。描画またはラスタライズのフェーズにおいて、ブラウザーはレイアウトフェーズで計算されたそれぞれのボックスをスクリーン上の実際のピクセルに変換します。描画は、テキスト、色、境界、シャドウ、ボタンや画像のような置換要素を含む、要素のすべての視覚的な部分をスクリーンに描くことを含みます。ブラウザーはこれを超高速で実行する必要があります。</p> -<p>スムーズなスクロールとアニメーションを実現するために、スタイルの計算やリフロー、ペイントなどメインスレッドを占有するすべての処理は、16.67ms 未満で完了する必要があります。2048 x 1536 の解像度を持つ iPad は 3,145,000 を超えるピクセルを持っています。それら大量のピクセルは高速にペイントされなければいけません。２回目以降のペイントを最初のペイントより高速にするため、スクリーンへの描画は一般的に複数のレイヤーに分解されます。この場合にコンポジットが必要になります。</p> +<p>スムーズなスクロールとアニメーションを実現するために、スタイルの計算や再フロー、描画などメインスレッドを占有するすべての処理は、16.67ms 未満で完了する必要があります。2048 x 1536 の解像度を持つ iPad は 3,145,000 を超えるピクセルを持っています。それら大量のピクセルは高速に描画されなければいけません。２回目以降の描画を最初の描画より高速にするため、スクリーンへの描画は一般的に複数のレイヤーに分解されます。この場合に合成が必要になります。</p> -<p>ペイントはペイントツリー内の要素をレイヤーに分解します。コンテンツを GPU (CPU 上のメインスレッドの代わりになる) 上のレイヤーに昇格させることで、ペイントと再ペイントのパフォーマンスを向上します。<code><a href="/ja/docs/Web/HTML/Element/video"><video></a></code> や<code><a href="/ja/docs/Web/HTML/Element/canvas"><canvas></a></code>など、レイヤーを生成する特定のプロパティと要素があります。<a href="/ja/docs/Web/CSS/opacity"><code>opacity</code></a>、3D <code><a href="/ja/docs/Web/CSS/transform">transform</a></code>、<code><a href="/ja/docs/Web/CSS/will-change">will-change</a></code>、その他いくつかの CSS プロパティを持つ要素も同様です。これらのノードは、その子孫が上記の理由でそれ自身のレイヤーを必要とするのでなければ、子孫と一緒に自身のレイヤー上に描画されます。</p> +<p>描画は描画ツリー内の要素をレイヤーに分解します。コンテンツを GPU (CPU 上のメインスレッドの代わりになる) 上のレイヤーに昇格させることで、描画と再描画のパフォーマンスを向上します。<code><a href="/ja/docs/Web/HTML/Element/video"><video></a></code> や<code><a href="/ja/docs/Web/HTML/Element/canvas"><canvas></a></code>など、レイヤーを生成する特定のプロパティと要素があります。<a href="/ja/docs/Web/CSS/opacity"><code>opacity</code></a>、3D <code><a href="/ja/docs/Web/CSS/transform">transform</a></code>、<code><a href="/ja/docs/Web/CSS/will-change">will-change</a></code>、その他いくつかの CSS プロパティを持つ要素も同様です。これらのノードは、その子孫が上記の理由でそれ自身のレイヤーを必要とするのでなければ、子孫と一緒に自身のレイヤー上に描画されます。</p> <p>レイヤーはパフォーマンスを改善しますが、メモリー管理の面ではコストのかかる処理です。そのため、ウェブのパフォーマンス最適化戦略の中で濫用するべきものではありません。</p> -<h3 id="Compositing" name="Compositing">コンポジット</h3> +<h3 id="Compositing">合成</h3> -<p>ドキュメントのセクションが異なるレイヤーに描画されて重なり合う場合、コンテンツをスクリーン上に正しい順番で描画するためにコンポジットが必要になります。</p> +<p>ドキュメントのセクションが異なるレイヤーに描画されて重なり合う場合、コンテンツをスクリーン上に正しい順番で描画するために合成が必要になります。</p> -<p>ページがアセットの読み込みを続ける間もリフローは発生します (後ほど出てくる図を見てください)。リフローは再ペイントと再コンポジットを引き起こします。画像のサイズを指定していた場合リフローは必要ありません。再ペイントが必要なレイヤーのみが再ペイントされ、必要があればコンポジットが行われます。しかし、私たちのサンプルでは画像のサイズを指定しませんでした。画像がサーバーから取得されたとき、レンダリングプロセスはレイアウトステップまで戻り、そこから再開します。</p> +<p>ページがアセットの読み込みを続ける間も再フローは発生します (後ほど出てくる図を見てください)。再フローは再描画と再合成を引き起こします。画像のサイズを指定していた場合再フローは必要ありません。再描画が必要なレイヤーのみが再描画され、必要があれば合成が行われます。しかし、私たちのサンプルでは画像のサイズを指定しませんでした。画像がサーバーから取得されたとき、レンダリングプロセスはレイアウトステップまで戻り、そこから再開します。</p> -<h2 id="Interactivity" name="Interactivity">インタラクティビティ</h2> +<h2 id="Interactivity">操作可能性</h2> -<p>メインスレッドがページのペイントを完了したら「これで終わり」と思うかもしれません。しかし、必ずしもそうとは言えません。読み込み処理が、遅延された <code><a href="/ja/docs/Web/API/GlobalEventHandlers/onload">onload</a></code> イベントの発火により実行される JavaScript を含む場合、メインスレッドがビジー状態となりスクロールやタッチ、その他のインタラクションができない場合があります。</p> +<p>メインスレッドがページの描画を完了したら「これで終わり」と思うかもしれません。しかし、必ずしもそうとは言えません。読み込み処理が、遅延された <code><a href="/ja/docs/Web/API/GlobalEventHandlers/onload">onload</a></code> イベントの発行により実行される JavaScript を含む場合、メインスレッドがビジー状態となりスクロールやタッチ、その他の操作ができない場合があります。</p> -<p>{{glossary('Time to Interactive')}} (TTI) は、DNS ルックアップと SSL コネクション を始める最初のリクエストからページがインタラクティブになるまでどのくらい時間がかかったかを示す測定値です。インタラクティブであるとは、ページがユーザーのインタラクションに 50ms 以内に応答する {{glossary('First Contentful Paint')}} の後の時点を言います。メインスレッドがパース処理、コンパイル、JavaScript の実行に占有されている場合、ユーザーのインタラクションにタイムリーに (50ms より早く) 応答することができません。</p> +<p>{{glossary('Time to Interactive')}} (TTI) は、DNS ルックアップと SSL コネクション を始める最初のリクエストからページが操作可能になるまでどのくらい時間がかかったかを示す測定値です。操作可能であるとは、ページがユーザーの操作に 50ms 以内に応答する {{glossary('First Contentful Paint')}} の後の時点を言います。メインスレッドがパース処理、コンパイル、JavaScript の実行に占有されている場合、ユーザーの操作にタイムリーに (50ms より早く) 応答することができません。</p> <p>以下の例では、画像の読み込みは高速かもしれませんが、<code>anotherscript.js</code> ファイルが 2MB あり、しかもユーザーのネットワークは低速です。このケースでは、ユーザーはページのコンテンツをすぐに見ることができるかもしれませんが、スクリプトがダウンロードされるまでスクロールを実行できない可能性があります。これは良いユーザー体験とは言えません。この WebPageTest の例からわかるように、メインスレッドを占有することは避けなければいけません。</p> -<p><img alt="The main thread is occupied by the downloading, parsing and execution of a javascript file - over a fast connection" src="https://mdn.mozillademos.org/files/16760/visa_network.png" style="height: 699px; width: 1200px;"></p> +<p><img alt="メインスレッドは javascript ファイルのダウンロード、解析、実行で占められています (高速接続時)。" src="visa_network.png"></p> <p>この例では、DOM コンテンツの読み込みプロセスは 1.5 秒以上かかっており、メインスレッドがすべての時間を完全に占有され、クリックイベントや画面のタップに応答できなくなっています。</p> -<h2 id="See_Also" name="See_Also">関連情報</h2> +<h2 id="See_Also">関連情報</h2> <ul> <li><a href="/ja/docs/Web/Performance">ウェブパフォーマンス</a></li> diff --git a/files/ja/web/performance/index.html b/files/ja/web/performance/index.html index 112430b6e7..7dc01e2657 100644 --- a/files/ja/web/performance/index.html +++ b/files/ja/web/performance/index.html @@ -17,79 +17,79 @@ tags: - Web Performance translation_of: Web/Performance --- -<p><span class="seoSummary">ウェブパフォーマンスは客観的な測定値であり、読み込み時間とランタイムに関するユーザーエクスペリエンスの認知度です。ウェブパフォーマンスとは、サイトが読み込まれ、対話や応答ができるようになるまでの時間と、ユーザーとの対話中にコンテンツがどの程度スムーズになるかです </span>- スクロールはスムーズですか？ ボタンはクリック可能ですか？ ポップアップはすばやく開くことができますか？ また、ポップアップはスムーズに動作しますか？ウェブパフォーマンスには、読み込み時間、 1 秒あたりのフレーム数、対話時間までの客観的な測定値と、コンテンツの読み込みに要した時間の主観的な経験の両方が含まれます。</p> +<p><span class="seoSummary">ウェブパフォーマンスは客観的な測定値と、読み込み時や実行時のユーザーエクスペリエンスの知覚状況から成ります。ウェブパフォーマンスとは、サイトが読み込まれるまでの時間、操作可能・応答可能になるまでの時間、そしてユーザーが操作する際のコンテンツのスムーズさを意味します。</span>スクロールはスムーズか、ボタンはクリックしやすいか、ポップアップはすぐに読み込まれて表示されるか、表示の際にスムーズにアニメーションするか。ウェブパフォーマンスには、読み込み時間、 1 秒あたりのフレーム数、操作可能になるまでの時間などの客観的な測定値と、コンテンツが読み込まれるまでにどのくらいの時間がかかったように感じたかという主観的な体験の両方が含まれます。</p> -<p>サイトが応答するまでの時間が長ければ長いほど、ユーザーはそのサイトを放棄することになります。読み込み時間と応答時間を最小限に抑え、さらに機能を追加して遅延を隠すことで、できるだけ早く、できるだけ利用可能でインタラクティブな体験を提供し、一方で、体験のロングテール部分では非同期的に読み込みを行うことが重要です。</p> +<p>サイトが応答するまでの時間が長ければ長いほど、ユーザーはそのサイトを放棄する傾向があります。読み込み時間と応答時間を最小限に抑え、さらに機能を追加して遅延を隠すことで、できるだけ早く、できるだけ利用可能でインタラクティブな体験を提供し、一方で、体験のロングテール部分では非同期的に読み込みを行うことが重要です。</p> -<p>ウェブパフォーマンスの測定と改善に役立つツール、API、およびベストプラクティスがあります。 このセクションでそれらをカバーします。</p> +<p>ウェブパフォーマンスの測定と改善に役立つツール、API、およびベストプラクティスがあります。 この章でそれらをカバーします。</p> -<h2 id="Key_performance_guides">Key performance guides</h2> +<h2 id="Key_performance_guides">キーパフォーマンスガイド</h2> <p>{{LandingPageListSubpages}}</p> <div class="cleared topicpage-table"> <div class="section"> -<h2 id="Beginners_tutorials">Beginner's tutorials</h2> +<h2 id="Beginners_tutorials">初心者向けチュートリアル</h2> -<p>The MDN <a href="/en-US/docs/Learn/Performance">Web Performance Learning Area</a> contains modern, up-to-date tutorials covering Performance essentials. Start here if you are a newcomer to performance:</p> +<p>MDN の<a href="/ja/docs/Learn/Performance">ウェブパフォーマンスの学習領域</a>には、パフォーマンスの基礎をカバーする最新のチュートリアルが含まれています。パフォーマンスについての初心者は、ここから始めてください。</p> <dl> - <dt><a href="/en-US/docs/Learn/Performance/What_is_web_performance">Web performance: brief overview</a></dt> - <dd>Overview of the web performance learning path. Start your journey here.</dd> - <dt><a href="/en-US/docs/Learn/Performance/What_is_web_performance">What is web performance?</a></dt> - <dd>This article starts the module off with a good look at what performance actually is — this includes the tools, metrics, APIs, networks, and groups of people we need to consider when thinking about performance, and how we can make performance part of our web development workflow.</dd> - <dt><a href="/en-US/docs/Learn/Performance/Perceived_performance">How do users perceive performance?</a></dt> + <dt><a href="/ja/docs/Learn/Performance/What_is_web_performance">ウェブパフォーマンス: 短い概要</a></dt> + <dd>ウェブパフォーマンスの学習経路の概要です。ここから旅を始めましょう。</dd> + <dt><a href="/ja/docs/Learn/Performance/What_is_web_performance">ウェブパフォーマンスとは</a></dt> + <dd>この記事では、パフォーマンスとは何かをよく理解することからモジュールを始めます。パフォーマンスについて考えるときに考慮すべきツール、指標、API、ネットワーク、人々のグループ、そしてウェブ開発のワークフローの一部としてパフォーマンスを活用する方法などを紹介します。</dd> + <dt><a href="/ja/docs/Learn/Performance/perceived_performance">ユーザーはパフォーマンスをどう知覚するのか</a></dt> <dd> - <p>More important than how fast your website is in milliseconds, is how fast your users perceive your site to be. These perceptions are impacted by actual p<span style="letter-spacing: -0.00278rem;">age load time, idling, responsiveness to user interaction, and the smoothness of scrolling and other animations. In this article, we discuss the various loading metrics, animation, and responsiveness metrics, along with best practices to improve user perception, if not the actual timings.</span></p> + <p>ウェブサイトの速さをミリ秒単位で示すことよりも重要なのは、ユーザーがサイトの速さをどのように認識しているかということです。これらの認識は、実際のページロード時間、アイドリング、ユーザーインタラクションへの応答性、スクロールやその他のアニメーションのスムーズさに影響されます。この記事では、様々なロードメトリクス、アニメーション、応答性のメトリクスと、実際の時間ではなくてもユーザーの認識を改善するためのベストプラクティスについて説明します。</p> </dd> - <dt><a href="/en-US/docs/Learn/Performance/Web_Performance_Basics">Web performance basics</a></dt> - <dd>In addition to the front end components of HTML, CSS, JavaScript, and media files, there are features that can make applications slower and features that can make applications subjectively and objectively faster. There are many APIs, developer tools, best practices, and bad practices relating to web performance. Here we'll introduce many of these features ad the basic level and provide links to deeper dives to improve performance for each topic.</dd> - <dt><a href="/en-US/docs/Learn/Performance/HTML">HTML performance features</a></dt> - <dd>Some attributes and the source order of your mark-up can impact the performance or your website. By minimizing the number of DOM nodes, making sure the best order and attributes are used for including content such as styles, scripts, media, and third-party scripts, you can drastically improve the user experience. This article looks in detail at how HTML can be used to ensure maximum performance.</dd> - <dt><a href="/en-US/docs/Learn/Performance/Multimedia">Multimedia: images and video</a></dt> - <dd>The lowest hanging fruit of web performance is often media optimization. Serving different media files based on each user agent's capability, size, and pixel density is possible. Additional tips like removing audio tracks from background videos can improve performance even further. In this article we discuss the impact video, audio, and image content has on performance, and the methods to ensure that impact is as minimal as possible.</dd> - <dt><a href="/en-US/docs/Learn/Performance/CSS">CSS performance features</a></dt> - <dd>CSS may be a less important optimization focus for improved performance, but there are some CSS features that impact performance more than others. In this article we look at some CSS properties that impact performance and suggested ways of handling styles to ensure performance is not negatively impacted.</dd> - <dt><a href="/en-US/docs/Learn/Performance/JavaScript">JavaScript performance best practices</a></dt> - <dd>JavaScript, when used properly, can allow for interactive and immersive web experiences — or it can significantly harm download time, render time, in-app performance, battery life, and user experience. This article outlines some JavaScript best practices that should be considered to ensure even complex content is as performant as possible.</dd> - <dt><a href="/en-US/docs/Learn/Performance/Mobile">Mobile performance</a></dt> - <dd>With web access on mobile devices being so popular, and all mobile platforms having fully-fledged web browsers, but possibly limited bandwidth, CPU and battery life, it is important to consider the performance of your web content on these platforms. This article looks at mobile-specific performance considerations.</dd> + <dt><a href="/ja/docs/Learn/Performance/Web_Performance_Basics">ウェブパフォーマンスの基本</a></dt> + <dd>HTML、CSS、JavaScript、メディアファイルなどのフロントエンド部品に加えて、アプリケーションを遅くする機能と、主観的・客観的にアプリケーションを速くする機能があります。ウェブパフォーマンスに関連する API、開発者ツール、ベストプラクティス、バッドプラクティスは数多くあります。ここでは、これらの機能の多くを基本的なレベルで紹介し、それぞれのトピックについて、パフォーマンスを向上させるためのより深い考察へのリンクを提供します。</dd> + <dt><a href="/ja/docs/Learn/Performance/HTML">HTML のパフォーマンス特性</a></dt> + <dd>マークアップの属性やソースの順序によっては、ウェブサイトのパフォーマンスに影響を与えることがあります。 DOM ノードの数を最小限に抑え、スタイル、スクリプト、メディア、サードパーティのスクリプトなどのコンテンツを含むために、最適な順序と属性を使用することで、ユーザーエクスペリエンスを劇的に向上させることができます。この記事では、最大限のパフォーマンスを確保するために HTML をどのように使用すればよいかを詳しく見ていきます。</dd> + <dt><a href="/ja/docs/Learn/Performance/Multimedia">マルチメディア: 画像と動画</a></dt> + <dd>ウェブパフォーマンスの中で最も身近な位置にあるのは、メディアの最適化です。各ユーザーエージェントの能力、サイズ、ピクセル密度に応じて、異なるメディアファイルを提供することが可能です。また、バックグラウンドのビデオからオーディオトラックを削除するなどのヒントを加えると、さらにパフォーマンスが向上します。この記事では、動画、音声、画像のコンテンツがパフォーマンスに与える影響と、その影響をできるだけ小さくするための方法について説明します。</dd> + <dt><a href="/ja/docs/Learn/Performance/CSS">CSS パフォーマンス特性</a></dt> + <dd>CSS は、パフォーマンス向上のための最適化の焦点としてはあまり重要ではないかもしれませんが、パフォーマンスに影響を与える CSS の機能はいくつかあります。この記事では、パフォーマンスに影響を与えるいくつかの CSS プロパティと、パフォーマンスに悪影響を与えないためのスタイルの処理方法を提案します。</dd> + <dt><a href="/ja/docs/Learn/Performance/JavaScript">JavaScript パフォーマンスのベストプラクティス</a></dt> + <dd>JavaScript は、適切に使用すればインタラクティブで没入感のあるウェブ体験を実現できますが、ダウンロード時間、レンダリング時間、アプリ内のパフォーマンス、バッテリー寿命、ユーザーエクスペリエンスを大きく損なう可能性があります。この記事では、複雑なコンテンツであっても可能な限りパフォーマンスを向上させるために考慮すべき JavaScript のベストプラクティスを紹介します。</dd> + <dt><a href="/ja/docs/Learn/Performance/Mobile">モバイルパフォーマンス</a></dt> + <dd>モバイル端末でのウェブアクセスは非常に人気があり、すべてのモバイルプラットフォームには本格的なウェブブラウザーが搭載されていますが、帯域幅、CPU、バッテリーの寿命が限られている可能性があるため、これらのプラットフォームでのウェブコンテンツのパフォーマンスを考慮することが重要です。この記事では、モバイルに特化したパフォーマンスの考慮点について説明します。</dd> </dl> </div> <div class="section"> -<h2 id="Using_Performance_APIs">Using Performance APIs</h2> +<h2 id="Using_Performance_APIs">パフォーマンス API の使用</h2> <dl> - <dt><a href="/en-US/docs/Web/API/Performance_API/Using_the_Performance_API">Performance API</a></dt> - <dd>This guide describes how to use the <a href="/en-US/docs/Web/API/Performance" title="The Performance interface provides access to performance-related information for the current page. It's part of the High Resolution Time API, but is enhanced by the Performance Timeline API, the Navigation Timing API, the User Timing API, and the Resource Timing API."><code>Performance</code></a> interfaces that are defined in the <a class="external external-icon" href="https://w3c.github.io/hr-time/" rel="noopener">High-Resolution Time</a> standard.</dd> - <dt><a href="/en-US/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API">Resource Timing API</a></dt> - <dd><a href="/en-US/docs/Web/API/Resource_Timing_API">Resource loading and timing</a> the loading of those resources, including managing the resource buffer and coping with CORS</dd> - <dt><a href="/en-US/docs/Web/API/Performance_Timeline/Using_Performance_Timeline">The performance timeline</a></dt> - <dd>The <a href="/en-US/docs/Web/API/Performance_Timeline">Performance Timeline</a> standard defines extensions to the <a href="/en-US/docs/Web/API/Performance" title="The Performance interface provides access to performance-related information for the current page. It's part of the High Resolution Time API, but is enhanced by the Performance Timeline API, the Navigation Timing API, the User Timing API, and the Resource Timing API."><code>Performance</code></a> interface to support client-side latency measurements within applications. Together, these interfaces can be used to help identify an application's performance bottlenecks.</dd> - <dt><a href="/en-US/docs/Web/API/User_Timing_API/Using_the_User_Timing_API">User Timing API</a></dt> - <dd>Create application specific timestamps using the <a href="/en-US/docs/Web/API/User_Timing_API">user timing API</a>'s "mark" and "measure" entry types - that are part of the browser's performance timeline.</dd> - <dt><a href="/en-US/docs/Web/API/Frame_Timing_API/Using_the_Frame_Timing_API">Frame Timing API</a></dt> - <dd>The <code><a href="/en-US/docs/Web/API/PerformanceFrameTiming">PerformanceFrameTiming</a></code> interface provides <em>frame</em> timing data about the browser's event loop.</dd> - <dt><a href="/en-US/docs/Web/API/Beacon_API">Beacon API</a></dt> - <dd><small>The <a href="/en-US/docs/Web/API/Beacon_API">Beacon</a> interface schedules an asynchronous and non-blocking request to a web server.</small></dd> - <dt><a href="/en-US/docs/Web/API/Intersection_Observer_API/Timing_element_visibility">Intersection Observer API</a></dt> - <dd>Learn to time element visibility with the <a href="/en-US/docs/Web/API/Intersection_Observer_API">Intersection Observer API</a> and be asynchronously notified when elements of interest becomes visible.</dd> + <dt><a href="/ja/docs/Web/API/Performance_API/Using_the_Performance_API">Performance API</a></dt> + <dd>このガイドでは、 <a href="/ja/docs/Web/API/Performance" title="Performance インターフェイスは、現在のページのパフォーマンス関連情報へのアクセスを提供します。これは、 High Resolution Time API の一部ですが、Performance Timeline API、Navigation Timing API、User Timing API、Resource Timing API によって拡張されています。"><code>Performance</code></a> インターフェイスの使い方を説明します。これは <a class="external external-icon" href="https://w3c.github.io/hr-time/" rel="noopener">High-Resolution Time</a> 標準で定義されているものです。</dd> + <dt><a href="/ja/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API">Resource Timing API</a></dt> + <dd><a href="/ja/docs/Web/API/Resource_Timing_API">リソースの読み込みとそのタイミング</a>です。リソースバッファの管理や CORS への対応なども含みます。</dd> + <dt><a href="/ja/docs/Web/API/Performance_Timeline/Using_Performance_Timeline">パフォーマンスタイムライン</a></dt> + <dd><a href="/ja/docs/Web/API/Performance_Timeline">Performance Timeline</a> 標準は、アプリケーション内のクライアントサイドのレイテンシー測定をサポートする <a href="/ja/docs/Web/API/Performance" title="Performance インターフェイスは、現在のページのパフォーマンス関連情報へのアクセスを提供します。これは、 High Resolution Time API の一部ですが、Performance Timeline API、Navigation Timing API、User Timing API、Resource Timing API によって拡張されています。"><code>Performance</code></a> インターフェイスの拡張機能を定義しています。これらのインターフェイスを併用することで、アプリケーションのパフォーマンスのボトルネックを特定するのに役立ちます。</dd> + <dt><a href="/ja/docs/Web/API/User_Timing_API/Using_the_User_Timing_API">User Timing API</a></dt> + <dd>アプリケーション固有のタイムスタンプを生成するために、 <a href="/ja/docs/Web/API/User_Timing_API">user timing API</a> の "mark" および "measure" の種類の項目を使用します。これらはブラウザーのパフォーマンスタイムラインの一部です。</dd> + <dt><a href="/ja/docs/Web/API/Frame_Timing_API/Using_the_Frame_Timing_API">Frame Timing API</a></dt> + <dd><code><a href="/ja/docs/Web/API/PerformanceFrameTiming">PerformanceFrameTiming</a></code> インターフェイスは、ブラウザーのイベントループに関する<em>フレーム</em>のタイミングデータを提供します。</dd> + <dt><a href="/ja/docs/Web/API/Beacon_API">Beacon API</a></dt> + <dd><a href="/ja/docs/Web/API/Beacon_API">Beacon</a> インターフェイスは、ウェブサーバーへの非同期かつブロックされないリクエストをスケジューリングします。</dd> + <dt><a href="/ja/docs/Web/API/Intersection_Observer_API/Timing_element_visibility">Intersection Observer API</a></dt> + <dd><a href="/ja/docs/Web/API/Intersection_Observer_API">Intersection Observer API</a> を使って要素が見えるようになることを時間的に測定し、関心のある要素が可視化されたときに非同期に通知を受けることができます。</dd> </dl> -<h2 id="Other_documentation">Other documentation</h2> +<h2 id="Other_documentation">その他の文書</h2> <dl> - <dt><a href="/en-US/docs/Tools/Performance">Developer Tools Performance Features</a></dt> - <dd>This section provides information on how to use and understand the performance features in your developer tools, including <a href="/en-US/docs/Tools/Performance/Waterfall">Waterfall</a>, <a href="/en-US/docs/Tools/Performance/Call_Tree">Call Tree</a>, and <a href="/en-US/docs/Tools/Performance/Flame_Chart">Flame Charts</a>.</dd> - <dt><a href="/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler">Profiling with the built-in profiler</a></dt> + <dt><a href="/ja/docs/Tools/Performance">開発者ツールのパフォーマンス機能</a></dt> + <dd>この節では、<a href="/ja/docs/Tools/Performance/Waterfall">ウォーターフォール</a>、<a href="/ja/docs/Tools/Performance/Call_Tree">コールツリー</a>、<a href="/ja/docs/Tools/Performance/Flame_Chart">フレイムチャート</a>など、開発者ツールのパフォーマンス機能の使い方と理解について説明します。</dd> + <dt><a href="/ja/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler">組み込みプロファイラーによるプロファイル</a></dt> <dd>Learn how to profile app performance with Firefox's built-in profiler.</dd> </dl> </div> </div> -<h2 id="Glossary_Terms">Glossary Terms</h2> +<h2 id="Glossary_Terms">用語集の用語</h2> <div class="index"> <ul class="index"> @@ -145,12 +145,12 @@ translation_of: Web/Performance </ul> </div> -<h2 id="Documents_yet_to_be_written">Documents yet to be written</h2> +<h2 id="Documents_yet_to_be_written">まだ書かれていない文書</h2> <dl> - <dt><a href="/en-US/docs/Learn/Performance/JavaScript">JavaScript performance best practices</a></dt> + <dt><a href="/ja/docs/Learn/Performance/JavaScript">JavaScript performance best practices</a></dt> <dd>JavaScript, when used properly, can allow for interactive and immersive web experiences ... or it can significantly harm download time, render time, in app performance, battery life, and user experience. This article outlines some JavaScript best practices that can ensure even complex content's performance is the highest possible.</dd> - <dt><a href="/en-US/docs/Learn/Performance/Mobile">Mobile performance</a></dt> + <dt><a href="/ja/docs/Learn/Performance/Mobile">Mobile performance</a></dt> <dd>With web access on mobile devices being so popular, and all mobile platforms having fully-fledged web browsers, but possibly limited bandwidth, CPU, and battery life, it is important to consider the performance of your web content on these platforms. This article also looks at mobile-specific performance considerations.</dd> <dt>Web font performance</dt> <dd>An often overlooked aspect of performance landscape are web fonts. Web fonts are more prominent in web design than ever, yet many developers embed them from a third party service and think nothing of it. In this article, we'll covers methods for getting your font files as small as possible with efficient file formats and sub setting. From there, we'll go on to talk about how browsers text, and how you can use CSS and JavaScript features to ensure your fonts render quickly, and with minimal disruption to the user experience.</dd> @@ -161,119 +161,119 @@ translation_of: Web/Performance <dt>The role of TLS in performance</dt> <dd>TLS—or HTTPS as we tend to call it—is crucial in creating secure and safe user experiences. While hardware has reduced the negative impacts TLS has had on server performance, it still represents a substantial slice of the time we spend waiting for browsers to connect to servers. This article explains the TLS handshake process, and offers some tips for reducing this time, such as OCSP stapling, HSTS preload headers, and the potential role of resource hints in masking TLS latency for third parties.</dd> <dt>Reading performance charts</dt> - <dd>Developer tools provide information on performance, memory, and network requests. Knowing how to read <a href="/en-US/docs/Tools/Performance/Waterfall">waterfall</a> charts, <a href="/en-US/docs/Tools/Performance/Call_Tree">call trees</a>, traces, <a href="/en-US/docs/Tools/Performance/Flame_Chart">flame charts</a> , and <a href="/en-US/docs/Tools/Performance/Allocations">allocations</a> in your browser developer tools will help you understand waterfall and flame charts in other performance tools.</dd> + <dd>Developer tools provide information on performance, memory, and network requests. Knowing how to read <a href="/ja/docs/Tools/Performance/Waterfall">waterfall</a> charts, <a href="/ja/docs/Tools/Performance/Call_Tree">call trees</a>, traces, <a href="/ja/docs/Tools/Performance/Flame_Chart">flame charts</a> , and <a href="/ja/docs/Tools/Performance/Allocations">allocations</a> in your browser developer tools will help you understand waterfall and flame charts in other performance tools.</dd> <dt>Alternative media formats</dt> <dd>When it comes to images and videos, there are more formats than you're likely aware of. Some of these formats can take your highly optimized media-rich pages even further by offering additional reductions in file size. In this guide we'll discuss some alternative media formats, how to use them responsibly so that non-supporting browsers don't get left out in the cold, and some advanced guidance on transcoding your existing assets to them.</dd> <dt>Analyzing JavaScript bundles</dt> <dd>No doubt, JavaScript is a big part of modern web development. While you should always strive to reduce the amount of JavaScript you use in your applications, it can be difficult to know where to start. In this guide, we'll show you how to analyze your application's script bundles, so you know <em>what</em> you're using, as well how to detect if your app contains duplicated scripts between bundles.</dd> - <dt><a href="/en-US/docs/Web/Performance/Lazy_loading">Lazy loading</a></dt> + <dt><a href="/ja/docs/Web/Performance/Lazy_loading">Lazy loading</a></dt> <dd>It isn't always necessary to load all of a web applications assets on initial page load. Lazy Loading is deferring the loading of assets on a page, such as scripts, images, etc., on a page to a later point in time i.e when those assets are actually needed.</dd> <dt>Lazy-loading JavaScript with dynamic imports</dt> <dd>When developers hear the term "lazy loading", they immediately think of below-the-fold imagery that loads when it scrolls into the viewport. But did you know you can lazy load JavaScript as well? In this guide we'll talk about the dynamic import() statement, which is a feature in modern browsers that loads a JavaScript module on demand. Of course, since this feature isn't available everywhere, we'll also show you how you can configure your tooling to use this feature in a widely compatible fashion.</dd> - <dt><a href="/en-US/docs/Web/Performance/Controlling_resource_delivery_with_resource_hints">Controlling resource delivery with resource hints</a></dt> + <dt><a href="/ja/docs/Web/Performance/Controlling_resource_delivery_with_resource_hints">Controlling resource delivery with resource hints</a></dt> <dd>Browsers often know better than we do when it comes to resource prioritization and delivery however they're far from clairyovant. Native browser features enable us to hint to the browser when it should connect to another server, or preload a resource before the browser knows it ever needs it. When used judiciously, this can make fast experience seem even faster. In this article, we cover native browser features like rel=preconnect, rel=dns-prefetch, rel=prefetch, and rel=preload, and how to use them to your advantage.</dd> - <dt><a href="/en-US/docs/Web/Performance/Performance_budgets">Performance Budgets</a></dt> + <dt><a href="/ja/docs/Web/Performance/Performance_budgets">Performance Budgets</a></dt> <dd>Marketing, design, and sales needs, and developer experience, often ad bloat, third-party scripts, and other features that can slow down web performance. To help set priorities, it is helpful to set a performance budget: a set of restrictions to not exceed during the development phase. In this article, we'll discuss creating and sticking to a performance budget. </dd> - <dt><a href="/en-US/docs/Web/Performance/Checklist">Web performance checklist</a></dt> + <dt><a href="/ja/docs/Web/Performance/Checklist">Web performance checklist</a></dt> <dd>A performance checklist of features to consider when developing applications with links to tutorials on how to implement each feature, include service workers, diagnosing performance problems, font loading best practices, client hints, creating performant animations, etc.</dd> - <dt><a href="/en-US/docs/Web/Performance/Mobile_performance_checklist">Mobile performance checklist</a></dt> + <dt><a href="/ja/docs/Web/Performance/Mobile_performance_checklist">Mobile performance checklist</a></dt> <dd>A concise checklist of performance considerations impacting mobile network users on hand-held, battery operated devices.</dd> </dl> -<h2 id="See_also">See also</h2> +<h2 id="See_also">関連情報</h2> <p>HTML</p> <ul> - <li><a href="/en-US/docs/Web/HTML/Element/picture">The <code><picture></code> Element</a></li> - <li><a href="/en-US/docs/Web/HTML/Element/video">The <code><video></code> Element</a></li> - <li><a href="/en-US/docs/Web/HTML/Element/source">The <code><source></code> Element</a></li> - <li><a href="/en-US/docs/Web/HTML/Element/img#attributes">The <code><img> srcset</code> attribute</a> + <li><a href="/ja/docs/Web/HTML/Element/picture"><code><picture></code> 要素</a></li> + <li><a href="/ja/docs/Web/HTML/Element/video"><code><video></code> 要素</a></li> + <li><a href="/ja/docs/Web/HTML/Element/source"><code><source></code> 要素</a></li> + <li><a href="/ja/docs/Web/HTML/Element/img#attributes"><code><img> srcset</code> 属性</a> <ul> - <li><a href="/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">Responsive images</a></li> + <li><a href="/ja/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">レスポンシブ画像</a></li> </ul> </li> - <li><a href="/en-US/docs/Web/HTML/Preloading_content">Preloading content with <code>rel="preload"</code></a> - <a href="https://w3c.github.io/preload/">(https://w3c.github.io/preload/ </a>)</li> + <li><a href="/ja/docs/Web/HTML/Link_types/preload"><code>rel="preload"</code> によるコンテンツの先読み</a> - <a href="https://w3c.github.io/preload/">(https://w3c.github.io/preload/ </a>)</li> </ul> <p>CSS</p> <ul> - <li><a href="/en-US/docs/Web/CSS/will-change">will-change</a></li> + <li><a href="/ja/docs/Web/CSS/will-change">will-change</a></li> <li>GPU v CPU</li> - <li>Measuring layout</li> - <li>Font-loading best practices</li> + <li>レイアウトの測定</li> + <li>フォント読み込みのベストプラクティス</li> </ul> <p>JavaScript</p> <ul> - <li><a href="/en-US/docs/Web/API/Window/DOMContentLoaded_event">DOMContentLoaded</a></li> - <li><a href="/en-US/docs/Glossary/Garbage_collection">Garbage collection</a></li> - <li><a href="/en-US/docs/Web/API/window/requestAnimationFrame">requestAnimationFrame</a></li> + <li><a href="/ja/docs/Web/API/Window/DOMContentLoaded_event">DOMContentLoaded</a></li> + <li><a href="/ja/docs/Glossary/Garbage_collection">ガベージコレクション</a></li> + <li><a href="/ja/docs/Web/API/Window/requestAnimationFrame">requestAnimationFrame</a></li> </ul> -<p>APIs</p> +<p>API</p> <ul> - <li><a href="/en-US/docs/Web/API/Performance_API">Performance API</a></li> - <li><a href="/en-US/docs/Web/API/Navigation_timing_API">Navigation Timing API</a></li> - <li><a href="/en-US/docs/Web/API/Media_Capabilities_API/Using_the_Media_Capabilities_API">Media Capabilities API</a></li> - <li><a href="/en-US/docs/Web/API/Network_Information_API">Network Information API</a></li> - <li><a href="/en-US/docs/Web/API/PerformanceNavigationTiming">PerformanceNavigationTiming</a></li> - <li><a href="/en-US/docs/Web/API/Battery_Status_API">Battery Status API</a></li> - <li><a href="/en-US/docs/Web/API/Navigator/deviceMemory">Navigator.deviceMemory</a></li> - <li><a href="/en-US/docs/Web/API/Intersection_Observer_API">Intersection Observer</a></li> - <li><a href="/en-US/docs/Web/API/User_Timing_API/Using_the_User_Timing_API">Using the User Timing AP</a>I</li> - <li><a href="/en-US/docs/Web/API/Long_Tasks_API">Long Tasks API</a></li> - <li><a href="/en-US/docs/Web/API/DOMHighResTimeStamp">High Resolution Timing API</a> (<a href="https://w3c.github.io/hr-time/">https://w3c.github.io/hr-time/)</a></li> - <li><a href="/en-US/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API">Resource Timing API</a></li> - <li><a href="/en-US/docs/Web/API/Page_Visibility_API">Page Visibility</a></li> - <li><a href="/en-US/docs/Web/API/Background_Tasks_API">Cooperative Scheduling of Background Tasks API</a> + <li><a href="/ja/docs/Web/API/Performance_API">Performance API</a></li> + <li><a href="/ja/docs/Web/API/Navigation_timing_API">Navigation Timing API</a></li> + <li><a href="/ja/docs/Web/API/Media_Capabilities_API/Using_the_Media_Capabilities_API">Media Capabilities API</a></li> + <li><a href="/ja/docs/Web/API/Network_Information_API">Network Information API</a></li> + <li><a href="/ja/docs/Web/API/PerformanceNavigationTiming">PerformanceNavigationTiming</a></li> + <li><a href="/ja/docs/Web/API/Battery_Status_API">Battery Status API</a></li> + <li><a href="/ja/docs/Web/API/Navigator/deviceMemory">Navigator.deviceMemory</a></li> + <li><a href="/ja/docs/Web/API/Intersection_Observer_API">Intersection Observer</a></li> + <li><a href="/ja/docs/Web/API/User_Timing_API/Using_the_User_Timing_API">Using the User Timing API</a></li> + <li><a href="/ja/docs/Web/API/Long_Tasks_API">Long Tasks API</a></li> + <li><a href="/ja/docs/Web/API/DOMHighResTimeStamp">High Resolution Timing API</a> (<a href="https://w3c.github.io/hr-time/">https://w3c.github.io/hr-time/)</a></li> + <li><a href="/ja/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API">Resource Timing API</a></li> + <li><a href="/ja/docs/Web/API/Page_Visibility_API">Page Visibility</a></li> + <li><a href="/ja/docs/Web/API/Background_Tasks_API">Background Tasks API の協調スケジューリング</a> <ul> - <li style="margin-top: 0.25em;"><a href="/en-US/docs/Web/API/Window/requestIdleCallback">requestIdleCallback() </a></li> + <li><a href="/ja/docs/Web/API/Window/requestIdleCallback">requestIdleCallback()</a></li> </ul> </li> - <li><a href="/en-US/docs/Web/API/Beacon_API">Beacon API</a></li> - <li>Resource Hints - <a href="/en-US/docs/Web/HTTP/Headers/X-DNS-Prefetch-Control">dns-prefetch</a>, preconnect, <a href="/en-US/docs/Web/HTTP/Link_prefetching_FAQ">prefetch</a>, and prerender</li> - <li><a href="/en-US/docs/Web/API/FetchEvent/navigationPreload">Fetchevent.navigationPreload</a></li> - <li><a href="/en-US/docs/Web/API/PerformanceServerTiming">Performance Server Timing API</a></li> + <li><a href="/ja/docs/Web/API/Beacon_API">Beacon API</a></li> + <li>リソースのヒント - <a href="/ja/docs/Web/HTTP/Headers/X-DNS-Prefetch-Control">dns-prefetch</a>, preconnect, <a href="/ja/docs/Web/HTTP/Link_prefetching_FAQ">prefetch</a>, prerender</li> + <li><a href="/ja/docs/Web/API/FetchEvent/PreloadResponse">FetchEvent.preloadResponse</a></li> + <li><a href="/ja/docs/Web/API/PerformanceServerTiming">Performance Server Timing API</a></li> </ul> -<p>Headers</p> +<p>ヘッダー</p> <ul> - <li><a href="/en-US/docs/Web/HTTP/Headers/Content-Encoding">Content-encoding</a></li> + <li><a href="/ja/docs/Web/HTTP/Headers/Content-Encoding">Content-encoding</a></li> <li>HTTP/2</li> - <li><a href="/en-US/docs/Glossary/GZip_compression">gZip</a></li> - <li>Client Hints</li> + <li><a href="/ja/docs/Glossary/GZip_compression">gZip</a></li> + <li>クライアントヒント</li> </ul> -<p>Tools</p> +<p>ツール</p> <ul> - <li><a href="/en-US/docs/Tools/Performance">Performance in Firefox Developer Tools</a></li> - <li>Flame charts</li> - <li>The Network panel</li> - <li>Waterfall charts</li> + <li><a href="/ja/docs/Tools/Performance">Firefox 開発者ツールのパフォーマンス</a></li> + <li>フレイムチャート</li> + <li>ネットワークパネル</li> + <li>ウォーターフォールチャート</li> </ul> -<p>Additional Metrics</p> +<p>その他の指標</p> <ul> - <li>Speed Index and Perceptual Speed Index</li> + <li>スピードインデックスと知覚的スピードインデックス</li> </ul> -<p>Best Practices</p> +<p>ベストプラクティス</p> <ul> - <li><a href="/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers">Using Service Workers</a></li> - <li><a href="/en-US/docs/Web/API/Web_Workers_API/Using_web_workers">Using Web Workers</a> + <li><a href="/ja/docs/Web/API/Service_Worker_API/Using_Service_Workers">サービスワーカーの使用</a></li> + <li><a href="/ja/docs/Web/API/Web_Workers_API/Using_web_workers">ウェブワーカーの使用</a> <ul> - <li><a href="/en-US/docs/Web/API/Web_Workers_API">Web Workers API</a></li> + <li><a href="/ja/docs/Web/API/Web_Workers_API">Web Workers API</a></li> </ul> </li> - <li><a href="/en-US/docs/Web/Progressive_web_apps/Offline_Service_workers">PWA</a></li> - <li><a href="/en-US/docs/Web/HTTP/Caching">Caching</a></li> - <li>Content Delivery Networks (CDN)</li> + <li><a href="/ja/docs/Web/Progressive_web_apps/Offline_Service_workers">PWA</a></li> + <li><a href="/ja/docs/Web/HTTP/Caching">キャッシュ</a></li> + <li>コンテンツ配信ネットワーク (CDN)</li> </ul> |