initial commit

2 files changed, 433 insertions, 0 deletions

diff --git a/files/ja/web/performance/how_browsers_work/index.html b/files/ja/web/performance/how_browsers_work/index.html
new file mode 100644
index 0000000000..3e5ce9b20b
--- /dev/null
+++ b/files/ja/web/performance/how_browsers_work/index.html
@@ -0,0 +1,216 @@
+---
+title: ページの生成：ブラウザーはどのように動作するか
+slug: Web/Performance/How_browsers_work
+tags:
+  - Browsers
+  - Compositing
+  - Critical rendering path
+  - DNS Lookup
+  - Navigation
+  - Page load
+  - Painting
+  - SSL/TLS Handshake
+  - TCP handshake
+  - Web Performance
+  - render
+translation_of: Web/Performance/How_browsers_work
+---
+<p>ユーザーは、読み込みが速く、スムーズにインタラクションできるコンテンツを、ウェブで体験することを求めています。したがって、<span class="seoSummary">開発者はこれらふたつの目標を達成するために努力しなければいけません。</span></p>
+
+<p><span class="seoSummary">どうやって性能そして体感性能を改善するか理解するためには、ブラウザーがどのように動作するかを理解することが役に立ちます。</span></p>
+
+<h2 id="Overview" name="Overview">概要</h2>
+
+<p>速いサイトはより良いユーザー体験をもたらします。ユーザーは読み込みが速く、スムーズにインタラクションできるコンテンツを体験することを求め、期待しています。</p>
+
+<p>ウェブの性能における 2 つの主要な課題は、レイテンシーに関する諸問題と、多くの場合ブラウザーはシングルスレッドであるという事実に関する諸問題を理解することです。</p>
+
+<p>レイテンシーは、速い読み込みを実現するために克服しなければいけない一番の脅威です。読み込みを速くしようとする開発者のゴールは、リクエストされた情報をできる限り速く送信すること、または少なくともとても速いように見せることです。ネットワークのレイテンシーは、バイト情報をコンピューターまで送信するのにかかる時間のことです。ウェブの性能は、ページの読み込みを出来る限り速くするよう私たちが何をするかにかかっています。</p>
+
+<p>多くの場合、ブラウザーはシングルスレッドだと考えられます。スムーズなインタラクションを実現しようとする開発者のゴールは、滑らかなスクロール、タッチ操作への反応など、期待通りのサイトのインタラクションを実現することです。メインスレッドが全ての処理を時間内に完了し、その上でユーザーのインタラクションを常にハンドリングできるよう保証するために、描画時間が鍵となります。ブラウザーがシングルスレッドであることによる特性を理解し、メインスレッドの責務を最小限に抑え、可能かつ適切な場合に、描画のスムーズさとインタラクションへの即時の反応を実現することで、ウェブの性能が改善されます。</p>
+
+<h2 id="Navigation" name="Navigation">ナビゲーション</h2>
+
+<p><em>ナビゲーション</em>はウェブページを読み込むための最初の一歩です。ユーザーが URL をアドレスバーに入力したり、リンクをクリックしたり、またはフォームを送信したり、ページをリクエストするたびごとにナビゲーションが発生します。</p>
+
+<p>ウェブの性能における目標の 1 つは、ナビゲーションが完了するまでの時間を最小限にすることです。理想的な条件下において、一般的にこの時間が長すぎることはありませんが、レイテンシーと帯域幅が遅延を引き起こす邪魔者になる場合があります。</p>
+
+<h3 id="DNS_Lookup" name="DNS_Lookup">DNS ルックアップ</h3>
+
+<p>ウェブページへのナビゲーションの最初の一歩は、ページのアセットがどこにあるか見つけることです。<code>https://example.com</code> へアクセスする場合、その HTML のページは IP アドレスが <code>93.184.216.34</code> のサーバーに存在します。これまでに一度もそのサイトを訪れたことがなかった場合、DNS ルックアップが必要になります。</p>
+
+<p>ブラウザーが DNS ルックアップをリクエストし、そのリクエストは最終的にネームサーバーによって処理され、ネームサーバーが IP アドレスを返します。この最初のリクエストの後、多くの場合その IP アドレスはしばらくの間キャッシュされ、ネームサーバーへ再接続する代わりにキャッシュから IP アドレスを取得することによって、後続するリクエストの速度を向上します。</p>
+
+<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>これはとくにモバイルネットワークにおいて性能上の問題になる可能性があります。ユーザーがモバイルネットワークを利用している場合、DNS ルックアップは、権威 DNS サーバーへ到達するために、電話機から基地局へ送信される必要があります。電話機と基地局、そしてネームサーバー間の距離によって重大な遅延が発生する場合があります。</p>
+
+<h3 id="TCP_Handshake" name="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>
+
+<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>通信を安全にするためにページ読み込みの時間が追加されますが、ブラウザーとサーバーの間で送信されるデータが第三者に解読されないという安全な通信は、レイテンシーに見合う価値があるものです。</p>
+
+<p>8 回のラウンドトリップを経て、ブラウザーはようやくリクエストを送ることができます。</p>
+
+<h2 id="Response" name="Response">レスポンス</h2>
+
+<p>ウェブサーバーへのコネクションが確立されると、ブラウザーはユーザーに代わって最初の <a href="/ja/docs/Web/HTTP/Methods">HTTP <code>GET</code> リクエスト</a>を送信します。ウェブサイトであれば、多くの場合その対象は HTML ファイルです。リクエストを受け取ったサーバーは、適当なレスポンスヘッダーと HTML のコンテンツを返します。</p>
+
+<pre class="brush: html">&lt;!doctype HTML&gt;
+&lt;html&gt;
+ &lt;head&gt;
+  &lt;meta charset="UTF-8"/&gt;
+  &lt;title&gt;My simple page&lt;/title&gt;
+  &lt;link rel="stylesheet" src="styles.css"/&gt;
+  &lt;script src="myscript.js"&gt;&lt;/script&gt;
+&lt;/head&gt;
+&lt;body&gt;
+  &lt;h1 class="heading"&gt;My Page&lt;/h1&gt;
+  &lt;p&gt;A paragraph with a &lt;a href="https://example.com/about"&gt;link&lt;/a&gt;&lt;/p&gt;
+  &lt;div&gt;
+    &lt;img src="myimage.jpg" alt="image description"/&gt;
+  &lt;/div&gt;
+  &lt;script src="anotherscript.js"&gt;&lt;/script&gt;
+&lt;/body&gt;
+&lt;/html&gt;</pre>
+
+<p>この最初のリクエストへのレスポンスは、受信データの最初のバイト (First Byte) を含んでいます。{{glossary('Time to First Byte')}} (TTFB) は、ユーザーがリクエストを実行した時点から—たとえば、リンクをクリックした時点から— HTML の最初のパケットを受信するまでの時間を表します。コンテンツの最初のかたまり (Chunk) は一般的に 14kB のデータです。</p>
+
+<p>上記のサンプルコードでは、リクエストされたコンテンツは明らかに 14kB より小さいですが、後述するように、リンクされたリソースは、ブラウザーのパース処理がそのリンクにたどり着くまでリクエストされることはありません。</p>
+
+<h3 id="TCP_Slow_Start_14kb_rule" name="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>最初のページ読み込みに関する 14kB ルールを聞いたことがあった場合、それは TCP スロースタートが理由です。そしてこれはウェブの性能の最適化が最初の 14kB にフォーカスする理由でもあります。TCP スロースタートは、ネットワークの輻輳を防ぎ、ネットワーク性能に対して適正なデータ転送速度を徐々に探り出します。</p>
+
+<h3 id="Congestion_control" name="Congestion_control">輻輳制御</h3>
+
+<p>サーバーが TCP パケットとしてデータを送信する一方で、ユーザー側のクライアントは確認応答、ACK を返してデータが配送されたことを確認します。コネクションには、ハードウェアやネットワークの条件によって許容量上の制限があります。サーバーが大きすぎるパケットを速すぎる速度で送信した場合、破棄されるでしょう。つまり、確認応答がない場合があるということです。サーバーはこれを missing ACK として処理します。輻輳制御アルゴリズムは、パケットを送信して確認応答を受け取るこのフローを使って送信レート (send rate) を決定します。</p>
+
+<h2 id="Parsing" name="Parsing">パース処理</h2>
+
+<p>データの最初のかたまりを受け取ると、ブラウザーは受信した情報のパース処理を始めることができます。{{glossary('speculative parsing', 'パース処理')}}は、ネットワークから受信したデータを {{glossary('DOM')}} と {{glossary('CSSOM')}} に変換するステップです。DOM と CSSOM は、レンダラーがページを画面へ描画するために利用されます。</p>
+
+<p>DOM はブラウザー向けのマークアップの内部的な表現です。DOM は外部に公開されており、JavaScript の様々な API を通じて操作できます。</p>
+
+<p>ブラウザーは、リクエストしたページの HTML が最初の 14kB のパケットより大きかった場合でも、手元にあるデータに基づいてパース処理を開始し、サイトを描画しようとします。これは、ウェブの性能を最適化する時にに、ブラウザーがページの描画を始めるために必要なすべてのデータ、あるいは少なくともページのテンプレート (最初の描画に必要となる CSS と HTML) を最初の 14kB に含めることが重要となる理由です。何か 1 つでも画面に描画を行うには、その前に HTML と CSS、JavaScript がパースされなければいけません。</p>
+
+<h3 id="Building_the_DOM_tree" name="Building_the_DOM_tree">DOM ツリーの構築</h3>
+
+<p><a href="/ja/docs/Web/Performance/Critical_rendering_path">クリティカルレンダリングパス</a>の 5 つのステップを説明します。</p>
+
+<p>最初のステップは HTML のマークアップを処理し、DOM ツリーを構築することです。HTML のパース処理は、<a href="/ja/docs/Web/API/DOMTokenList">トークン化</a>とツリーの構築に分かれます。HTML のトークンは開始タグと終了タグ、属性の名前と値を含みます。ドキュメントが正しく構成されていればパース処理は単純で、速度も速くなります。パーサーはトークン化された入力情報をドキュメントツリーを構成するドキュメントに変換します。</p>
+
+<p>DOM ツリーはドキュメントのコンテンツを表します。<code><a href="/ja/docs/Web/HTML/Element/html">&lt;html&gt;</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>パーサーが画像のようなノンブロッキングリソースを発見した場合、ブラウザーはそのリソースをリクエストし、そのままパース処理を継続します。CSS ファイルに遭遇した場合もパース処理を継続できます、しかし  <code><a href="/ja/docs/Web/JavaScript/Reference/Statements/async_function">async</a></code> または <code>defer</code> 属性がない <code>&lt;script&gt;</code> タグはレンダリングをブロックし、HTML のパース処理を停止します。ブラウザーのプリロードスキャナーがブロックの時間を減らしますが、それでも過度のスクリプトの使用は重大なボトルネックになり得ます。</p>
+
+<h3 id="Preload_scanner" name="Preload_scanner">プリロードスキャナー</h3>
+
+<p>ブラウザーが DOM ツリーを構築する間はそのプロセスがメインスレッドを占有します。その間に<em>プリロードスキャナー</em>が処理可能なコンテンツをパースし、CSS や JavaScript、ウェブフォントのような優先度の高いリソースのリクエストを行います。プリロードスキャナーのおかげで、リクエストするべき外部リソースへの参照をパーサーが見つけるのを待たなくて良くなります。バックグラウンドでリソースを取得するため、メインの HTML パーサーが該当のアセットにたどり着いた時には、すでにそれらのリソースが転送中あるいはダウンロード済みになっています。プリロードスキャナーによる最適化によりブロッキングを減らすることができます。</p>
+
+<pre class="brush:html">&lt;link rel="stylesheet" src="styles.css"/&gt;
+&lt;script src="myscript.js" <strong>async</strong>&gt;&lt;/script&gt;
+&lt;img src="myimage.jpg" alt="image description"/&gt;
+&lt;script src="anotherscript.js" <strong>async</strong>&gt;&lt;/script&gt;
+</pre>
+
+<p>この例では、メインスレッドが HTML と CSS をパースしている間に、プリロードスキャナーがスクリプトと画像を探索し、それらのダウンロードを開始します。もし JavaScript の実行順序が重要でないなら、スクリプトがプロセスをブロックしないように <code>async</code> 属性または <code>defer</code> 属性を追加しましょう。</p>
+
+<p>CSS の取得は HTML のパース処理あるいはダウンロードをブロックしません。しかし JavaScript の実行をブロックします。その理由は、しばしば JavaScript が CSS プロパティの要素への影響を問い合わせるために使われるからです。</p>
+
+<h3 id="Building_the_CSSOM" name="Building_the_CSSOM">CSSOM の構築</h3>
+
+<p>クリティカルレンダリングパスの 2 つめのステップは CSS を処理して CSSOM ツリーを構築することです。CSS のオブジェクトモデルは DOM によく似ています。DOM と CSSOM はどちらもツリー構造です。この 2 つは独立したデータ構造を持ちます。ブラウザーは、CSS のルールをブラウザーが理解できるスタイルのマップに変換します。ブラウザーは CSS のルールセットを読み取り、CSS セレクターにもとづいて、親、子、兄弟の関係から構成されるノードのツリーを生成します。</p>
+
+<p>HTML の場合と同様に、ブラウザーは受信した CSS のルールをブラウザーが実行可能な形式に変換しなければいけません。そのために、ブラウザーは HTML をオブジェクトに変換する場合と同じプロセスを CSS に対しても実行します。</p>
+
+<p>CSSOM ツリーはユーザーエージェントのスタイルシートから取得したスタイルを含みます。ブラウザーは、ノードに対して適用される最も一般的なルールからスタートして、より特定されたルールを再帰的に適用し、最終的なスタイルを計算します。つまり、プロパティの値をカスケードします。</p>
+
+<p>CSSOM の構築はとても高速であるため、現在の開発者ツールはそれ自体をユニークな色で表示しません。その代わりに、開発者ツールの「スタイルの再計算」は、CSS を解析して CSSOM ツリーを構築し、再帰的にスタイルを計算するトータルの時間を表示します。ウェブの性能の最適化の観点から言うと、CSSOM を生成するトータルの時間は一般的に１回の DNS ルックアップにかかる時間よりも少ないため、それほどの苦労はないと言えます。</p>
+
+<h3 id="Other_Processes" name="Other_Processes">その他の処理</h3>
+
+<h4 id="JavaScript_Compilation" name="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>
+
+<p>ブラウザーはコンテンツを理解し翻訳する補助機器で使用される<a href="/ja/docs/Learn/Accessibility">アクセシビリティ</a>ツリーも構築します。アクセシビリティオブジェクトモデル (AOM) は補助機器向けの DOM のようなものです。ブラウザーは、DOM が更新されるとアクセシビリティツリーも更新します。アクセシビリティツリーは補助機能それ自体からは変更できません。</p>
+
+<p>AOM が構築されるまで、<a href="https://wiki.developer.mozilla.org/ja/docs/Web/Accessibility/ARIA/ARIA_Screen_Reader_Implementors_Guide">スクリーンリーダー</a>でコンテンツにアクセスできません。</p>
+
+<h2 id="Render" name="Render">レンダリング</h2>
+
+<p>レンダリングのステップは、スタイル、レイアウト、ペイント、そしてコンポジットで構成されます。パースのステップで作成された CSSOM と DOM のツリーはレンダーツリーの形式へと組み合わされ、すべてのビジュアル要素のレイアウトを計算するために使用されてスクリーンに描画されます。いくつかのケースでは、CPU の代わりに GPU を使用してスクリーンの一部を描画し、メインスレッドを解放してパフォーマンスを改善するために、コンテンツ自身をレイヤーに昇格し、コンポジットを行います。</p>
+
+<h3 id="Style" name="Style">スタイル</h3>
+
+<p>クリティカルレンダリングパスの 3 番目のステップは DOM と CSSOM をレンダーツリーの形式へと組み合わせることです。計算されたスタイルのツリー、あるいはレンダーツリー、の構築は DOM ツリーのルートからスタートし、目に見える (Visible) ノードをトラバースします。</p>
+
+<p>ユーザーエージェントのスタイルシートにある <code>&lt;head&gt;</code> のような表示されることないタグとその子要素、<code>script { display: none; }</code> のように <code>display: none</code> を指定されたすべてのノード、はレンダリングの結果に影響しないためレンダーツリーには含まれません。<code>visibility: hidden</code> が適用されたノードは、スペースを確保するためレンダーツリーに含まれます。上記のサンプルコード内の <code>script</code> ノードは、ユーザーエージェントのデフォルトを上書きするディレクティブが指定されていないためレンダーツリーに含まれません。</p>
+
+<p>それぞれの目に見えるノードには、CSSOM のルールが適用されます。レンダーツリーはすべての目に見えるノードをコンテンツと計算されたスタイルを合わせて保持します。すべての関連するスタイルと DOM 上の目に見えるノードをマッチングし、<a href="/ja/docs/Web/CSS/Cascade">CSS カスケード</a>に基づいて、それぞれのノードに対応する計算されたスタイルを決定します。</p>
+
+<h3 id="Layout" name="Layout">レイアウト</h3>
+
+<p>クリティカルレンダリングパスの 4 番目のステップは各ノードの平面状の位置を計算するためにレイアウト処理を実行することです。<em>レイアウト</em>はレンダーツリーに含まれるすべてのノードの幅と高さ、位置を決める処理です。さらにページ上のそれぞれオブジェクトのサイズと位置を決定します。<em>リフロー</em>は、続いて発生するドキュメント全体、あるいはページの一部分のサイズと位置を決める処理です。</p>
+
+<p>レンダーツリーが構築されるとすぐにレイアウトが始まります。レンダーツリーは計算されたスタイルを踏まえてどのノードが表示されるか (非表示であっても) 特定しますが、寸法や位置は特定しません。各オブジェクトの正確なサイズと位置を決めるために、ブラウザーがレンダーツリーのルートからトラバースを行います。</p>
+
+<p>ウェブページ上では、ほとんどすべての要素はボックスです。異なるデバイス、異なるデスクトップの設定は、ビューポートのサイズの数が無制限に存在することを示しています。このフェーズにおいて、ビューポートのサイズを考慮して、ブラウザーはすべての異なるボックスのスクリーン上の寸法を決定します。ビューポートのサイズを基本として、レイアウトは一般的にボディからスタートし、すべてのボディの子孫をそれぞれの要素のボックスモデルプロパティに合わせてレイアウトし、画像のように寸法がわからない代替要素のためのプレースホルダースペースを作成します。</p>
+
+<p>ノードのサイズとポジションが決められる最初のタイミングをレイアウトと呼びます。続いて発生するノードのサイズと位置の再計算をリフロー呼びます。私たちの例では、画像が返される前に最初のレイアウトが発生すると考えられます。画像のサイズを宣言していなかったため、画像のサイズがわかるとすぐにリフローが発生します。</p>
+
+<h3 id="Paint" name="Paint">ペイント</h3>
+
+<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>ペイントはペイントツリー内の要素をレイヤーに分解します。コンテンツを GPU (CPU 上のメインスレッドの代わりになる) 上のレイヤーに昇格させることで、ペイントと再ペイントのパフォーマンスを向上します。<code><a href="https://wiki.developer.mozilla.org/ja/docs/Web/HTML/Element/video">&lt;video&gt;</a></code> や<code><a href="https://wiki.developer.mozilla.org/ja/docs/Web/HTML/Element/canvas">&lt;canvas&gt;</a></code>など、レイヤーを生成する特定のプロパティと要素があります。<a href="https://wiki.developer.mozilla.org/ja/docs/Web/CSS/opacity"><code>opacity</code></a>、3D <code><a href="https://wiki.developer.mozilla.org/ja/docs/Web/CSS/transform">transform</a></code>、<code><a href="https://wiki.developer.mozilla.org/ja/docs/Web/CSS/will-change">will-change</a></code>、その他いくつかの CSS プロパティを持つ要素も同様です。これらのノードは、その子孫が上記の理由でそれ自身のレイヤーを必要とするのでなければ、子孫と一緒に自身のレイヤー上に描画されます。</p>
+
+<p>レイヤーはパフォーマンスを改善しますが、メモリー管理の面ではコストのかかる処理です。そのため、ウェブのパフォーマンス最適化戦略の中で濫用するべきものではありません。</p>
+
+<h3 id="Compositing" name="Compositing">コンポジット</h3>
+
+<p>ドキュメントのセクションが異なるレイヤーに描画されて重なり合う場合、コンテンツをスクリーン上に正しい順番で描画するためにコンポジットが必要になります。</p>
+
+<p>ページがアセットの読み込みを続ける間もリフローは発生します (後ほど出てくる図を見てください)。リフローは再ペイントと再コンポジットを引き起こします。画像のサイズを指定していた場合リフローは必要ありません。再ペイントが必要なレイヤーのみが再ペイントされ、必要があればコンポジットが行われます。しかし、私たちのサンプルでは画像のサイズを指定しませんでした。画像がサーバーから取得されたとき、レンダリングプロセスはレイアウトステップまで戻り、そこから再開します。</p>
+
+<h2 id="Interactivity" name="Interactivity">インタラクティビティ</h2>
+
+<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>以下の例では、画像の読み込みは高速かもしれませんが、<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>この例では、DOM コンテンツの読み込みプロセスは 1.5 秒以上かかっており、メインスレッドがすべての時間を完全に占有され、クリックイベントや画面のタップに応答できなくなっています。</p>
+
+<h2 id="See_Also" name="See_Also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/Performance">ウェブパフォーマンス</a></li>
+</ul>
diff --git a/files/ja/web/performance/index.html b/files/ja/web/performance/index.html
new file mode 100644
index 0000000000..b2c6d47165
--- /dev/null
+++ b/files/ja/web/performance/index.html
@@ -0,0 +1,217 @@
+---
+title: Web パフォーマンス
+slug: Web/Performance
+translation_of: Web/Performance
+---
+<div>{{draft}}</div>
+
+<p><span class="seoSummary">Web パフォーマンスは客観的な測定値であり、ロード時間とランタイムに関するユーザーエクスペリエンスの認知度です。Web パフォーマンスとは、サイトがロードされ、対話型になり、応答性が向上するまでにかかる時間と、ユーザーとの対話中にコンテンツがどの程度スムーズになるかです </span>- スクロールはスムーズですか？ ボタンはクリック可能ですか？ ポップアップはすばやく開くことができますか？ また、ポップアップはスムーズにアニメートしますか？ Web パフォーマンスには、読み込み時間、1秒あたりのフレーム数、対話時間までの客観的な測定値と、コンテンツの読み込みに要した時間の主観的な経験の両方が含まれます。</p>
+
+<p>サイトのレスポンスに時間がかかるほど、ユーザーはそのサイトを放棄します。ロードの時間とレスポンスの時間を最小限に抑え、エクスペリエンスをできるだけ早くインタラクティブにしながら、エクスペリエンスの長い末尾部分に非同期的にロードすることで、レイテンシを隠す追加機能を追加することが重要です。</p>
+
+<p>Web パフォーマンスの測定と改善に役立つツール、API、およびベストプラクティスがあります。 このセクションでそれらをカバーします</p>
+
+<div class="cleared topicpage-table">
+<div class="section">
+<h2 id="主なチュートリアル">主なチュートリアル</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:</p>
+
+<dl>
+ <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/Web/Performance/Critical_rendering_path">Critical rendering path</a></dt>
+ <dd>Some attributes and the source order of your markup can impact the performance or your website. By minimizing the number of DOM nodes, making sure you use the best order and attributes for included 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 and the critical rendering path one can use to ensure maximum performance.</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. <span class="veryhardreadability"><span><span>This article outlines some JavaScript best practices that can ensure even complex content is as performant as possible.</span></span></span></dd>
+ <dt><a href="/en-US/docs/Learn/Performance/Multimedia">Multimedia: Images and Video</a></dt>
+ <dd>Frequently, media optimization is the lowest hanging fruit of web performance. 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 images, 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_performance">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/perceived_performance">How do users perceive performance?</a></dt>
+ <dd>
+ <p>More important than how fast your website is in milliseconds, is how fast do your users perceive your site to be. Page load time, idling, responsiveness to user interaction, and the smoothness of scrolling and other animations impact these perceptions. 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.</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/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>Populating the page</dt>
+ <dd>The client makes an HTTP request, and, hopefully, a few seconds later, the site appears. Displaying the content involves executing JavaScript, possibly modifying the DOM, calculating styles, calculating layout, and finally rendering the content, which involves painting and compositing, and can involve GPU acceleration on a separate thread.</dd>
+ <dt>Performance bottlenecks</dt>
+ <dd> </dd>
+ <dt><a href="/en-US/docs/Web/Performance/time_to_interactive">Time to Interactive</a></dt>
+ <dd> </dd>
+ <dt><a href="/en-US/docs/Learn/Performance/Latency">Understanding latency</a></dt>
+ <dd>
+ <p>Latency is the amount of time it takes between the browser making a request for a resource, and the browser receiving back the first byte of the resource requested. This article explains what latency is, how it impacts performance, and how to measure and improve latency.</p>
+ </dd>
+ <dt>Understanding bandwidth</dt>
+ <dd>
+ <div>
+ <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"><span><span>Bandwidth is the amount of data (measured in Mbps or Kbps) that one can send per second. </span></span><span class="veryhardreadability"><span><span>This article explains the role of bandwidth in media-rich internet applications, how you can measure it, and how you can optimize applications to make the best use of available bandwidth</span></span></span><span><span>.</span></span></div>
+ </div>
+
+ <p> </p>
+ </dd>
+ <dt><a href="/en-US/docs/Learn/Performance/HTTP2">HTTP/2 and you</a></dt>
+ <dd>
+ <p>The transport layer—that is, HTTP—is utterly essential to the functioning of the web, and it has only been relatively recently that it has seen a major update in the form of HTTP/2. Out of the box, HTTP/2 provides many performance improvements and advantages over its predecessor, but it also changes the landscape. In this article, you'll learn what HTTP/2 does for you, and how to fine-tune your application to make it do go even further.</p>
+ </dd>
+ <dt>The role of TLS in performance</dt>
+ <dd>
+ <p>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.</p>
+ </dd>
+ <dt>Reading performance charts</dt>
+ <dd>Developer tools provide information on performance, memory, and network requests. Knowing how to read <a href="https://developer.mozilla.org/en-US/docs/Tools/Performance/Waterfall">waterfall</a> charts, <a href="https://developer.mozilla.org/en-US/docs/Tools/Performance/Call_Tree">call trees</a>, traces, <a href="https://developer.mozilla.org/en-US/docs/Tools/Performance/Flame_Chart">flame charts</a> , and <a href="https://developer.mozilla.org/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>
+ <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. <span class="veryhardreadability"><span><span>In this guide, we'll show you how to analyze your application's script bundles, so you know </span></span><em><span>what</span></em><span><span> you're using, as well how to detect if your app contains duplicated scripts between bundles</span></span></span><span><span>.</span></span></dd>
+ <dt><a href="/en-US/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 defering the loading of assets on a page, such as scripts, images, etc., on a page to a later point in time – when those assets are actually needed.</dd>
+ <dt>Lazy-loading JavaScript with import()</dt>
+ <dd>The term "lazy loading" often refers to load deferment techniques for assets not needed at load such as loading below-the-fold imagery only when those images scroll into the view. Now there are native features to load JavaScript! In this guide, we'll talk about the dynamic import() statement, a newer browser feature, that loads a JavaScript module on demand.</dd>
+ <dt><a href="/en-US/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—but 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>
+</dl>
+</div>
+
+<div class="section">
+<h2 class="Other_documentation" id="Other_documentation" name="Other_documentation">Other documentation</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/Performance/business_case_for_performance">The business case for web performance</a></dt>
+ <dd>
+ <p>You know web performance is important, but how do you convince clients and management to invest in performance and make it a priority. In this article, we'll discuss creating a clear business case to convince decision-makers to make the investment. </p>
+ </dd>
+ <dt><a href="/en-US/docs/Web/Performance/Performance_budget">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/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>
+ <dt><a href="/en-US/docs/Web/Apps/Fundamentals/Performance/Optimizing_startup_performance">Optimizing Startup Performance</a><a href="/en-US/docs/Web/Apps/Fundamentals/Performance/Optimizing_startup_performance"> </a></dt>
+ <dd>How long does your app take to start up? Does it lock up the browser while loading? Take the time to ensure your app starts up nicely. This article offers tips and suggestions to help you achieve that goal.</dd>
+ <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/Learn/Performance/Understanding_latency">Understanding Latency</a></dt>
+ <dd>Latency is the amount of time it takes between the browser making a request for a resource, and the browser receiving back the first byte of the resource requested. This article explains what latency is, how it impacts performance, how to measure latency, and how to reduce it.</dd>
+ <dt><a href="/en-US/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 features, include service workers, diagnosing performance problems, font loading best practices, client hints, creating performant animations, etc.</dd>
+ <dt><a href="https://developer.mozilla.org/en-US/docs/Web/Performance/Rum-vs-Synthetic">Performance Monitoring: RUM vs synthetic monitoring</a></dt>
+ <dd>Sythentic and RUM are two different approaches for monitoring web performance. In this article we define and compare these two performance monitoring approaches.</dd>
+</dl>
+
+<h3 id="App_Performance">App Performance</h3>
+
+<dl>
+ <dt><a href="/en-US/Apps/Developing/Performance/Performance_fundamentals">Performance fundamentals</a></dt>
+ <dd>A wide overview of Web application performance, what it is, how the browser helps to improve it, and what tools and processes you can use to test and further improve it.</dd>
+ <dt><a href="/en-US/Apps/Developing/Performance/Optimizing_startup_performance">Optimizing startup performance</a></dt>
+ <dd>Tips and suggestions to help you improve startup performance, both when writing a new app and when porting an app from another platform to the Web.</dd>
+ <dt><a href="/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler">Profiling with the built-in profiler</a></dt>
+ <dd>Learn how to profile app performance with Firefox's built-in profiler.</dd>
+ <dt><a href="/en-US/Apps/Build/Performance/CSS_JavaScript_animation_performance">CSS and JavaScript animation performance</a></dt>
+ <dd>Animations are critical for a pleasurable user experience. This article discusses the performance differences between CSS- and JavaScript-based animations. </dd>
+</dl>
+
+<p><span class="alllinks"><a href="/en-US/docs/tag/Performance">View all articles about performance...</a></span></p>
+</div>
+</div>
+
+<p>{{LandingPageListSubpages}}</p>
+
+<h2 id="See_also">See also</h2>
+
+<p>HTML</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTML/Element/picture">The <code>&lt;picture&gt;</code> Element</a></li>
+ <li><a href="/en-US/docs/Web/HTML/Element/video">The <code>&lt;video&gt;</code> Element</a></li>
+ <li><a href="/en-US/docs/Web/HTML/Element/source">The <code>&lt;source&gt;</code> Element</a></li>
+ <li><a href="/en-US/docs/Web/HTML/Element/img#Attributes">The <code>&lt;img&gt; srcset</code> attribute</a>
+  <ul>
+   <li><a href="/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">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>
+</ul>
+
+<p>CSS</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/CSS/will-change">will-change</a></li>
+ <li>GPU v CPU</li>
+ <li>Measuring layout</li>
+ <li>font-loading best practices</li>
+</ul>
+
+<p>JavaScript</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/Events/DOMContentLoaded">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>
+</ul>
+
+<p>APIs</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>
+  <ul>
+   <li style="margin-top: 0.25em;"><a href="/en-US/docs/Web/API/Window/requestIdleCallback">requestIdleCallback() </a></li>
+  </ul>
+ </li>
+ <li><a href="/en-US/docs/Web/API/Beacon_API/Using_the_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>
+</ul>
+
+<p>Headers</p>
+
+<ul>
+ <li><a href="/en-US/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>
+</ul>
+
+<p>Tools</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>
+</ul>
+
+<p>Additional Metrics</p>
+
+<ul>
+ <li>Speed Index and Perceptual Speed Index</li>
+</ul>
+
+<p>Best Practices</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>
+  <ul>
+   <li><a href="/en-US/docs/Web/API/Web_Workers_API">Web Workers API</a></li>
+  </ul>
+ </li>
+ <li><a href="/en-US/docs/Web/Apps/Progressive/Offline_Service_workers">PWA</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/Caching">Caching</a></li>
+ <li>Content Delivery Networks (CDN)</li>
+</ul>