` と一致させる必要があります。
+- pluginURL
+ - : ブラウザーがダウンロードできる XML 検索プラグインの URL です。
+
+もしサイトが複数の検索プラグインを提供しているなら、すべてを自動検出させることができます。例を示します。
+
+```html
+
-
パフォーマンスとは、効率性を意味します。この文書では、オープンウェブアプリの観点から、パフォーマンスとは何か、ブラウザープラットフォームでどのようにパフォーマンスを向上させるか、テストや改善にどのようなツールやプロセスを使用できるかについて一般的な説明をします。.
-
最終的には、ユーザーが知覚したパフォーマンスが唯一のパフォーマンスとなります。ユーザーは、触ったり、動かしたり、話したりして、システムに入力を与えます。その代わり、ユーザーは視覚、触覚、聴覚を通じて出力を知覚します。パフォーマンスとは、ユーザーの入力に応じてシステムが出力するものの品質のことです。
-
-他の条件が同じであれば、ユーザーが知覚するパフォーマンス (以下、UPP) 以外のターゲットに最適化されたコードは、 UPP に最適化されたコードと競合すると負けてしまいます。ユーザーは、例えば、 1 秒間に 1,000 件しかデータベーストランザクションを処理しないが応答性の高いスムーズに動くアプリの方を、 1 秒間に 100,000,000 件のデータベーストランザクションを処理するカクカクした応答性の低いアプリよりも好みます。もちろん、他の指標を最適化することは決して無意味ではありませんが、実際の UPP ターゲットが最優先です。
-
-以下の節では、必須のパフォーマンス指標を指摘し、説明します。
-
-応答性
-
-応答性とは、ユーザーの入力に応じてシステムがどれだけ速く出力 (複数の場合もある) を行うかを意味します。例えば、ユーザーが画面をタップすると、ピクセルが特定の方法で変化することを期待します。この操作の場合、応答性の指標は、タップしてからピクセルが変化するまでの経過時間となります。
-
-応答性には、複数の段階のフィードバックが含まれることがあります。アプリケーションの起動は、特に重要なケースの一つで、詳しくは後述します。
-
-応答性が重要なのは、人は無視されるとイライラしたり怒ったりするからです。アプリはユーザーの入力に応答しない間、ユーザーを無視していることになります。
-
-フレームレート
-
-フレームレートとは、システムがユーザーに表示するピクセルを変化させる速度のことです。例えば、毎秒 10 フレームのゲームよりも、毎秒 60 フレームのゲームの方が好きだというのは、理由を説明できなくても、誰もが知っている概念です。
-
-フレームレートは「サービスの質」の指標としても重要です。コンピューターのディスプレイは、現実を模倣した光子をユーザーの目に届けることで、ユーザーの目を「欺く」ように設計されています。例えば、文字が印刷された紙は、光子をあるパターンでユーザーの目に反射させます。リーダーアプリは、ピクセルを操作することで、同じようなパターンで光子を放出し、ユーザーの目を「騙す」のです。
-
-脳は考えるとき、動きはギクシャクしたバラバラなものではなく、滑らかに連続して更新されるものだと考えます。 (ストロボはそれを逆手に取り、脳の入力を奪って離散的な現実を錯覚させるから面白いのです）。コンピューターのディスプレイでは、フレームレートが高ければ高いほど、より忠実に現実を再現することができます。
-
-
-
注 : 人間は通常、60Hz以上のフレームレートの違いを知覚することができません。そのため、最近の電子ディスプレイは、60Hzで更新するように設計されています。例えばハチドリには、テレビが途切れ途切れで非現実的に見えることでしょう。
-
メモリーの使用
-
-メモリーの使用量 も重要な指標です。応答性やフレームレートとは異なり、ユーザーはメモリー使用量を直接知覚することはありませんが、メモリー使用量は「ユーザーの状態」に近いものです。理想的なシステムでは、ユーザーの状態を常に 100% 維持することができます。システム内のすべてのアプリケーションは同時に実行され、すべてのアプリケーションは、ユーザーが最後にアプリケーションを操作したにユーザーが設定した状態を維持します (アプリケーションの状態はコンピュータのメモリーに保存されているため、近似値になるのです)。
-
-このことから、重要ではあるが直感的ではない副産物が得られます。設計の優れたシステムは、空き メモリー量を最大化しません。メモリーは資源であり、空きメモリーは使われていない資源であるからです。むしろ、設計の優れたシステムは、ユーザーの状態を維持するために可能な限り多くのメモリーを使用し、かつ他の UPP 目標を満たすように最適化されています。
-
-これは、システムがメモリーを浪費 すべきだという意味ではありません。システムがある特定のユーザーの状態を維持するために必要以上のメモリーを使用すると、システムは他のユーザーの状態を維持するために使用できる資源を浪費していることになります。実際には、すべてのユーザーの状態を維持できるシステムはありません。ユーザーの状態に賢くメモリーを割り当てることは、以下で詳しく説明する重要な問題です。
-
-電力使用量
-
-ここで解説する最後の指標は、電力使用量 です。メモリー使用量と同様に、ユーザーは、端末が他のすべての UPP 目標を維持できる時間という形で、電力使用量を間接的にしか認識しません。 UPP 目標を達成するためには、システムは必要最小限の電力しか使用しないようにする必要があります。
-
-この文書の残りの部分では、これらの指標の観点からパフォーマンスについて説明します。
-
-
-
-この節では、 Firefox/Gecko が、すべてのアプリケーションのレベルよりも下位で、一般的にどのようにパフォーマンスに貢献しているかを簡単に説明します。開発者やユーザーの視点から、「プラットフォームは何をしてくれるのか？」という問いに答えます。
-
-ウェブ技術
-
-ウェブプラットフォームには多くのツールが用意されていますが、中には特定の仕事に適したものもあります。アプリケーションロジックはすべて JavaScript で書かれています。グラフィックの表示には、 (高水準の宣言型言語である) HTML や CSS を使用するか、低レベルの命令型インターフェースである {{ htmlelement("canvas") }} 要素 (WebGL を含む) を使用します。 HTML/CSS と Canvas の「中間」に位置するのが SVG で、両者の利点を兼ね備えています。
-
-HTML や CSS は、フレームレートやピクセルレベルでのレンダリング制御を犠牲にして、生産性を大幅に向上させます。テキストや画像は自動的に再フローされ、 UI 要素には自動的にシステムのテーマが適用されます。また、このシステムは、様々な解像度のディスプレイや右書きの言語など、開発者が最初に思いつかないような使用方法に「組み込み」で対応します。
-
-canvas 要素は、開発者が直接描画できるピクセルバッファーを提供します。これにより、開発者はピクセルレベルでレンダリングを制御し、フレームレートを正確に制御することができますが、複数の解像度や方向、右書きの言語などに対応する必要があります。開発者は、おなじみの 2D 描画 API か、 OpenGL ES 2.0 をほぼ踏襲した「金属に近い」バインディングである WebGL を使用してキャンバスに描画します。
-
-
-
注 : Firefox OS は、 HTML 、CSS 、JavaScript などのウェブ技術で作られたアプリに最適化されています。一握りの基本的なシステムサービスを除いて、 Firefox OS で動作するすべてのコードはウェブアプリと Gecko エンジンから来ています。 OS のウィンドウマネージャも HTML、CSS、JavaScript で書かれています。コアとなる OS とアプリケーションは同じウェブ技術で構築されているため、これらの技術がどのように機能するかが重要になります。そこには「逃げ道」はありません。これは開発者にとって大きなメリットです。なぜなら、サードパーティのアプリケーションは、 OS が独自に行ったすべての最適化の恩恵を受けることができるからです。プリインストールされたコードだけが利用できる「魔法のパフォーマンスソース」はありません。 Firefox OS に関する詳細は、 Firefox OS のパフォーマンステスト をご覧ください。
-
Gecko のレンダリング
-
-Gecko の JavaScript エンジンは、実行時 (JIT) コンパイルに対応しています。これにより、アプリケーションロジックは、Java 仮想マシンのような他の仮想マシンと同等の性能を発揮し、場合によっては「ネイティブコード」に近い性能を発揮します。
-
-HTML、CSS、Canvas を支える Gecko のグラフィックパイプラインは、いくつかの方法で最適化されています。 Gecko の HTML/CSS レイアウトおよびグラフィックコードは、スクロールなどの一般的なケースでは、無効化や再描画を削減しますが、開発者はこのサポートを「無料」で受けることができます。 Gecko が「自動的に」描画したり、 canvas へアプリケーションが「手動で」描画したりするピクセルバッファーは、ディスプレイのフレームバッファーに描画される際のコピーを最小限に抑えます。これは、中間サーフェスがオーバーヘッドになるような場所 (他の多くのオペレーティングシステムにおけるアプリケーションごとの「バックバッファー」など) を避け、コンポジターハードウェアが直接アクセスできるグラフィックバッファー用の特別なメモリーを使用することで実現されています。複雑なシーンのレンダリングには、端末の GPU を使用して最大のパフォーマンスを発揮します。電力消費を抑えるために、シンプルなシーンは専用の合成ハードウェアを使ってレンダリングし、 GPU はアイドルまたはオフにしています。
-
-リッチアプリケーションでは、完全な静的コンテンツは例外です。リッチアプリケーションでは、アニメーションやトランジション効果のある動的コンテンツを使用します。トランジションやアニメーションは、アプリケーションにとって特に重要です。開発者は、 CSS を使用することで、複雑な動作をシンプルで高レベルな構文で宣言することができます。また、 Gecko のグラフィックパイプラインは、一般的なアニメーションを効率的に描画するように高度に最適化されています。良くあるアニメーションは、システムコンポジターにオフロードされ、パフォーマンスと電力効率に優れた方法でレンダリングされます。
-
-アプリの起動時のパフォーマンスは、実行時のパフォーマンスと同じくらい重要です。 Gecko は、 Web 全体を含むさまざまなコンテンツを効率的に読み込むように最適化されています。並列 HTML 解析、再フローと画像デコーディングのインテリジェントなスケジューリング、巧妙なレイアウトアルゴリズムなど、コンテンツを対象とした長年の改良は、Firefox でのウェブアプリケーションの改良にも同様に反映されます。
-
-
-
-
-
-この節では、「どうしたらアプリを高速にできるのか」という開発者の問いのためのものです。
-
-
-
-アプリケーションの起動は、一般的に 3 つのイベントで構成されています。
-
-
- 1 つ目は、アプリケーションのファーストペイント (最初のフレームを描くのに十分なアプリケーションリソースが読み込まれた時点) です。
- 2 つ目は、アプリケーションが操作可能になった時点です。例えば、ユーザーがボタンをタップすると、アプリケーションが反応するようになります。
- 最後のイベントは完全読み込み です。たとえば、音楽プレイヤーにユーザーのアルバムをすべて表示された時点です。
-
-
-高速な起動の鍵となるのは、 2 つのことを念頭に置くことです。 UPP がすべてであること、そして上記のユーザーが知覚する各イベントには「クリティカルパス」が存在することです。クリティカルパスとは、まさに、そのイベントを発生させるために実行しなければならないコードのことです。
-
-例えば、アプリケーションの最初のフレームを視覚的に描くためには、いくつかの HTML と、その HTML にスタイル付けする CSS で構成されます。
-
-
- HTML を解釈する必要がある
- その HTML の DOM を構築する必要がある
- DOM の一部にある画像などのリソースを読み込み、デコードする必要がある
- CSS のスタイルをその DOM に適用する必要がある
- スタイル付けした文書を再フローさせる必要がある
-
-
-このリストのどこにも、「一般的でないメニューに必要な JS ファイルの読み込み」や「ハイスコアリスト用の画像の取得とデコード」などは含まれていません。これらの作業項目は、最初のフレームを描くためのクリティカルパスには含まれていません。
-
-当たり前のようですが、ユーザーが認識する起動イベントに早く到達するためには、クリティカルパス上のコードだけ を実行することが主な「コツ」です。その場面を単純化することで、クリティカルパスを短縮します。
-
-ウェブプラットフォームは非常にダイナミックです。 JavaScript は動的に型付けされる言語であり、ウェブプラットフォームではコード、HTML、CSS、画像などのリソースを動的に読み込むことができます。これらの機能を利用して、起動後しばらくしてから不要なコンテンツを「遅延して」読み込むことで、クリティカルパスから外れた作業を先送りすることができます。
-
-起動を遅らせるもう 1 つの問題は、リクエストに対するレスポンス (データベースのロードなど) を待つことで発生するアイドルタイムです。この問題を避けるために、アプリケーションは起動時にできるだけ早くリクエストを発行する必要があります (これを「フロントローディング」と呼びます)。そうすれば、後でデータが必要になったとき、うまくいけばすでに利用可能で、アプリケーションは待つ必要がありません。
-
-
-
-また、ローカルにキャッシュされた静的なリソースは、高レイテンシー、低帯域幅のモバイルネットワークを介して取得された動的なデータよりもはるかに速く読み込まれることに注意してください。ネットワークへのリクエストは、アプリケーションの早期起動のためのクリティカルパスであってはなりません。ローカルキャッシュ／オフラインアプリケーションは、サービスワーカー によって実現できます。その方法については、 サービスワーカーで PWA をオフライン対応させる を参照してください。
-
-フレームレート
-
-高フレームレートを実現するためにまず重要なのは、適切な道具を選ぶことです。静止画やスクロール、アニメーションの頻度が少ないコンテンツの実装には、 HTML と CSS を使用します。レンダリングを厳密にコントロールする必要があり、テーマ性を必要としないゲームのように、高度に動的なコンテンツを実装する場合は、キャンバスを使用します。
-
-キャンバスで描かれたコンテンツでは、フレームレートの目標値を達成できるかどうかは、開発者次第です。
-
-HTML と CSS のコンテンツでは、適切なプリミティブを使用することが高フレームレートへの道となります。 Firefox は任意のコンテンツをスクロールするために高度に最適化されているため、通常はこの点を気にする必要はありません。しかし、 CSS の放射状グラデーションの代わりに静的なレンダリングを使用するなど、速度のために汎用性や品質を犠牲にすると、スクロールのフレームレートが目標値を超えてしまうことがよくあります。 CSS のメディアクエリー を使えば、こうした妥協を必要とする端末だけに制限することができます。
-
-多くのアプリケーションでは、「ページ」や「パネル」を使ったトランジションやアニメーションが使われています。例えば、ユーザーが「設定」ボタンをタップすると、アプリケーションの設定画面に遷移したり、設定メニューが「ポップアップ」したりします。 Firefox は、以下のようなシーンの遷移やアニメーションに高度に最適化されています。
-
-
- 端末の画面サイズ以下のページ/パネルを使用する
- CSS 変換や不透明度のプロパティを使った遷移やアニメーションを使用する
-
-
-これらのガイドラインに従った遷移やアニメーションは、システムコンポジターにオフロードされ、最大限効率的に動作します。
-
-メモリーと電力の使用量
-
-メモリーと電力使用量の改善は、スタートアップの高速化と同じような問題です。必要のない作業をしたり、普段使わない UI リソースをダラダラとロードしたりしてはいけません。効率的なデータ構造を使用し、画像などのリソースをしっかりと最適化しましょう。
-
-最近の CPU は、ほとんどアイドル状態の時に低消費電力モードに入ることができます。常にタイマーを作動させたり、不要なアニメーションを実行し続けるアプリケーションは、 CPU が低電力モードに入るのを妨げます。電力効率の良いアプリケーションは、そのようなことをしてはいけません。
-
-アプリケーションがバックグラウンドに送られると、その文書に対して {{event("visibilitychange")}} イベントが発行されます。このイベントは開発者の味方です。アプリケーションはこのイベントに耳を傾けるべきです。バックグラウンドに送られたときに、アプリケーションが読み込まれたリソースをできるだけ多く手放すと、メモリー使用量が少なくて済み、 Firefox OS の場合、廃棄される可能性も低くなります (以下のメモを参照)。これはつまり、 (すでに実行されているため) 「起動」が速く、 UPP が良いことを意味します。
-
-
-
注 : 前述のとおり、 Firefox OS はできる限り多くのアプリケーションを同時に実行するようにしていますが、通常は端末のメモリーが不足したときにアプリケーションを破棄しなければならないことがあります。Firefox OS がどのようにメモリー使用量を管理し、メモリー不足の問題が発生したときにアプリケーションを終了するかについての詳細は、「Debugging out of memory errors on Firefox OS 」を参照してください。
-
以下の実用的なヒントは、前述のアプリケーションのパフォーマンス要因の 1 つまたは複数を改善するのに役立ちます。
-
-CSS アニメーションとトランジションを使用する
-
-一部のライブラリーの animate() 関数は、おそらく現在、パフォーマンスが悪い数多くの技術 (例えば {{domxref("WindowOrWorkerGlobalScope.setTimeout")}} や top/left による位置指定) を使用しています。代わりに CSS アニメーション を使用してください。多くの場合、実際には CSS トランジション を使って実現することができます。ブラウザーはこれらの効果を最適化するように設計されており、 GPU を使用してプロセッサーのパフォーマンスへの影響を最小限に抑えながらスムーズに処理することができるため、うまく機能します。もう一つの利点は、標準化された構文を使って、アプリの他のルック＆フィールと一緒に CSS でこれらの効果を定義できることです。
-
-CSS アニメーションでは、 キーフレーム を使って効果を細かく制御することができます。また、アニメーション処理中に発生するイベントを監視して、アニメーション処理中の特定のポイントで実行する必要のある他のタスクを処理することもできます。これらのアニメーションは、 {{cssxref(":hover")}}, {{cssxref(":focus")}}, {{cssxref(":target")}} を使ったり、親要素に動的にクラスを追加したり削除したりすることで、簡単に起動することができます。
-
-アニメーションをその場で作成したり、 JavaScript で修正したりしたい場合は、 James Long 氏が CSS-animations.js というシンプルなライブラリーを作成していますので、そちらをご利用ください。
-
-
-
-コンテンツの位置やスケールなどを調整するのに、絶対位置を調整したり、すべての計算を自分で行ったりする代わりに、 CSS の {{cssxref("transform")}} プロパティを使用しましょう。その理由は、繰り返しになりますが、ハードウェアアクセラレーションです。ブラウザーはこれらの作業を GPU で行い、 CPU に他の処理をさせることができます。
-
-さらに、変換は、他では得られない機能を提供します。 2D 空間の要素を変換するだけでなく、 3 次元に変換したり、斜めにしたり、回転させたりすることができます。 Paul Irish 氏は、パフォーマンスの観点から見た translate() の利点を詳しく分析top と left の位置指定で変換をシミュレートする場合は、多くの追加コードが必要になります。もうひとつの利点は、 canvas 要素で作業するのと同じだということです。
-
-
-
注 : プラットフォームによっては、 CSS アニメーションでハードウェアアクセラレーションを利用したい場合、 translateZ(0.1) 変換を割り当てる必要があります。前述のとおり、パフォーマンスが向上しますが、メモリー消費の問題もあります。テストをして、自分のアプリケーションに最適な方法を見つけてみてはいかがでしょうか。
-
requestAnimationFrame() を setInterval() の代わりに使用する{{domxref("WindowOrWorkerGlobalScope.setInterval")}} の呼び出しは、現在の状況下で可能かどうかわからない推定フレームレートでコードを実行します。このコードは、ブラウザーが実際に描画していない間、つまりビデオハードウェアが次の表示サイクルに達していない間にも、結果をレンダリングするようブラウザーに指示します。これはプロセッサー時間を浪費し、ユーザーの端末のバッテリー寿命を縮めることにもつながります。
-
-その代わりに、 {{domxref("window.requestAnimationFrame()")}} を使うようにしましょう。これは、ブラウザーがアニメーションの次のフレームを作り始める準備ができるまで待機し、ハードウェアが実際に何も描画しない場合は無視します。この API のもう一つの利点は、アプリが画面上に表示されていない間はアニメーションが実行されないことです (バックグラウンドで他のタスクが動作している場合など)。これにより、バッテリーの消費を抑え、ユーザーが夜空に向かってあなたの名前を罵るのを防ぐことができます。
-
-
-
-アクセシビリティに配慮した古いタイプのウェブ開発者は、キーボード入力二も対応する click イベントが大好きです。モバイル端末では、これらのイベントは遅すぎます。代わりに {{event("touchstart")}} と {{event("touchend")}} を使うべきです。これらのイベントには、アプリの操作を鈍くする遅延がないからです。最初にタッチ対応のテストを行えば、アクセシビリティも犠牲にすることはありません。例えば、 Financial Times は、そのために fastclick というライブラリーを使用しており、これを利用することができます。
-
-インターフェイスをシンプルに保つ
-
-HTML5 アプリのパフォーマンスに関する大きな問題のひとつに、たくさんの DOM 要素を移動させるとすべてが遅くなるということがあります。見た目をシンプルにして、ドラッグ＆ドロップでプロキシー要素を移動させるようにすると非常に有効です。
-
-たとえば、長い要素のリスト (ツイートとします) がある場合、それらをすべて移動させてはいけません。代わりに、表示されているものと、現在表示されているツイートのセットの両側にいくつかあるものだけを DOM ツリーに残します。残りは隠すか削除します。データを DOM にアクセスするのではなく、 JavaScript のオブジェクトに保持することで、アプリのパフォーマンスが大幅に向上します。表示は、データそのものではなく、データのプレゼンテーションだと考えてください。だからといって、 HTML をそのままソースとして使ってはいけないというわけではありません。 HTML を一度読み込んでから 10 個の要素をスクロールさせ、表示されていない 100 個の要素を動かすのではなく、結果リストの中の自分の位置に応じて最初と最後の要素の内容を変えればいいのです。ゲームでは、スプライトにも同じことが言えます。その代わりに、画面外にスクロールした要素を新しいものが入ってきたときに再利用します。
-
-
-
-Firefox や Chrome などのブラウザーには、ページの表示速度が遅いことを診断するためのツールが組み込まれています。特に、 Firefox のネットワークモニター は、ページ上のそれぞれのネットワークリクエストがいつ発生し、どれくらいの規模で、どれくらいの時間がかかっているかを正確に時系列で表示します。
-
-
-
-ページに実行に時間がかかる JavaScript コードが含まれている場合、 JavaScript プロファイラー は最も遅いコードの行を特定します。
-
-
-
-Gecko 内蔵のプロファイラー は、プロファイラーの実行中にブラウザーのコードのどの部分がゆっくりと動作しているかについて、さらに詳細な情報を提供する非常に便利なツールです。これは使用方法が少し複雑ですが、多くの有用な詳細情報を提供してくれます。
-
-
-
-
-
注 : Android のブラウザーで Firefox を起動し、リモートデバッグ を有効にすることで、これらのツールを使用することができます。
-
特に、モバイルブラウザーでは、数十から数百のネットワークリクエストに時間がかかります。また、大きな画像や CSS グラデーションの描画にも時間がかかることがあります。大きなファイルのダウンロードは、高速なネットワークであっても時間がかかることがあります。これは、モバイルハードウェアの速度が遅すぎて、利用可能なすべての帯域幅を活用できない場合があるためです。モバイルウェブのパフォーマンスに関する一般的なヒントについては、 Maximiliano Firtman 氏の Mobile Web High Performance の談話をご覧ください。
-
-テストケースとバグの報告
-
-Firefox や Chrome の開発者ツールで問題が解決しない場合や、ウェブブラウザーが原因と思われる場合は、問題を最大限に分離した縮小版のテストケースを提供してみてください。それが問題の診断に役立つことがよくあります。
-
-HTML ページの静的なコピー (埋め込まれている画像、スタイルシート、スクリプトを含む) を保存、読み込みすることで問題を再現できるかどうかを確認してください。問題が再現できれば、静的ファイルを編集して個人情報を削除し、他の人に送って助けを求めてください (例えば、 Bugzilla レポートを提出するか、サーバーでホスティングして URL を共有してください)。また、上述のツールを使って収集したプロファイリング情報も共有してください。
diff --git a/files/ja/web/performance/fundamentals/index.md b/files/ja/web/performance/fundamentals/index.md
new file mode 100644
index 00000000000000..bae7b7d769fc17
--- /dev/null
+++ b/files/ja/web/performance/fundamentals/index.md
@@ -0,0 +1,197 @@
+---
+title: パフォーマンスの基礎
+slug: Web/Performance/Fundamentals
+tags:
+ - Apps
+ - Firefox
+ - Gecko
+ - Guide
+ - Performance
+translation_of: Web/Performance/Fundamentals
+---
+パフォーマンスとは、効率性を意味します。この文書では、オープンウェブアプリの観点から、パフォーマンスとは何か、ブラウザープラットフォームでどのようにパフォーマンスを向上させるか、テストや改善にどのようなツールやプロセスを使用できるかについて一般的な説明をします。.
+
+## パフォーマンスとは
+
+最終的には、ユーザーが知覚したパフォーマンスが唯一のパフォーマンスとなります。ユーザーは、触ったり、動かしたり、話したりして、システムに入力を与えます。その代わり、ユーザーは視覚、触覚、聴覚を通じて出力を知覚します。パフォーマンスとは、ユーザーの入力に応じてシステムが出力するものの品質のことです。
+
+他の条件が同じであれば、ユーザーが知覚するパフォーマンス (以下、UPP) 以外のターゲットに最適化されたコードは、 UPP に最適化されたコードと競合すると負けてしまいます。ユーザーは、例えば、 1 秒間に 1,000 件しかデータベーストランザクションを処理しないが応答性の高いスムーズに動くアプリの方を、 1 秒間に 100,000,000 件のデータベーストランザクションを処理するカクカクした応答性の低いアプリよりも好みます。もちろん、他の指標を最適化することは決して無意味ではありませんが、実際の UPP ターゲットが最優先です。
+
+以下の節では、必須のパフォーマンス指標を指摘し、説明します。
+
+### 応答性
+
+応答性とは、ユーザーの入力に応じてシステムがどれだけ速く出力 (複数の場合もある) を行うかを意味します。例えば、ユーザーが画面をタップすると、ピクセルが特定の方法で変化することを期待します。この操作の場合、応答性の指標は、タップしてからピクセルが変化するまでの経過時間となります。
+
+応答性には、複数の段階のフィードバックが含まれることがあります。アプリケーションの起動は、特に重要なケースの一つで、詳しくは後述します。
+
+応答性が重要なのは、人は無視されるとイライラしたり怒ったりするからです。アプリはユーザーの入力に応答しない間、ユーザーを無視していることになります。
+
+### フレームレート
+
+フレームレートとは、システムがユーザーに表示するピクセルを変化させる速度のことです。例えば、毎秒 10 フレームのゲームよりも、毎秒 60 フレームのゲームの方が好きだというのは、理由を説明できなくても、誰もが知っている概念です。
+
+フレームレートは「サービスの質」の指標としても重要です。コンピューターのディスプレイは、現実を模倣した光子をユーザーの目に届けることで、ユーザーの目を「欺く」ように設計されています。例えば、文字が印刷された紙は、光子をあるパターンでユーザーの目に反射させます。リーダーアプリは、ピクセルを操作することで、同じようなパターンで光子を放出し、ユーザーの目を「騙す」のです。
+
+脳は考えるとき、動きはギクシャクしたバラバラなものではなく、滑らかに連続して更新されるものだと考えます。 (ストロボはそれを逆手に取り、脳の入力を奪って離散的な現実を錯覚させるから面白いのです）。コンピューターのディスプレイでは、フレームレートが高ければ高いほど、より忠実に現実を再現することができます。
+
+> **Note:** 人間は通常、60Hz 以上のフレームレートの違いを知覚することができません。そのため、最近の電子ディスプレイは、60Hz で更新するように設計されています。例えばハチドリには、テレビが途切れ途切れで非現実的に見えることでしょう。
+
+### メモリーの使用
+
+**メモリーの使用量**も重要な指標です。応答性やフレームレートとは異なり、ユーザーはメモリー使用量を直接知覚することはありませんが、メモリー使用量は「ユーザーの状態」に近いものです。理想的なシステムでは、ユーザーの状態を常に 100% 維持することができます。システム内のすべてのアプリケーションは同時に実行され、すべてのアプリケーションは、ユーザーが最後にアプリケーションを操作したにユーザーが設定した状態を維持します (アプリケーションの状態はコンピュータのメモリーに保存されているため、近似値になるのです)。
+
+このことから、重要ではあるが直感的ではない副産物が得られます。設計の優れたシステムは、**空き**メモリー量を最大化しません。メモリーは資源であり、空きメモリーは使われていない資源であるからです。むしろ、設計の優れたシステムは、ユーザーの状態を維持するために可能な限り多くのメモリーを使用し、かつ他の UPP 目標を満たすように最適化されています。
+
+これは、システムがメモリーを**浪費**すべきだという意味ではありません。システムがある特定のユーザーの状態を維持するために必要以上のメモリーを使用すると、システムは他のユーザーの状態を維持するために使用できる資源を浪費していることになります。実際には、すべてのユーザーの状態を維持できるシステムはありません。ユーザーの状態に賢くメモリーを割り当てることは、以下で詳しく説明する重要な問題です。
+
+### 電力使用量
+
+ここで解説する最後の指標は、**電力使用量**です。メモリー使用量と同様に、ユーザーは、端末が他のすべての UPP 目標を維持できる時間という形で、電力使用量を間接的にしか認識しません。 UPP 目標を達成するためには、システムは必要最小限の電力しか使用しないようにする必要があります。
+
+この文書の残りの部分では、これらの指標の観点からパフォーマンスについて説明します。
+
+## プラットフォームのパフォーマンスの最適化
+
+この節では、 Firefox/Gecko が、すべてのアプリケーションのレベルよりも下位で、一般的にどのようにパフォーマンスに貢献しているかを簡単に説明します。開発者やユーザーの視点から、「プラットフォームは何をしてくれるのか？」という問いに答えます。
+
+### ウェブ技術
+
+ウェブプラットフォームには多くのツールが用意されていますが、中には特定の仕事に適したものもあります。アプリケーションロジックはすべて JavaScript で書かれています。グラフィックの表示には、 (高水準の宣言型言語である) HTML や CSS を使用するか、低レベルの命令型インターフェースである {{ htmlelement("canvas") }} 要素 ([WebGL](/ja/docs/Web/API/WebGL_API) を含む) を使用します。 HTML/CSS と Canvas の「中間」に位置するのが [SVG](/ja/docs/Web/SVG) で、両者の利点を兼ね備えています。
+
+HTML や CSS は、フレームレートやピクセルレベルでのレンダリング制御を犠牲にして、生産性を大幅に向上させます。テキストや画像は自動的に再フローされ、 UI 要素には自動的にシステムのテーマが適用されます。また、このシステムは、様々な解像度のディスプレイや右書きの言語など、開発者が最初に思いつかないような使用方法に「組み込み」で対応します。
+
+`canvas` 要素は、開発者が直接描画できるピクセルバッファーを提供します。これにより、開発者はピクセルレベルでレンダリングを制御し、フレームレートを正確に制御することができますが、複数の解像度や方向、右書きの言語などに対応する必要があります。開発者は、おなじみの 2D 描画 API か、 OpenGL ES 2.0 をほぼ踏襲した「金属に近い」バインディングである WebGL を使用してキャンバスに描画します。
+
+> **Note:** Firefox OS は、 [HTML](/ja/docs/Web/HTML)、[CSS](/ja/docs/Web/CSS)、[JavaScript](/ja/docs/Web/JavaScript) などのウェブ技術で作られたアプリに最適化されています。一握りの基本的なシステムサービスを除いて、 Firefox OS で動作するすべてのコードはウェブアプリと Gecko エンジンから来ています。 OS のウィンドウマネージャも HTML、CSS、JavaScript で書かれています。コアとなる OS とアプリケーションは同じウェブ技術で構築されているため、これらの技術がどのように機能するかが重要になります。そこには「逃げ道」はありません。これは開発者にとって大きなメリットです。なぜなら、サードパーティのアプリケーションは、 OS が独自に行ったすべての最適化の恩恵を受けることができるからです。プリインストールされたコードだけが利用できる「魔法のパフォーマンスソース」はありません。 Firefox OS に関する詳細は、 [Firefox OS のパフォーマンステスト](/ja/docs/Archive/B2G_OS/Firefox_OS_apps/Performance/Firefox_OS_performance_testing)をご覧ください。
+
+### Gecko のレンダリング
+
+Gecko の JavaScript エンジンは、実行時 (JIT) コンパイルに対応しています。これにより、アプリケーションロジックは、Java 仮想マシンのような他の仮想マシンと同等の性能を発揮し、場合によっては「ネイティブコード」に近い性能を発揮します。
+
+HTML、CSS、Canvas を支える Gecko のグラフィックパイプラインは、いくつかの方法で最適化されています。 Gecko の HTML/CSS レイアウトおよびグラフィックコードは、スクロールなどの一般的なケースでは、無効化や再描画を削減しますが、開発者はこのサポートを「無料」で受けることができます。 Gecko が「自動的に」描画したり、 `canvas` へアプリケーションが「手動で」描画したりするピクセルバッファーは、ディスプレイのフレームバッファーに描画される際のコピーを最小限に抑えます。これは、中間サーフェスがオーバーヘッドになるような場所 (他の多くのオペレーティングシステムにおけるアプリケーションごとの「バックバッファー」など) を避け、コンポジターハードウェアが直接アクセスできるグラフィックバッファー用の特別なメモリーを使用することで実現されています。複雑なシーンのレンダリングには、端末の GPU を使用して最大のパフォーマンスを発揮します。電力消費を抑えるために、シンプルなシーンは専用の合成ハードウェアを使ってレンダリングし、 GPU はアイドルまたはオフにしています。
+
+リッチアプリケーションでは、完全な静的コンテンツは例外です。リッチアプリケーションでは、アニメーションやトランジション効果のある動的コンテンツを使用します。トランジションやアニメーションは、アプリケーションにとって特に重要です。開発者は、 CSS を使用することで、複雑な動作をシンプルで高レベルな構文で宣言することができます。また、 Gecko のグラフィックパイプラインは、一般的なアニメーションを効率的に描画するように高度に最適化されています。良くあるアニメーションは、システムコンポジターにオフロードされ、パフォーマンスと電力効率に優れた方法でレンダリングされます。
+
+アプリの起動時のパフォーマンスは、実行時のパフォーマンスと同じくらい重要です。 Gecko は、 Web 全体を含むさまざまなコンテンツを効率的に読み込むように最適化されています。並列 HTML 解析、再フローと画像デコーディングのインテリジェントなスケジューリング、巧妙なレイアウトアルゴリズムなど、コンテンツを対象とした長年の改良は、Firefox でのウェブアプリケーションの改良にも同様に反映されます。
+
+> **Note:** 起動時のパフォーマンスをさらに向上させるための Firefox OS の仕様についての詳細は、 [Firefox OS パフォーマンステスト](/ja/docs/Archive/B2G_OS/Firefox_OS_apps/Performance/Firefox_OS_performance_testing)を参照してください。
+
+## アプリケーションのパフォーマンス
+
+この節では、「どうしたらアプリを高速にできるのか」という開発者の問いのためのものです。
+
+### 起動時のパフォーマンス
+
+アプリケーションの起動は、一般的に 3 つのイベントで構成されています。
+
+- 1 つ目は、アプリケーションの**ファーストペイント** (最初のフレームを描くのに十分なアプリケーションリソースが読み込まれた時点) です。
+- 2 つ目は、アプリケーションが操作可能になった時点です。例えば、ユーザーがボタンをタップすると、アプリケーションが反応するようになります。
+- 最後のイベントは**完全読み込み**です。たとえば、音楽プレイヤーにユーザーのアルバムをすべて表示された時点です。
+
+高速な起動の鍵となるのは、 2 つのことを念頭に置くことです。 UPP がすべてであること、そして上記のユーザーが知覚する各イベントには「クリティカルパス」が存在することです。クリティカルパスとは、まさに、そのイベントを発生させるために実行しなければならないコードのことです。
+
+例えば、アプリケーションの最初のフレームを視覚的に描くためには、いくつかの HTML と、その HTML にスタイル付けする CSS で構成されます。
+
+1. HTML を解釈する必要がある
+2. その HTML の DOM を構築する必要がある
+3. DOM の一部にある画像などのリソースを読み込み、デコードする必要がある
+4. CSS のスタイルをその DOM に適用する必要がある
+5. スタイル付けした文書を再フローさせる必要がある
+
+このリストのどこにも、「一般的でないメニューに必要な JS ファイルの読み込み」や「ハイスコアリスト用の画像の取得とデコード」などは含まれていません。これらの作業項目は、最初のフレームを描くためのクリティカルパスには含まれていません。
+
+当たり前のようですが、ユーザーが認識する起動イベントに早く到達するためには、*クリティカルパス上のコードだけ*を実行することが主な「コツ」です。その場面を単純化することで、クリティカルパスを短縮します。
+
+ウェブプラットフォームは非常にダイナミックです。 JavaScript は動的に型付けされる言語であり、ウェブプラットフォームではコード、HTML、CSS、画像などのリソースを動的に読み込むことができます。これらの機能を利用して、起動後しばらくしてから不要なコンテンツを「遅延して」読み込むことで、クリティカルパスから外れた作業を先送りすることができます。
+
+起動を遅らせるもう 1 つの問題は、リクエストに対するレスポンス (データベースのロードなど) を待つことで発生するアイドルタイムです。この問題を避けるために、アプリケーションは起動時にできるだけ早くリクエストを発行する必要があります (これを「フロントローディング」と呼びます)。そうすれば、後でデータが必要になったとき、うまくいけばすでに利用可能で、アプリケーションは待つ必要がありません。
+
+> **Note:** 起動時のパフォーマンスを向上させるための詳しい情報は、[起動時のパフォーマンスを最適化する](/ja/docs/Web/Performance/Optimizing_startup_performance)をご覧ください。
+
+また、ローカルにキャッシュされた静的なリソースは、高レイテンシー、低帯域幅のモバイルネットワークを介して取得された動的なデータよりもはるかに速く読み込まれることに注意してください。ネットワークへのリクエストは、アプリケーションの早期起動のためのクリティカルパスであってはなりません。ローカルキャッシュ／オフラインアプリケーションは、[サービスワーカー](/ja/docs/Web/API/Service_Worker_API)によって実現できます。その方法については、 [サービスワーカーで PWA をオフライン対応させる](/ja/docs/Web/Progressive_web_apps/Offline_Service_workers) を参照してください。
+
+### フレームレート
+
+高フレームレートを実現するためにまず重要なのは、適切な道具を選ぶことです。静止画やスクロール、アニメーションの頻度が少ないコンテンツの実装には、 HTML と CSS を使用します。レンダリングを厳密にコントロールする必要があり、テーマ性を必要としないゲームのように、高度に動的なコンテンツを実装する場合は、キャンバスを使用します。
+
+キャンバスで描かれたコンテンツでは、フレームレートの目標値を達成できるかどうかは、開発者次第です。
+
+HTML と CSS のコンテンツでは、適切なプリミティブを使用することが高フレームレートへの道となります。 Firefox は任意のコンテンツをスクロールするために高度に最適化されているため、通常はこの点を気にする必要はありません。しかし、 CSS の放射状グラデーションの代わりに静的なレンダリングを使用するなど、速度のために汎用性や品質を犠牲にすると、スクロールのフレームレートが目標値を超えてしまうことがよくあります。 CSS の[メディアクエリー](/ja/docs/Web/CSS/Media_Queries/Using_media_queries)を使えば、こうした妥協を必要とする端末だけに制限することができます。
+
+多くのアプリケーションでは、「ページ」や「パネル」を使ったトランジションやアニメーションが使われています。例えば、ユーザーが「設定」ボタンをタップすると、アプリケーションの設定画面に遷移したり、設定メニューが「ポップアップ」したりします。 Firefox は、以下のようなシーンの遷移やアニメーションに高度に最適化されています。
+
+- 端末の画面サイズ以下のページ/パネルを使用する
+- CSS 変換や不透明度のプロパティを使った遷移やアニメーションを使用する
+
+これらのガイドラインに従った遷移やアニメーションは、システムコンポジターにオフロードされ、最大限効率的に動作します。
+
+### メモリーと電力の使用量
+
+メモリーと電力使用量の改善は、スタートアップの高速化と同じような問題です。必要のない作業をしたり、普段使わない UI リソースをダラダラとロードしたりしてはいけません。効率的なデータ構造を使用し、画像などのリソースをしっかりと最適化しましょう。
+
+最近の CPU は、ほとんどアイドル状態の時に低消費電力モードに入ることができます。常にタイマーを作動させたり、不要なアニメーションを実行し続けるアプリケーションは、 CPU が低電力モードに入るのを妨げます。電力効率の良いアプリケーションは、そのようなことをしてはいけません。
+
+アプリケーションがバックグラウンドに送られると、その文書に対して {{event("visibilitychange")}} イベントが発行されます。このイベントは開発者の味方です。アプリケーションはこのイベントに耳を傾けるべきです。バックグラウンドに送られたときに、アプリケーションが読み込まれたリソースをできるだけ多く手放すと、メモリー使用量が少なくて済み、 Firefox OS の場合、廃棄される可能性も低くなります (以下のメモを参照)。これはつまり、 (すでに実行されているため) 「起動」が速く、 UPP が良いことを意味します。
+
+> **Note:** 前述のとおり、 Firefox OS はできる限り多くのアプリケーションを同時に実行するようにしていますが、通常は端末のメモリーが不足したときにアプリケーションを破棄しなければならないことがあります。Firefox OS がどのようにメモリー使用量を管理し、メモリー不足の問題が発生したときにアプリケーションを終了するかについての詳細は、「[Debugging out of memory errors on Firefox OS](/ja/docs/Archive/B2G_OS/Debugging/Debugging_OOMs)」を参照してください。
+
+### アプリケーションのパフォーマンスのためのコーディングのコツ
+
+以下の実用的なヒントは、前述のアプリケーションのパフォーマンス要因の 1 つまたは複数を改善するのに役立ちます。
+
+#### CSS アニメーションとトランジションを使用する
+
+一部のライブラリーの `animate()` 関数は、おそらく現在、パフォーマンスが悪い数多くの技術 (例えば {{domxref("WindowOrWorkerGlobalScope.setTimeout")}} や `top`/`left` による位置指定) を使用しています。代わりに [CSS アニメーション](/ja/docs/Web/CSS/CSS_Animations/Using_CSS_animations)を使用してください。多くの場合、実際には [CSS トランジション](/ja/docs/Web/CSS/CSS_Transitions/Using_CSS_transitions)を使って実現することができます。ブラウザーはこれらの効果を最適化するように設計されており、 GPU を使用してプロセッサーのパフォーマンスへの影響を最小限に抑えながらスムーズに処理することができるため、うまく機能します。もう一つの利点は、標準化された構文を使って、アプリの他のルック＆フィールと一緒に CSS でこれらの効果を定義できることです。
+
+CSS アニメーションでは、 [キーフレーム](/ja/docs/Web/CSS/@keyframes)を使って効果を細かく制御することができます。また、アニメーション処理中に発生するイベントを監視して、アニメーション処理中の特定のポイントで実行する必要のある他のタスクを処理することもできます。これらのアニメーションは、 {{cssxref(":hover")}}, {{cssxref(":focus")}}, {{cssxref(":target")}} を使ったり、親要素に動的にクラスを追加したり削除したりすることで、簡単に起動することができます。
+
+アニメーションをその場で作成したり、 [JavaScript](/ja/docs/Web/JavaScript) で修正したりしたい場合は、 James Long 氏が [CSS-animations.js](https://github.com/jlongster/css-animations.js/) というシンプルなライブラリーを作成していますので、そちらをご利用ください。
+
+#### CSS 変換を使用する
+
+コンテンツの位置やスケールなどを調整するのに、絶対位置を調整したり、すべての計算を自分で行ったりする代わりに、 CSS の {{cssxref("transform")}} プロパティを使用しましょう。その理由は、繰り返しになりますが、ハードウェアアクセラレーションです。ブラウザーはこれらの作業を GPU で行い、 CPU に他の処理をさせることができます。
+
+さらに、変換は、他では得られない機能を提供します。 2D 空間の要素を変換するだけでなく、 3 次元に変換したり、斜めにしたり、回転させたりすることができます。 Paul Irish 氏は、パフォーマンスの観点から見た [`translate()` の利点を詳しく分析](https://paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/)しています。しかし、一般的には、 CSS アニメーションを使用する場合と同じメリットがあります。つまり、仕事に適したツールを使用し、最適化はブラウザーに任せることができるのです。また、要素の位置を簡単に拡張できる方法を使用しています。 `top` と `left` の位置指定で変換をシミュレートする場合は、多くの追加コードが必要になります。もうひとつの利点は、 `canvas` 要素で作業するのと同じだということです。
+
+> **Note:** プラットフォームによっては、 CSS アニメーションでハードウェアアクセラレーションを利用したい場合、 `translateZ(0.1)` 変換を割り当てる必要があります。前述のとおり、パフォーマンスが向上しますが、メモリー消費の問題もあります。テストをして、自分のアプリケーションに最適な方法を見つけてみてはいかがでしょうか。
+
+#### `requestAnimationFrame()` を `setInterval()` の代わりに使用する
+
+{{domxref("WindowOrWorkerGlobalScope.setInterval")}} の呼び出しは、現在の状況下で可能かどうかわからない推定フレームレートでコードを実行します。このコードは、ブラウザーが実際に描画していない間、つまりビデオハードウェアが次の表示サイクルに達していない間にも、結果をレンダリングするようブラウザーに指示します。これはプロセッサー時間を浪費し、ユーザーの端末のバッテリー寿命を縮めることにもつながります。
+
+その代わりに、 {{domxref("window.requestAnimationFrame()")}} を使うようにしましょう。これは、ブラウザーがアニメーションの次のフレームを作り始める準備ができるまで待機し、ハードウェアが実際に何も描画しない場合は無視します。この API のもう一つの利点は、アプリが画面上に表示されていない間はアニメーションが実行されないことです (バックグラウンドで他のタスクが動作している場合など)。これにより、バッテリーの消費を抑え、ユーザーが夜空に向かってあなたの名前を罵るのを防ぐことができます。
+
+#### イベントを即時にする
+
+アクセシビリティに配慮した古いタイプのウェブ開発者は、キーボード入力二も対応する click イベントが大好きです。モバイル端末では、これらのイベントは遅すぎます。代わりに {{event("touchstart")}} と {{event("touchend")}} を使うべきです。これらのイベントには、アプリの操作を鈍くする遅延がないからです。最初にタッチ対応のテストを行えば、アクセシビリティも犠牲にすることはありません。例えば、 Financial Times は、そのために [fastclick](https://github.com/ftlabs/fastclick) というライブラリーを使用しており、これを利用することができます。
+
+#### インターフェイスをシンプルに保つ
+
+HTML5 アプリのパフォーマンスに関する大きな問題のひとつに、たくさんの [DOM](/ja/docs/Web/API/Document_Object_Model) 要素を移動させるとすべてが遅くなるということがあります。見た目をシンプルにして、ドラッグ＆ドロップでプロキシー要素を移動させるようにすると非常に有効です。
+
+たとえば、長い要素のリスト (ツイートとします) がある場合、それらをすべて移動させてはいけません。代わりに、表示されているものと、現在表示されているツイートのセットの両側にいくつかあるものだけを DOM ツリーに残します。残りは隠すか削除します。データを DOM にアクセスするのではなく、 JavaScript のオブジェクトに保持することで、アプリのパフォーマンスが大幅に向上します。表示は、データそのものではなく、データのプレゼンテーションだと考えてください。だからといって、 HTML をそのままソースとして使ってはいけないというわけではありません。 HTML を一度読み込んでから 10 個の要素をスクロールさせ、表示されていない 100 個の要素を動かすのではなく、結果リストの中の自分の位置に応じて最初と最後の要素の内容を変えればいいのです。ゲームでは、スプライトにも同じことが言えます。その代わりに、画面外にスクロールした要素を新しいものが入ってきたときに再利用します。
+
+## 一般的なアプリケーションのパフォーマンス分析
+
+Firefox や Chrome などのブラウザーには、ページの表示速度が遅いことを診断するためのツールが組み込まれています。特に、 [Firefox のネットワークモニター](/ja/docs/Tools/Network_Monitor)は、ページ上のそれぞれのネットワークリクエストがいつ発生し、どれくらいの規模で、どれくらいの時間がかかっているかを正確に時系列で表示します。
+
+
+
+ページに実行に時間がかかる JavaScript コードが含まれている場合、 [JavaScript プロファイラー](/ja/docs/Tools/Performance)は最も遅いコードの行を特定します。
+
+
+
+[Gecko 内蔵のプロファイラー](/ja/docs/Performance/Profiling_with_the_Built-in_Profiler) は、プロファイラーの実行中にブラウザーのコードのどの部分がゆっくりと動作しているかについて、さらに詳細な情報を提供する非常に便利なツールです。これは使用方法が少し複雑ですが、多くの有用な詳細情報を提供してくれます。
+
+
+
+> **Note:** Android のブラウザーで Firefox を起動し、[リモートデバッグ](/ja/docs/Tools/Remote_Debugging)を有効にすることで、これらのツールを使用することができます。
+
+特に、モバイルブラウザーでは、数十から数百のネットワークリクエストに時間がかかります。また、大きな画像や CSS グラデーションの描画にも時間がかかることがあります。大きなファイルのダウンロードは、高速なネットワークであっても時間がかかることがあります。これは、モバイルハードウェアの速度が遅すぎて、利用可能なすべての帯域幅を活用できない場合があるためです。モバイルウェブのパフォーマンスに関する一般的なヒントについては、 Maximiliano Firtman 氏の [Mobile Web High Performance](https://www.slideshare.net/firt/mobile-web-high-performance) の談話をご覧ください。
+
+### テストケースとバグの報告
+
+Firefox や Chrome の開発者ツールで問題が解決しない場合や、ウェブブラウザーが原因と思われる場合は、問題を最大限に分離した縮小版のテストケースを提供してみてください。それが問題の診断に役立つことがよくあります。
+
+HTML ページの静的なコピー (埋め込まれている画像、スタイルシート、スクリプトを含む) を保存、読み込みすることで問題を再現できるかどうかを確認してください。問題が再現できれば、静的ファイルを編集して個人情報を削除し、他の人に送って助けを求めてください (例えば、 [Bugzilla](https://bugzilla.mozilla.org/) レポートを提出するか、サーバーでホスティングして URL を共有してください)。また、上述のツールを使って収集したプロファイリング情報も共有してください。
diff --git a/files/ja/web/performance/how_browsers_work/index.html b/files/ja/web/performance/how_browsers_work/index.html
deleted file mode 100644
index 93404959420edc..00000000000000
--- a/files/ja/web/performance/how_browsers_work/index.html
+++ /dev/null
@@ -1,216 +0,0 @@
----
-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
----
-ユーザーは、読み込みが速く、スムーズに操作できるコンテンツを、ウェブで体験することを求めています。したがって、開発者はこれらふたつの目標を達成するために努力しなければいけません。
-
-どうやって性能そして体感性能を改善するか理解するためには、ブラウザーがどのように動作するかを理解することが役に立ちます。
-
-概要
-
-速いサイトはより良いユーザー体験をもたらします。ユーザーは読み込みが速く、スムーズに操作できるコンテンツを体験することを求め、期待しています。
-
-ウェブの性能における 2 つの主要な課題は、レイテンシーに関する諸問題と、多くの場合ブラウザーはシングルスレッドであるという事実に関する諸問題を理解することです。
-
-レイテンシーは、速い読み込みを実現するために克服しなければいけない一番の脅威です。読み込みを速くしようとする開発者のゴールは、リクエストされた情報をできる限り速く送信すること、または少なくともとても速いように見せることです。ネットワークのレイテンシーは、バイト情報をコンピューターまで送信するのにかかる時間のことです。ウェブの性能は、ページの読み込みを出来る限り速くするよう私たちが何をするかにかかっています。
-
-多くの場合、ブラウザーはシングルスレッドだと考えられます。スムーズな操作を実現しようとする開発者のゴールは、滑らかなスクロール、タッチ操作への反応など、期待通りのサイトの操作を実現することです。メインスレッドが全ての処理を時間内に完了し、その上でユーザーの操作を常にハンドリングできるよう保証するために、描画時間が鍵となります。ブラウザーがシングルスレッドであることによる特性を理解し、メインスレッドの責務を最小限に抑え、可能かつ適切な場合に、描画のスムーズさと操作への即時の反応を実現することで、ウェブの性能が改善されます。
-
-ナビゲーション
-
-ナビゲーション はウェブページを読み込むための最初の一歩です。ユーザーが URL をアドレスバーに入力したり、リンクをクリックしたり、またはフォームを送信したり、ページをリクエストするたびごとにナビゲーションが発生します。
-
-ウェブの性能における目標の 1 つは、ナビゲーションが完了するまでの時間を最小限にすることです。理想的な条件下において、一般的にこの時間が長すぎることはありませんが、レイテンシーと帯域幅が遅延を引き起こす邪魔者になる場合があります。
-
-DNS ルックアップ
-
-ウェブページへのナビゲーションの最初の一歩は、ページのアセットがどこにあるか見つけることです。https://example.com へアクセスする場合、その HTML のページは IP アドレスが 93.184.216.34 のサーバーに存在します。これまでに一度もそのサイトを訪れたことがなかった場合、DNS ルックアップが必要になります。
-
-ブラウザーが DNS ルックアップをリクエストし、そのリクエストは最終的にネームサーバーによって処理され、ネームサーバーが IP アドレスを返します。この最初のリクエストの後、多くの場合その IP アドレスはしばらくの間キャッシュされ、ネームサーバーへ再接続する代わりにキャッシュから IP アドレスを取得することによって、後続するリクエストの速度を向上します。
-
-DNS ルックアップは、一般的に、1 回のページ読み込みの中でホスト名ごとに 1 回だけ必要になります。しかし、DNS ルックアップは要求されたページが参照するユニークなホストネームそれぞれに対して実行が必要です。必要なフォントや画像、スクリプト、広告、メトリクスのそれぞれが異なるホスト名を持っている場合は、それぞれに対して DNS ルックアップが必要です。
-
-
-
-これはとくにモバイルネットワークにおいて性能上の問題になる可能性があります。ユーザーがモバイルネットワークを利用している場合、DNS ルックアップは、権威 DNS サーバーへ到達するために、電話機から基地局へ送信される必要があります。電話機と基地局、そしてネームサーバー間の距離によって重大な遅延が発生する場合があります。
-
-TCP ハンドシェイク
-
-IP アドレスが判明すると、ブラウザーは {{glossary('TCP handshake','TCP 3 ウェイハンドシェイク')}}を通じてサーバーとのコネクションを設定します。この仕組みは、通信を意図する 2 つの主体が—この場合はブラウザーとウェブサーバーが—、データを送信する前に、多くの場合 {{glossary('HTTPS')}} を用いて、ネットワーク TCP ソケットコネクションのパラメーターを交換できるよう設計されています。
-
-TCP の 3 ウェイハンドシェイクは、しばしば、"SYN-SYN-ACK"、より正確には SYN、SYN-ACK、ACK と呼ばれます。これは 2 つのコンピューターの間で TCP のセッションを開始するために、TCP によって 3 つのメッセージが送受信されることを表します。つまり、これはそれぞれのサーバーの間で 3 回以上のメッセージのやりとりが必要であり、そのためのリクエストが生成されなければいけないことを意味しています。
-
-TLS ネゴシエーション
-
-HTTPS によって確立される安全なコネクションでは、もう 1 つのハンドシェイクが必要です。このハンドシェイク、より正確に言うと {{glossary('TLS')}} ネゴシエーションは、通信の暗号化に使用する暗号の種類を決定し、サーバーを認証し、実際のデータ送信が始まる前に安全な通信の準備を整えます。この処理は、コンテンツのリクエストを実際に送信する前に、さらに 3 回のラウンドトリップを必要とします。
-
-
-
-通信を安全にするためにページ読み込みの時間が追加されますが、ブラウザーとサーバーの間で送信されるデータが第三者に解読されないという安全な通信は、レイテンシーに見合う価値があるものです。
-
-8 回のラウンドトリップを経て、ブラウザーはようやくリクエストを送ることができます。
-
-レスポンス
-
-ウェブサーバーへのコネクションが確立されると、ブラウザーはユーザーに代わって最初の HTTP GET リクエスト を送信します。ウェブサイトであれば、多くの場合その対象は HTML ファイルです。リクエストを受け取ったサーバーは、適当なレスポンスヘッダーと HTML のコンテンツを返します。
-
-<!doctype HTML>
-<html>
- <head>
- <meta charset="UTF-8"/>
- <title>My simple page</title>
- <link rel="stylesheet" src="styles.css"/>
- <script src="myscript.js"></script>
-</head>
-<body>
- <h1 class="heading">My Page</h1>
- <p>A paragraph with a <a href="https://example.com/about">link</a></p>
- <div>
- <img src="myimage.jpg" alt="image description"/>
- </div>
- <script src="anotherscript.js"></script>
-</body>
-</html>
-
-この最初のリクエストへのレスポンスは、受信データの最初のバイト (First Byte) を含んでいます。{{glossary('Time to First Byte')}} (TTFB) は、ユーザーがリクエストを実行した時点から—たとえば、リンクをクリックした時点から— HTML の最初のパケットを受信するまでの時間を表します。コンテンツの最初のかたまり (Chunk) は一般的に 14kB のデータです。
-
-上記のサンプルコードでは、リクエストされたコンテンツは明らかに 14kB より小さいですが、後述するように、リンクされたリソースは、ブラウザーのパース処理がそのリンクにたどり着くまでリクエストされることはありません。
-
-TCP スロースタート / 14kB ルール
-
-最初の応答パケットは 14kB になります。これは、{{glossary('TCP slow start','TCP スロースタート')}}の一部で、ネットワークコネクションの速度を制御するアルゴリズムの影響です。スロースタートは、ネットワークの最大の帯域幅が確定するまで徐々に送信するデータ量が増やします。
-
-{{glossary('TCP slow start','TCP スロースタート')}}において、サーバーは最初のパケットを受信した後、次のパケットのサイズを 28kB に倍増させます。さらに後続のパケットについて事前に決めた上限に達するか、ネットワークの輻輳を検知するまでサイズを増やします。
-
-
-
-最初のページ読み込みに関する 14kB ルールを聞いたことがあった場合、それは TCP スロースタートが理由です。そしてこれはウェブの性能の最適化が最初の 14kB にフォーカスする理由でもあります。TCP スロースタートは、ネットワークの輻輳を防ぎ、ネットワーク性能に対して適正なデータ転送速度を徐々に探り出します。
-
-輻輳制御
-
-サーバーが TCP パケットとしてデータを送信する一方で、ユーザー側のクライアントは確認応答、ACK を返してデータが配送されたことを確認します。コネクションには、ハードウェアやネットワークの条件によって許容量上の制限があります。サーバーが大きすぎるパケットを速すぎる速度で送信した場合、破棄されるでしょう。つまり、確認応答がない場合があるということです。サーバーはこれを missing ACK として処理します。輻輳制御アルゴリズムは、パケットを送信して確認応答を受け取るこのフローを使って送信レート (send rate) を決定します。
-
-パース処理
-
-データの最初のかたまりを受け取ると、ブラウザーは受信した情報のパース処理を始めることができます。{{glossary('speculative parsing', 'パース処理')}}は、ネットワークから受信したデータを {{glossary('DOM')}} と {{glossary('CSSOM')}} に変換するステップです。DOM と CSSOM は、レンダラーがページを画面へ描画するために利用されます。
-
-DOM はブラウザー向けのマークアップの内部的な表現です。DOM は外部に公開されており、JavaScript の様々な API を通じて操作できます。
-
-ブラウザーは、リクエストしたページの HTML が最初の 14kB のパケットより大きかった場合でも、手元にあるデータに基づいてパース処理を開始し、サイトを描画しようとします。これは、ウェブの性能を最適化する時にに、ブラウザーがページの描画を始めるために必要なすべてのデータ、あるいは少なくともページのテンプレート (最初の描画に必要となる CSS と HTML) を最初の 14kB に含めることが重要となる理由です。何か 1 つでも画面に描画を行うには、その前に HTML と CSS、JavaScript がパースされなければいけません。
-
-DOM ツリーの構築
-
-クリティカルレンダリングパス の 5 つのステップを説明します。
-
-最初のステップは HTML のマークアップを処理し、DOM ツリーを構築することです。HTML のパース処理は、トークン化 とツリーの構築に分かれます。HTML のトークンは開始タグと終了タグ、属性の名前と値を含みます。ドキュメントが正しく構成されていればパース処理は単純で、速度も速くなります。パーサーはトークン化された入力情報をドキュメントツリーを構成するドキュメントに変換します。
-
-DOM ツリーはドキュメントのコンテンツを表します。<html>
-
-
-
-パーサーが画像のようなノンブロッキングリソースを発見した場合、ブラウザーはそのリソースをリクエストし、そのままパース処理を継続します。CSS ファイルに遭遇した場合もパース処理を継続できます、しかし async defer 属性がない <script> タグはレンダリングをブロックし、HTML のパース処理を停止します。ブラウザーのプリロードスキャナーがブロックの時間を減らしますが、それでも過度のスクリプトの使用は重大なボトルネックになり得ます。
-
-プリロードスキャナー
-
-ブラウザーが DOM ツリーを構築する間はそのプロセスがメインスレッドを占有します。その間にプリロードスキャナー が処理可能なコンテンツをパースし、CSS や JavaScript、ウェブフォントのような優先度の高いリソースのリクエストを行います。プリロードスキャナーのおかげで、リクエストするべき外部リソースへの参照をパーサーが見つけるのを待たなくて良くなります。バックグラウンドでリソースを取得するため、メインの HTML パーサーが該当のアセットにたどり着いた時には、すでにそれらのリソースが転送中あるいはダウンロード済みになっています。プリロードスキャナーによる最適化によりブロッキングを減らすることができます。
-
-<link rel="stylesheet" src="styles.css"/>
-<script src="myscript.js" async ></script>
-<img src="myimage.jpg" alt="image description"/>
-<script src="anotherscript.js" async ></script>
-
-
-この例では、メインスレッドが HTML と CSS をパースしている間に、プリロードスキャナーがスクリプトと画像を探索し、それらのダウンロードを開始します。もし JavaScript の実行順序が重要でないなら、スクリプトがプロセスをブロックしないように async 属性または defer 属性を追加しましょう。
-
-CSS の取得は HTML のパース処理あるいはダウンロードをブロックしません。しかし JavaScript の実行をブロックします。その理由は、しばしば JavaScript が CSS プロパティの要素への影響を問い合わせるために使われるからです。
-
-CSSOM の構築
-
-クリティカルレンダリングパスの 2 つめのステップは CSS を処理して CSSOM ツリーを構築することです。CSS のオブジェクトモデルは DOM によく似ています。DOM と CSSOM はどちらもツリー構造です。この 2 つは独立したデータ構造を持ちます。ブラウザーは、CSS のルールをブラウザーが理解できるスタイルのマップに変換します。ブラウザーは CSS のルールセットを読み取り、CSS セレクターにもとづいて、親、子、兄弟の関係から構成されるノードのツリーを生成します。
-
-HTML の場合と同様に、ブラウザーは受信した CSS のルールをブラウザーが実行可能な形式に変換しなければいけません。そのために、ブラウザーは HTML をオブジェクトに変換する場合と同じプロセスを CSS に対しても実行します。
-
-CSSOM ツリーはユーザーエージェントのスタイルシートから取得したスタイルを含みます。ブラウザーは、ノードに対して適用される最も一般的なルールからスタートして、より特定されたルールを再帰的に適用し、最終的なスタイルを計算します。つまり、プロパティの値をカスケードします。
-
-CSSOM の構築はとても高速であるため、現在の開発者ツールはそれ自体をユニークな色で表示しません。その代わりに、開発者ツールの「スタイルの再計算」は、CSS を解析して CSSOM ツリーを構築し、再帰的にスタイルを計算するトータルの時間を表示します。ウェブの性能の最適化の観点から言うと、CSSOM を生成するトータルの時間は一般的に１回の DNS ルックアップにかかる時間よりも少ないため、それほどの苦労はないと言えます。
-
-その他の処理
-
-JavaScript のコンパイル
-
-CSS がパースされ、CSSOM が生成される間、JavaScript ファイルを含む他のアセットが（プリロードスキャナーによって）ダウンロードされます。JavaScript は、インタープリターに処理され、コンパイル、パース処理を経て実行されます。スクリプトはパース処理によって抽象構文木に変換されます。いくつかのブラウザーエンジンは、{{glossary('Abstract Syntax Tree', '抽象構文木')}}をインタープリターへ引き渡し、メインスレッドで実行されるバイトコードを出力します。これが JavaScript のコンパイル処理に当たります。
-
-アクセシビリティツリーの構築
-
-ブラウザーはコンテンツを理解し翻訳する補助機器で使用されるアクセシビリティ ツリーも構築します。アクセシビリティオブジェクトモデル (AOM) は補助機器向けの DOM のようなものです。ブラウザーは、DOM が更新されるとアクセシビリティツリーも更新します。アクセシビリティツリーは補助機能それ自体からは変更できません。
-
-AOM が構築されるまで、スクリーンリーダー でコンテンツにアクセスできません。
-
-レンダリング
-
-レンダリングのステップは、スタイル、レイアウト、描画、そして合成で構成されます。パースのステップで作成された CSSOM と DOM のツリーはレンダーツリーの形式へと組み合わされ、すべてのビジュアル要素のレイアウトを計算するために使用されてスクリーンに描画されます。いくつかのケースでは、CPU の代わりに GPU を使用してスクリーンの一部を描画し、メインスレッドを解放してパフォーマンスを改善するために、コンテンツ自身をレイヤーに昇格し、合成を行います。
-
-スタイル
-
-クリティカルレンダリングパスの 3 番目のステップは DOM と CSSOM をレンダーツリーの形式へと組み合わせることです。計算されたスタイルのツリー、あるいはレンダーツリー、の構築は DOM ツリーのルートからスタートし、目に見える (Visible) ノードをトラバースします。
-
-ユーザーエージェントのスタイルシートにある <head> のような表示されることないタグとその子要素、script { display: none; } のように display: none を指定されたすべてのノード、はレンダリングの結果に影響しないためレンダーツリーには含まれません。visibility: hidden が適用されたノードは、スペースを確保するためレンダーツリーに含まれます。上記のサンプルコード内の script ノードは、ユーザーエージェントのデフォルトを上書きするディレクティブが指定されていないためレンダーツリーに含まれません。
-
-それぞれの目に見えるノードには、CSSOM のルールが適用されます。レンダーツリーはすべての目に見えるノードをコンテンツと計算されたスタイルを合わせて保持します。すべての関連するスタイルと DOM 上の目に見えるノードをマッチングし、CSS カスケード に基づいて、それぞれのノードに対応する計算されたスタイルを決定します。
-
-レイアウト
-
-クリティカルレンダリングパスの 4 番目のステップは各ノードの平面状の位置を計算するためにレイアウト処理を実行することです。レイアウト はレンダーツリーに含まれるすべてのノードの幅と高さ、位置を決める処理です。さらにページ上のそれぞれオブジェクトのサイズと位置を決定します。再フロー は、続いて発生するドキュメント全体、あるいはページの一部分のサイズと位置を決める処理です。
-
-レンダーツリーが構築されるとすぐにレイアウトが始まります。レンダーツリーは計算されたスタイルを踏まえてどのノードが表示されるか (非表示であっても) 特定しますが、寸法や位置は特定しません。各オブジェクトの正確なサイズと位置を決めるために、ブラウザーがレンダーツリーのルートからトラバースを行います。
-
-ウェブページ上では、ほとんどすべての要素はボックスです。異なるデバイス、異なるデスクトップの設定は、ビューポートのサイズの数が無制限に存在することを示しています。このフェーズにおいて、ビューポートのサイズを考慮して、ブラウザーはすべての異なるボックスのスクリーン上の寸法を決定します。ビューポートのサイズを基本として、レイアウトは一般的にボディからスタートし、すべてのボディの子孫をそれぞれの要素のボックスモデルプロパティに合わせてレイアウトし、画像のように寸法がわからない代替要素のためのプレースホルダースペースを作成します。
-
-ノードのサイズとポジションが決められる最初のタイミングをレイアウトと呼びます。続いて発生するノードのサイズと位置の再計算を再フロー呼びます。私たちの例では、画像が返される前に最初のレイアウトが発生すると考えられます。画像のサイズを宣言していなかったため、画像のサイズがわかるとすぐに再フローが発生します。
-
-描画
-
-クリティカルレンダリングパスの最後のステップは個別のノードをスクリーンに描画することです。最初に発生する描画を first meaningful paint と呼びます。描画またはラスタライズのフェーズにおいて、ブラウザーはレイアウトフェーズで計算されたそれぞれのボックスをスクリーン上の実際のピクセルに変換します。描画は、テキスト、色、境界、シャドウ、ボタンや画像のような置換要素を含む、要素のすべての視覚的な部分をスクリーンに描くことを含みます。ブラウザーはこれを超高速で実行する必要があります。
-
-スムーズなスクロールとアニメーションを実現するために、スタイルの計算や再フロー、描画などメインスレッドを占有するすべての処理は、16.67ms 未満で完了する必要があります。2048 x 1536 の解像度を持つ iPad は 3,145,000 を超えるピクセルを持っています。それら大量のピクセルは高速に描画されなければいけません。２回目以降の描画を最初の描画より高速にするため、スクリーンへの描画は一般的に複数のレイヤーに分解されます。この場合に合成が必要になります。
-
-描画は描画ツリー内の要素をレイヤーに分解します。コンテンツを GPU (CPU 上のメインスレッドの代わりになる) 上のレイヤーに昇格させることで、描画と再描画のパフォーマンスを向上します。<video> <canvas> opacitytransform will-change
-
-レイヤーはパフォーマンスを改善しますが、メモリー管理の面ではコストのかかる処理です。そのため、ウェブのパフォーマンス最適化戦略の中で濫用するべきものではありません。
-
-合成
-
-ドキュメントのセクションが異なるレイヤーに描画されて重なり合う場合、コンテンツをスクリーン上に正しい順番で描画するために合成が必要になります。
-
-ページがアセットの読み込みを続ける間も再フローは発生します (後ほど出てくる図を見てください)。再フローは再描画と再合成を引き起こします。画像のサイズを指定していた場合再フローは必要ありません。再描画が必要なレイヤーのみが再描画され、必要があれば合成が行われます。しかし、私たちのサンプルでは画像のサイズを指定しませんでした。画像がサーバーから取得されたとき、レンダリングプロセスはレイアウトステップまで戻り、そこから再開します。
-
-操作可能性
-
-メインスレッドがページの描画を完了したら「これで終わり」と思うかもしれません。しかし、必ずしもそうとは言えません。読み込み処理が、遅延された onload
-
-{{glossary('Time to Interactive')}} (TTI) は、DNS ルックアップと SSL コネクション を始める最初のリクエストからページが操作可能になるまでどのくらい時間がかかったかを示す測定値です。操作可能であるとは、ページがユーザーの操作に 50ms 以内に応答する {{glossary('First Contentful Paint')}} の後の時点を言います。メインスレッドがパース処理、コンパイル、JavaScript の実行に占有されている場合、ユーザーの操作にタイムリーに (50ms より早く) 応答することができません。
-
-以下の例では、画像の読み込みは高速かもしれませんが、anotherscript.js ファイルが 2MB あり、しかもユーザーのネットワークは低速です。このケースでは、ユーザーはページのコンテンツをすぐに見ることができるかもしれませんが、スクリプトがダウンロードされるまでスクロールを実行できない可能性があります。これは良いユーザー体験とは言えません。この WebPageTest の例からわかるように、メインスレッドを占有することは避けなければいけません。
-
-
-
-この例では、DOM コンテンツの読み込みプロセスは 1.5 秒以上かかっており、メインスレッドがすべての時間を完全に占有され、クリックイベントや画面のタップに応答できなくなっています。
-
-関連情報
-
-
diff --git a/files/ja/web/performance/how_browsers_work/index.md b/files/ja/web/performance/how_browsers_work/index.md
new file mode 100644
index 00000000000000..6ac38eb0f87a25
--- /dev/null
+++ b/files/ja/web/performance/how_browsers_work/index.md
@@ -0,0 +1,217 @@
+---
+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
+---
+ユーザーは、読み込みが速く、スムーズに操作できるコンテンツを、ウェブで体験することを求めています。したがって、開発者はこれらふたつの目標を達成するために努力しなければいけません。
+
+どうやって性能そして体感性能を改善するか理解するためには、ブラウザーがどのように動作するかを理解することが役に立ちます。
+
+## 概要
+
+速いサイトはより良いユーザー体験をもたらします。ユーザーは読み込みが速く、スムーズに操作できるコンテンツを体験することを求め、期待しています。
+
+ウェブの性能における 2 つの主要な課題は、レイテンシーに関する諸問題と、多くの場合ブラウザーはシングルスレッドであるという事実に関する諸問題を理解することです。
+
+レイテンシーは、速い読み込みを実現するために克服しなければいけない一番の脅威です。読み込みを速くしようとする開発者のゴールは、リクエストされた情報をできる限り速く送信すること、または少なくともとても速いように見せることです。ネットワークのレイテンシーは、バイト情報をコンピューターまで送信するのにかかる時間のことです。ウェブの性能は、ページの読み込みを出来る限り速くするよう私たちが何をするかにかかっています。
+
+多くの場合、ブラウザーはシングルスレッドだと考えられます。スムーズな操作を実現しようとする開発者のゴールは、滑らかなスクロール、タッチ操作への反応など、期待通りのサイトの操作を実現することです。メインスレッドが全ての処理を時間内に完了し、その上でユーザーの操作を常にハンドリングできるよう保証するために、描画時間が鍵となります。ブラウザーがシングルスレッドであることによる特性を理解し、メインスレッドの責務を最小限に抑え、可能かつ適切な場合に、描画のスムーズさと操作への即時の反応を実現することで、ウェブの性能が改善されます。
+
+## ナビゲーション
+
+*ナビゲーション*はウェブページを読み込むための最初の一歩です。ユーザーが URL をアドレスバーに入力したり、リンクをクリックしたり、またはフォームを送信したり、ページをリクエストするたびごとにナビゲーションが発生します。
+
+ウェブの性能における目標の 1 つは、ナビゲーションが完了するまでの時間を最小限にすることです。理想的な条件下において、一般的にこの時間が長すぎることはありませんが、レイテンシーと帯域幅が遅延を引き起こす邪魔者になる場合があります。
+
+### DNS ルックアップ
+
+ウェブページへのナビゲーションの最初の一歩は、ページのアセットがどこにあるか見つけることです。`https://example.com` へアクセスする場合、その HTML のページは IP アドレスが `93.184.216.34` のサーバーに存在します。これまでに一度もそのサイトを訪れたことがなかった場合、DNS ルックアップが必要になります。
+
+ブラウザーが DNS ルックアップをリクエストし、そのリクエストは最終的にネームサーバーによって処理され、ネームサーバーが IP アドレスを返します。この最初のリクエストの後、多くの場合その IP アドレスはしばらくの間キャッシュされ、ネームサーバーへ再接続する代わりにキャッシュから IP アドレスを取得することによって、後続するリクエストの速度を向上します。
+
+DNS ルックアップは、一般的に、1 回のページ読み込みの中でホスト名ごとに 1 回だけ必要になります。しかし、DNS ルックアップは要求されたページが参照するユニークなホストネームそれぞれに対して実行が必要です。必要なフォントや画像、スクリプト、広告、メトリクスのそれぞれが異なるホスト名を持っている場合は、それぞれに対して DNS ルックアップが必要です。
+
+
+
+これはとくにモバイルネットワークにおいて性能上の問題になる可能性があります。ユーザーがモバイルネットワークを利用している場合、DNS ルックアップは、権威 DNS サーバーへ到達するために、電話機から基地局へ送信される必要があります。電話機と基地局、そしてネームサーバー間の距離によって重大な遅延が発生する場合があります。
+
+### TCP ハンドシェイク
+
+IP アドレスが判明すると、ブラウザーは {{glossary('TCP handshake','TCP 3 ウェイハンドシェイク')}}を通じてサーバーとのコネクションを設定します。この仕組みは、通信を意図する 2 つの主体が—この場合はブラウザーとウェブサーバーが—、データを送信する前に、多くの場合 {{glossary('HTTPS')}} を用いて、ネットワーク TCP ソケットコネクションのパラメーターを交換できるよう設計されています。
+
+TCP の 3 ウェイハンドシェイクは、しばしば、"SYN-SYN-ACK"、より正確には SYN、SYN-ACK、ACK と呼ばれます。これは 2 つのコンピューターの間で TCP のセッションを開始するために、TCP によって 3 つのメッセージが送受信されることを表します。つまり、これはそれぞれのサーバーの間で 3 回以上のメッセージのやりとりが必要であり、そのためのリクエストが生成されなければいけないことを意味しています。
+
+### TLS ネゴシエーション
+
+HTTPS によって確立される安全なコネクションでは、もう 1 つのハンドシェイクが必要です。このハンドシェイク、より正確に言うと {{glossary('TLS')}} ネゴシエーションは、通信の暗号化に使用する暗号の種類を決定し、サーバーを認証し、実際のデータ送信が始まる前に安全な通信の準備を整えます。この処理は、コンテンツのリクエストを実際に送信する前に、さらに 3 回のラウンドトリップを必要とします。
+
+
+
+通信を安全にするためにページ読み込みの時間が追加されますが、ブラウザーとサーバーの間で送信されるデータが第三者に解読されないという安全な通信は、レイテンシーに見合う価値があるものです。
+
+8 回のラウンドトリップを経て、ブラウザーはようやくリクエストを送ることができます。
+
+## レスポンス
+
+ウェブサーバーへのコネクションが確立されると、ブラウザーはユーザーに代わって最初の [HTTP `GET` リクエスト](/ja/docs/Web/HTTP/Methods)を送信します。ウェブサイトであれば、多くの場合その対象は HTML ファイルです。リクエストを受け取ったサーバーは、適当なレスポンスヘッダーと HTML のコンテンツを返します。
+
+```html
+
+
+
+ My simple page
+ My Page
+ A paragraph with a link
+
+
+
`](/ja/docs/Web/HTML/Element/video) や[``](/ja/docs/Web/HTML/Element/canvas)など、レイヤーを生成する特定のプロパティと要素があります。[`opacity`](/ja/docs/Web/CSS/opacity)、3D [`transform`](/ja/docs/Web/CSS/transform)、[`will-change`](/ja/docs/Web/CSS/will-change)、その他いくつかの CSS プロパティを持つ要素も同様です。これらのノードは、その子孫が上記の理由でそれ自身のレイヤーを必要とするのでなければ、子孫と一緒に自身のレイヤー上に描画されます。
+
+レイヤーはパフォーマンスを改善しますが、メモリー管理の面ではコストのかかる処理です。そのため、ウェブのパフォーマンス最適化戦略の中で濫用するべきものではありません。
+
+### 合成
+
+ドキュメントのセクションが異なるレイヤーに描画されて重なり合う場合、コンテンツをスクリーン上に正しい順番で描画するために合成が必要になります。
+
+ページがアセットの読み込みを続ける間も再フローは発生します (後ほど出てくる図を見てください)。再フローは再描画と再合成を引き起こします。画像のサイズを指定していた場合再フローは必要ありません。再描画が必要なレイヤーのみが再描画され、必要があれば合成が行われます。しかし、私たちのサンプルでは画像のサイズを指定しませんでした。画像がサーバーから取得されたとき、レンダリングプロセスはレイアウトステップまで戻り、そこから再開します。
+
+## 操作可能性
+
+メインスレッドがページの描画を完了したら「これで終わり」と思うかもしれません。しかし、必ずしもそうとは言えません。読み込み処理が、遅延された [`onload`](/ja/docs/Web/API/GlobalEventHandlers/onload) イベントの発行により実行される JavaScript を含む場合、メインスレッドがビジー状態となりスクロールやタッチ、その他の操作ができない場合があります。
+
+{{glossary('Time to Interactive')}} (TTI) は、DNS ルックアップと SSL コネクション を始める最初のリクエストからページが操作可能になるまでどのくらい時間がかかったかを示す測定値です。操作可能であるとは、ページがユーザーの操作に 50ms 以内に応答する {{glossary('First Contentful Paint')}} の後の時点を言います。メインスレッドがパース処理、コンパイル、JavaScript の実行に占有されている場合、ユーザーの操作にタイムリーに (50ms より早く) 応答することができません。
+
+以下の例では、画像の読み込みは高速かもしれませんが、`anotherscript.js` ファイルが 2MB あり、しかもユーザーのネットワークは低速です。このケースでは、ユーザーはページのコンテンツをすぐに見ることができるかもしれませんが、スクリプトがダウンロードされるまでスクロールを実行できない可能性があります。これは良いユーザー体験とは言えません。この WebPageTest の例からわかるように、メインスレッドを占有することは避けなければいけません。
+
+
+
+この例では、DOM コンテンツの読み込みプロセスは 1.5 秒以上かかっており、メインスレッドがすべての時間を完全に占有され、クリックイベントや画面のタップに応答できなくなっています。
+
+## 関連情報
+
+- [ウェブパフォーマンス](/ja/docs/Web/Performance)
diff --git a/files/ja/web/performance/index.html b/files/ja/web/performance/index.html
deleted file mode 100644
index 1ec5e9cced5bae..00000000000000
--- a/files/ja/web/performance/index.html
+++ /dev/null
@@ -1,279 +0,0 @@
----
-title: ウェブパフォーマンス
-slug: Web/Performance
-tags:
- - API
- - App
- - App Performance
- - HTML
- - JavaScript
- - Landing
- - Mobile
- - Mobile Performance
- - Performance
- - Performance Budget
- - Start-Up Performance
- - Web
- - Web Performance
-translation_of: Web/Performance
----
-ウェブパフォーマンスは客観的な測定値と、読み込み時や実行時のユーザーエクスペリエンスの知覚状況から成ります。ウェブパフォーマンスとは、サイトが読み込まれるまでの時間、操作可能・応答可能になるまでの時間、そしてユーザーが操作する際のコンテンツのスムーズさを意味します。 スクロールはスムーズか、ボタンはクリックしやすいか、ポップアップはすぐに読み込まれて表示されるか、表示の際にスムーズにアニメーションするか。ウェブパフォーマンスには、読み込み時間、 1 秒あたりのフレーム数、操作可能になるまでの時間などの客観的な測定値と、コンテンツが読み込まれるまでにどのくらいの時間がかかったように感じたかという主観的な体験の両方が含まれます。
-
-サイトが応答するまでの時間が長ければ長いほど、ユーザーはそのサイトを放棄する傾向があります。読み込み時間と応答時間を最小限に抑え、さらに機能を追加して遅延を隠すことで、できるだけ早く、できるだけ利用可能でインタラクティブな体験を提供し、一方で、体験のロングテール部分では非同期的に読み込みを行うことが重要です。
-
-ウェブパフォーマンスの測定と改善に役立つツール、API、およびベストプラクティスがあります。 この章でそれらをカバーします。
-
-
-
-{{LandingPageListSubpages}}
-
-
-
-
初心者向けチュートリアル
-
-
MDN のウェブパフォーマンスの学習領域 には、パフォーマンスの基礎をカバーする最新のチュートリアルが含まれています。パフォーマンスについての初心者は、ここから始めてください。
-
-
- ウェブパフォーマンス: 短い概要 ウェブパフォーマンスの学習経路の概要です。ここから旅を始めましょう。
- ウェブパフォーマンスとは この記事では、パフォーマンスとは何かをよく理解することからモジュールを始めます。パフォーマンスについて考えるときに考慮すべきツール、指標、API、ネットワーク、人々のグループ、そしてウェブ開発のワークフローの一部としてパフォーマンスを活用する方法などを紹介します。
- ユーザーはパフォーマンスをどう知覚するのか
- ウェブサイトの速さをミリ秒単位で示すことよりも重要なのは、ユーザーがサイトの速さをどのように認識しているかということです。これらの認識は、実際のページロード時間、アイドリング、ユーザーインタラクションへの応答性、スクロールやその他のアニメーションのスムーズさに影響されます。この記事では、様々なロードメトリクス、アニメーション、応答性のメトリクスと、実際の時間ではなくてもユーザーの認識を改善するためのベストプラクティスについて説明します。
-
- ウェブパフォーマンスの基本 HTML、CSS、JavaScript、メディアファイルなどのフロントエンド部品に加えて、アプリケーションを遅くする機能と、主観的・客観的にアプリケーションを速くする機能があります。ウェブパフォーマンスに関連する API、開発者ツール、ベストプラクティス、バッドプラクティスは数多くあります。ここでは、これらの機能の多くを基本的なレベルで紹介し、それぞれのトピックについて、パフォーマンスを向上させるためのより深い考察へのリンクを提供します。
- HTML のパフォーマンス特性 マークアップの属性やソースの順序によっては、ウェブサイトのパフォーマンスに影響を与えることがあります。 DOM ノードの数を最小限に抑え、スタイル、スクリプト、メディア、サードパーティのスクリプトなどのコンテンツを含むために、最適な順序と属性を使用することで、ユーザーエクスペリエンスを劇的に向上させることができます。この記事では、最大限のパフォーマンスを確保するために HTML をどのように使用すればよいかを詳しく見ていきます。
- マルチメディア: 画像と動画 ウェブパフォーマンスの中で最も身近な位置にあるのは、メディアの最適化です。各ユーザーエージェントの能力、サイズ、ピクセル密度に応じて、異なるメディアファイルを提供することが可能です。また、バックグラウンドのビデオからオーディオトラックを削除するなどのヒントを加えると、さらにパフォーマンスが向上します。この記事では、動画、音声、画像のコンテンツがパフォーマンスに与える影響と、その影響をできるだけ小さくするための方法について説明します。
- CSS パフォーマンス特性 CSS は、パフォーマンス向上のための最適化の焦点としてはあまり重要ではないかもしれませんが、パフォーマンスに影響を与える CSS の機能はいくつかあります。この記事では、パフォーマンスに影響を与えるいくつかの CSS プロパティと、パフォーマンスに悪影響を与えないためのスタイルの処理方法を提案します。
- JavaScript パフォーマンスのベストプラクティス JavaScript は、適切に使用すればインタラクティブで没入感のあるウェブ体験を実現できますが、ダウンロード時間、レンダリング時間、アプリ内のパフォーマンス、バッテリー寿命、ユーザーエクスペリエンスを大きく損なう可能性があります。この記事では、複雑なコンテンツであっても可能な限りパフォーマンスを向上させるために考慮すべき JavaScript のベストプラクティスを紹介します。
- モバイルパフォーマンス モバイル端末でのウェブアクセスは非常に人気があり、すべてのモバイルプラットフォームには本格的なウェブブラウザーが搭載されていますが、帯域幅、CPU、バッテリーの寿命が限られている可能性があるため、これらのプラットフォームでのウェブコンテンツのパフォーマンスを考慮することが重要です。この記事では、モバイルに特化したパフォーマンスの考慮点について説明します。
-
-
-
-
-
-
用語集の用語
-
-
-
- {{glossary('Beacon')}}
- {{glossary('Brotli compression')}}
- {{glossary('Client hints')}}
- {{glossary('Code splitting')}}
- {{glossary('CSSOM')}}
- {{glossary('Domain sharding')}}
- {{glossary('Effective connection type')}}
- {{glossary('First contentful paint')}}
- {{glossary('First CPU idle')}}
- {{glossary('First input delay')}}
- {{glossary('First interactive')}}
- {{glossary('First meaningful paint')}}
- {{glossary('First paint')}}
- {{glossary('HTTP')}}
- {{glossary('HTTP_2', 'HTTP/2')}}
- {{glossary('Jank')}}
- {{glossary('Latency')}}
- {{glossary('Lazy load')}}
- {{glossary('Long task')}}
- {{glossary('Lossless compression')}}
- {{glossary('Lossy compression')}}
- {{glossary('Main thread')}}
- {{glossary('Minification')}}
- {{glossary('Network throttling')}}
- {{glossary('Packet')}}
- {{glossary('Page load time')}}
- {{glossary('Page prediction')}}
- {{glossary('Parse')}}
- {{glossary('Perceived performance')}}
- {{glossary('Prefetch')}}
- {{glossary('Prerender')}}
- {{glossary('QUIC')}}
- {{glossary('RAIL')}}
- {{glossary('Real User Monitoring')}}
- {{glossary('Resource Timing')}}
- {{glossary('Round Trip Time (RTT)')}}
- {{glossary('Server Timing')}}
- {{glossary('Speculative parsing')}}
- {{glossary('Speed index')}}
- {{glossary('SSL')}}
- {{glossary('Synthetic monitoring')}}
- {{glossary('TCP handshake')}}
- {{glossary('TCP slow start')}}
- {{glossary('Time to first byte')}}
- {{glossary('Time to interactive')}}
- {{glossary('TLS')}}
- {{glossary('TCP', 'Transmission Control Protocol (TCP)')}}
- {{glossary('Tree shaking')}}
- {{glossary('Web performance')}}
-
-
まだ書かれていない文書
-
-
- JavaScript performance best practices 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.
- Mobile performance 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.
- Web font performance
- 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.
- Performance bottlenecks
- Understanding bandwidth
- Bandwidth is the amount of data measured in Megabits(Mb) or Kilobits(Kb) that one can send per second. 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
- The role of TLS in performance
- 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.
- Reading performance charts
- Developer tools provide information on performance, memory, and network requests. Knowing how to read waterfall charts, call trees , traces, flame charts , and allocations in your browser developer tools will help you understand waterfall and flame charts in other performance tools.
- Alternative media formats
- 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.
- Analyzing JavaScript bundles
- 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 what you're using, as well how to detect if your app contains duplicated scripts between bundles.
- Lazy loading 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.
- Lazy-loading JavaScript with dynamic imports
- 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.
- Controlling resource delivery with resource hints 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.
- Performance Budgets 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.
- Web performance checklist 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.
- Mobile performance checklist A concise checklist of performance considerations impacting mobile network users on hand-held, battery operated devices.
-
-
-関連情報
-
-HTML
-
-
-
-CSS
-
-
- will-change GPU v CPU
- レイアウトの測定
- フォント読み込みのベストプラクティス
-
-
-JavaScript
-
-
-
-API
-
-
-
-ヘッダー
-
-
-
-ツール
-
-
-
-その他の指標
-
-
- スピードインデックスと知覚的スピードインデックス
-
-
-ベストプラクティス
-
-
diff --git a/files/ja/web/performance/index.md b/files/ja/web/performance/index.md
new file mode 100644
index 00000000000000..7ebfb53992625a
--- /dev/null
+++ b/files/ja/web/performance/index.md
@@ -0,0 +1,239 @@
+---
+title: ウェブパフォーマンス
+slug: Web/Performance
+tags:
+ - API
+ - App
+ - App Performance
+ - HTML
+ - JavaScript
+ - Landing
+ - Mobile
+ - Mobile Performance
+ - Performance
+ - Performance Budget
+ - Start-Up Performance
+ - Web
+ - Web Performance
+translation_of: Web/Performance
+---
+ウェブパフォーマンスは客観的な測定値と、読み込み時や実行時のユーザーエクスペリエンスの知覚状況から成ります。ウェブパフォーマンスとは、サイトが読み込まれるまでの時間、操作可能・応答可能になるまでの時間、そしてユーザーが操作する際のコンテンツのスムーズさを意味します。スクロールはスムーズか、ボタンはクリックしやすいか、ポップアップはすぐに読み込まれて表示されるか、表示の際にスムーズにアニメーションするか。ウェブパフォーマンスには、読み込み時間、 1 秒あたりのフレーム数、操作可能になるまでの時間などの客観的な測定値と、コンテンツが読み込まれるまでにどのくらいの時間がかかったように感じたかという主観的な体験の両方が含まれます。
+
+サイトが応答するまでの時間が長ければ長いほど、ユーザーはそのサイトを放棄する傾向があります。読み込み時間と応答時間を最小限に抑え、さらに機能を追加して遅延を隠すことで、できるだけ早く、できるだけ利用可能でインタラクティブな体験を提供し、一方で、体験のロングテール部分では非同期的に読み込みを行うことが重要です。
+
+ウェブパフォーマンスの測定と改善に役立つツール、API、およびベストプラクティスがあります。 この章でそれらをカバーします。
+
+## キーパフォーマンスガイド
+
+{{LandingPageListSubpages}}
+
+## 初心者向けチュートリアル
+
+MDN の[ウェブパフォーマンスの学習領域](/ja/docs/Learn/Performance)には、パフォーマンスの基礎をカバーする最新のチュートリアルが含まれています。パフォーマンスについての初心者は、ここから始めてください。
+
+- [ウェブパフォーマンス: 短い概要](/ja/docs/Learn/Performance/What_is_web_performance)
+ - : ウェブパフォーマンスの学習経路の概要です。ここから旅を始めましょう。
+- [ウェブパフォーマンスとは](/ja/docs/Learn/Performance/What_is_web_performance)
+ - : この記事では、パフォーマンスとは何かをよく理解することからモジュールを始めます。パフォーマンスについて考えるときに考慮すべきツール、指標、API、ネットワーク、人々のグループ、そしてウェブ開発のワークフローの一部としてパフォーマンスを活用する方法などを紹介します。
+- [ユーザーはパフォーマンスをどう知覚するのか](/ja/docs/Learn/Performance/perceived_performance)
+ - : ウェブサイトの速さをミリ秒単位で示すことよりも重要なのは、ユーザーがサイトの速さをどのように認識しているかということです。これらの認識は、実際のページロード時間、アイドリング、ユーザーインタラクションへの応答性、スクロールやその他のアニメーションのスムーズさに影響されます。この記事では、様々なロードメトリクス、アニメーション、応答性のメトリクスと、実際の時間ではなくてもユーザーの認識を改善するためのベストプラクティスについて説明します。
+- [ウェブパフォーマンスの基本](/ja/docs/Learn/Performance/Web_Performance_Basics)
+ - : HTML、CSS、JavaScript、メディアファイルなどのフロントエンド部品に加えて、アプリケーションを遅くする機能と、主観的・客観的にアプリケーションを速くする機能があります。ウェブパフォーマンスに関連する API、開発者ツール、ベストプラクティス、バッドプラクティスは数多くあります。ここでは、これらの機能の多くを基本的なレベルで紹介し、それぞれのトピックについて、パフォーマンスを向上させるためのより深い考察へのリンクを提供します。
+- [HTML のパフォーマンス特性](/ja/docs/Learn/Performance/HTML)
+ - : マークアップの属性やソースの順序によっては、ウェブサイトのパフォーマンスに影響を与えることがあります。 DOM ノードの数を最小限に抑え、スタイル、スクリプト、メディア、サードパーティのスクリプトなどのコンテンツを含むために、最適な順序と属性を使用することで、ユーザーエクスペリエンスを劇的に向上させることができます。この記事では、最大限のパフォーマンスを確保するために HTML をどのように使用すればよいかを詳しく見ていきます。
+- [マルチメディア: 画像と動画](/ja/docs/Learn/Performance/Multimedia)
+ - : ウェブパフォーマンスの中で最も身近な位置にあるのは、メディアの最適化です。各ユーザーエージェントの能力、サイズ、ピクセル密度に応じて、異なるメディアファイルを提供することが可能です。また、バックグラウンドのビデオからオーディオトラックを削除するなどのヒントを加えると、さらにパフォーマンスが向上します。この記事では、動画、音声、画像のコンテンツがパフォーマンスに与える影響と、その影響をできるだけ小さくするための方法について説明します。
+- [CSS パフォーマンス特性](/ja/docs/Learn/Performance/CSS)
+ - : CSS は、パフォーマンス向上のための最適化の焦点としてはあまり重要ではないかもしれませんが、パフォーマンスに影響を与える CSS の機能はいくつかあります。この記事では、パフォーマンスに影響を与えるいくつかの CSS プロパティと、パフォーマンスに悪影響を与えないためのスタイルの処理方法を提案します。
+- [JavaScript パフォーマンスのベストプラクティス](/ja/docs/Learn/Performance/JavaScript)
+ - : JavaScript は、適切に使用すればインタラクティブで没入感のあるウェブ体験を実現できますが、ダウンロード時間、レンダリング時間、アプリ内のパフォーマンス、バッテリー寿命、ユーザーエクスペリエンスを大きく損なう可能性があります。この記事では、複雑なコンテンツであっても可能な限りパフォーマンスを向上させるために考慮すべき JavaScript のベストプラクティスを紹介します。
+- [モバイルパフォーマンス](/ja/docs/Learn/Performance/Mobile)
+ - : モバイル端末でのウェブアクセスは非常に人気があり、すべてのモバイルプラットフォームには本格的なウェブブラウザーが搭載されていますが、帯域幅、CPU、バッテリーの寿命が限られている可能性があるため、これらのプラットフォームでのウェブコンテンツのパフォーマンスを考慮することが重要です。この記事では、モバイルに特化したパフォーマンスの考慮点について説明します。
+
+## パフォーマンス API の使用
+
+- [Performance API](/ja/docs/Web/API/Performance_API/Using_the_Performance_API)
+ - : このガイドでは、 [`Performance`](/ja/docs/Web/API/Performance "Performance インターフェイスは、現在のページのパフォーマンス関連情報へのアクセスを提供します。これは、 High Resolution Time API の一部ですが、Performance Timeline API、Navigation Timing API、User Timing API、Resource Timing API によって拡張されています。") インターフェイスの使い方を説明します。これは [High-Resolution Time](https://w3c.github.io/hr-time/) 標準で定義されているものです。
+- [Resource Timing API](/ja/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API)
+ - : [リソースの読み込みとそのタイミング](/ja/docs/Web/API/Resource_Timing_API)です。リソースバッファの管理や CORS への対応なども含みます。
+- [パフォーマンスタイムライン](/ja/docs/Web/API/Performance_Timeline/Using_Performance_Timeline)
+ - : [Performance Timeline](/ja/docs/Web/API/Performance_Timeline) 標準は、アプリケーション内のクライアントサイドのレイテンシー測定をサポートする [`Performance`](/ja/docs/Web/API/Performance "Performance インターフェイスは、現在のページのパフォーマンス関連情報へのアクセスを提供します。これは、 High Resolution Time API の一部ですが、Performance Timeline API、Navigation Timing API、User Timing API、Resource Timing API によって拡張されています。") インターフェイスの拡張機能を定義しています。これらのインターフェイスを併用することで、アプリケーションのパフォーマンスのボトルネックを特定するのに役立ちます。
+- [User Timing API](/ja/docs/Web/API/User_Timing_API/Using_the_User_Timing_API)
+ - : アプリケーション固有のタイムスタンプを生成するために、 [user timing API](/ja/docs/Web/API/User_Timing_API) の "mark" および "measure" の種類の項目を使用します。これらはブラウザーのパフォーマンスタイムラインの一部です。
+- [Frame Timing API](/ja/docs/Web/API/Frame_Timing_API/Using_the_Frame_Timing_API)
+ - : [`PerformanceFrameTiming`](/ja/docs/Web/API/PerformanceFrameTiming) インターフェイスは、ブラウザーのイベントループに関する*フレーム*のタイミングデータを提供します。
+- [Beacon API](/ja/docs/Web/API/Beacon_API)
+ - : [Beacon](/ja/docs/Web/API/Beacon_API) インターフェイスは、ウェブサーバーへの非同期かつブロックされないリクエストをスケジューリングします。
+- [Intersection Observer API](/ja/docs/Web/API/Intersection_Observer_API/Timing_element_visibility)
+ - : [Intersection Observer API](/ja/docs/Web/API/Intersection_Observer_API) を使って要素が見えるようになることを時間的に測定し、関心のある要素が可視化されたときに非同期に通知を受けることができます。
+
+## その他の文書
+
+- [開発者ツールのパフォーマンス機能](/ja/docs/Tools/Performance)
+ - : この節では、[ウォーターフォール](/ja/docs/Tools/Performance/Waterfall)、[コールツリー](/ja/docs/Tools/Performance/Call_Tree)、[フレイムチャート](/ja/docs/Tools/Performance/Flame_Chart)など、開発者ツールのパフォーマンス機能の使い方と理解について説明します。
+- [組み込みプロファイラーによるプロファイル](/ja/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler)
+ - : Learn how to profile app performance with Firefox's built-in profiler.
+
+## 用語集の用語
+
+- {{glossary('Beacon')}}
+- {{glossary('Brotli compression')}}
+- {{glossary('Client hints')}}
+- {{glossary('Code splitting')}}
+- {{glossary('CSSOM')}}
+- {{glossary('Domain sharding')}}
+- {{glossary('Effective connection type')}}
+- {{glossary('First contentful paint')}}
+- {{glossary('First CPU idle')}}
+- {{glossary('First input delay')}}
+- {{glossary('First interactive')}}
+- {{glossary('First meaningful paint')}}
+- {{glossary('First paint')}}
+- {{glossary('HTTP')}}
+- {{glossary('HTTP_2', 'HTTP/2')}}
+- {{glossary('Jank')}}
+- {{glossary('Latency')}}
+- {{glossary('Lazy load')}}
+- {{glossary('Long task')}}
+- {{glossary('Lossless compression')}}
+- {{glossary('Lossy compression')}}
+- {{glossary('Main thread')}}
+- {{glossary('Minification')}}
+- {{glossary('Network throttling')}}
+- {{glossary('Packet')}}
+- {{glossary('Page load time')}}
+- {{glossary('Page prediction')}}
+- {{glossary('Parse')}}
+- {{glossary('Perceived performance')}}
+- {{glossary('Prefetch')}}
+- {{glossary('Prerender')}}
+- {{glossary('QUIC')}}
+- {{glossary('RAIL')}}
+- {{glossary('Real User Monitoring')}}
+- {{glossary('Resource Timing')}}
+- {{glossary('Round Trip Time (RTT)')}}
+- {{glossary('Server Timing')}}
+- {{glossary('Speculative parsing')}}
+- {{glossary('Speed index')}}
+- {{glossary('SSL')}}
+- {{glossary('Synthetic monitoring')}}
+- {{glossary('TCP handshake')}}
+- {{glossary('TCP slow start')}}
+- {{glossary('Time to first byte')}}
+- {{glossary('Time to interactive')}}
+- {{glossary('TLS')}}
+- {{glossary('TCP', 'Transmission Control Protocol (TCP)')}}
+- {{glossary('Tree shaking')}}
+- {{glossary('Web performance')}}
+
+## まだ書かれていない文書
+
+- [JavaScript performance best practices](/ja/docs/Learn/Performance/JavaScript)
+ - : 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.
+- [Mobile performance](/ja/docs/Learn/Performance/Mobile)
+ - : 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.
+- Web font performance
+ - : 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.
+- Performance bottlenecks
+ - : ...
+- Understanding bandwidth
+ - : Bandwidth is the amount of data measured in Megabits(Mb) or Kilobits(Kb) that one can send per second. 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
+- The role of TLS in performance
+ - : 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.
+- Reading performance charts
+ - : Developer tools provide information on performance, memory, and network requests. Knowing how to read [waterfall](/ja/docs/Tools/Performance/Waterfall) charts, [call trees](/ja/docs/Tools/Performance/Call_Tree), traces, [flame charts](/ja/docs/Tools/Performance/Flame_Chart) , and [allocations](/ja/docs/Tools/Performance/Allocations) in your browser developer tools will help you understand waterfall and flame charts in other performance tools.
+- Alternative media formats
+ - : 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.
+- Analyzing JavaScript bundles
+ - : 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 _what_ you're using, as well how to detect if your app contains duplicated scripts between bundles.
+- [Lazy loading](/ja/docs/Web/Performance/Lazy_loading)
+ - : 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.
+- Lazy-loading JavaScript with dynamic imports
+ - : 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.
+- [Controlling resource delivery with resource hints](/ja/docs/Web/Performance/Controlling_resource_delivery_with_resource_hints)
+ - : 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.
+- [Performance Budgets](/ja/docs/Web/Performance/Performance_budgets)
+ - : 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.
+- [Web performance checklist](/ja/docs/Web/Performance/Checklist)
+ - : 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.
+- [Mobile performance checklist](/ja/docs/Web/Performance/Mobile_performance_checklist)
+ - : A concise checklist of performance considerations impacting mobile network users on hand-held, battery operated devices.
+
+## 関連情報
+
+HTML
+
+- [`` 要素](/ja/docs/Web/HTML/Element/picture)
+- [`` 要素](/ja/docs/Web/HTML/Element/video)
+- [`` 要素](/ja/docs/Web/HTML/Element/source)
+- [`このページには、さまざまなチュートリアルとトレーニング用教材へのリンクがあります。これからウェブ開発を始めようとしている方、基礎を学ぼうとしている方、ウェブ開発に慣れている方など、ベストプラクティスを学習するのに役立つ教材をここで見つけることができます。
-
-これらの教材は、先見の明のある企業やウェブ開発者が、オープン標準やウェブ開発のベストプラクティスを支持して、クリエティブ・コモンズなどのオープンコンテンツライセンスに準じて提供や翻訳を許可しています。
-
-ウェブについて全くの初心者の人たちへ
-
-
- ウェブ入門 ウェブ入門 は、実用的なウェブ開発の入門シリーズです。まずはじめに、簡単なウェブページを作るのに必要なツールを準備します。そして、簡単なコードを書いたら、それを実際にウェブに公開します。
-
-HTML チュートリアル
-
-入門レベル
-
-
- HTML 入門 HTML とは何か、HTML がどのように動くか、HTML の簡単な歴史について、HTML 文書の構造がどのようなものかを解説します。次に、HTML の構成部分をそれぞれ詳細に見ていきます。
- MDN HTML 要素リファレンス HTML 要素の包括的なリファレンスです。ブラウザーごとの対応状況も分かります。
-
-
-
- Creating a Simple Web Page with HTML (英語)この HTML ガイドは、初心者向けに HTML5 タグを含めた、よくあるタグを紹介しています。また、段階ごとに基本的なウェブページを作成するためのコード例を載せています。
- HTML Challenges (英語)問題に挑戦し HTML のスキルを磨きましょう。マークアップが意味のあるものになっているか (例: <h2> か <strong> のどちらをを使うべきか) がポイントです。
-
-
-
-
-
- マルチメディアと埋め込み このモジュールでは、ウェブページに、HTML をどのようにして用いればマルチメディアを含むことができるかについて学びます。また、画像を挿入するためのさまざまな方法や、どのようにして動画・音声、そして他のウェブページ全体を挿入するのかについても触れています。
-
-
-
- HTML 表 ウェブページにおいて、表の形のデータを理解可能な形、そしてアクセシビリティに配慮した形で表現することは少し難しいでしょう。このモジュールは、基本的な表のマークアップ、そしてさらに注や要約を付加など、もっと複雑な機能を扱います。
-
-
-上級レベル
-
-
- HTML フォーム HTML フォームは、ウェブの重要な部品です。フォームは多くの機能を提供し、ユーザーがウェブサイトとやり取りする際に必要なものとなっています。例えば登録、ログイン、フィードバックの送信、商品の購入、などなど。このモジュールではフォームのクライアント側の部分を作成するところから始めます。
-
-
-
- 読み込みが速い HTML ページを作成するヒント ウェブページを最適化することでサイト表示の待ち時間を短くし、サーバーとインターネット接続経路の負荷を軽減する方法を学ぶことができます。
-
-
-CSS チュートリアル
-
-入門レベル
-
-
- CSS の基本 CSS (Cascading Style Sheets) は、ウェブページのスタイルを設定するコードです。CSS の基本ではあなたが始めるのに必要なものを紹介します。私たちは次のような質問に答えます：テキストを黒または赤にするにはどうすればいいですか？ そのような場所でコンテンツを画面に表示させるにはどうすればよいですか？ 背景画像と色を使ってウェブページをどのように飾るのですか？
- CSS 入門 CSS (Cascading Style Sheets) は、ウェブページのスタイルづけやレイアウトに使用されます。例えば、コンテンツのフォント、色、サイズ、間隔を変更したり、複数の段に分割したり、アニメーションやその他の装飾機能を追加したりすることができます。このモジュールでは、 CSS がどのように機能するか、どのような構文になっているか、そして HTML にスタイルを追加するためにどのように使い始めるか、といった基本的な内容で、 CSS マスターへの道を順番に始めます。
-
-
-
- CSS の構成要素
- このモジュールは CSS 入門 の続きです。言語とその構文に慣れ、基本的な使用方法を身につけたところで、もう少し深く掘り下げてみましょう。このモジュールでは、カスケードと継承、利用可能なすべてのセレクターの種類、単位、サイズ調整、背景や境界線のスタイル、デバッグなどについて学びます。
-
- このモジュールの目的は、有能な CSS を書くためのツールキットを提供し、
テキストのスタイル付け や CSS レイアウト などのより具体的な分野に進む前に、すべての基本的な理論を理解してもらうことです。
-
- テキストのスタイル付け ここでは、フォント、太字、イタリック体、線、文字間隔、影、その他のテキストの機能の設定を含むテキストのスタイル付けの基礎を確認します。ページにカスタムフォントを適用し、リストとリンクにスタイルを適用することでこのモジュールを締めくくります。
- CSS に関するよくある質問 初心者から寄せられるよくある質問とその回答です。
-
-
-
-
-
- CSS レイアウト この時点で、 CSS の基本、テキストスタイルの設定方法、コンテンツが内部にあるボックスのスタイルと操作方法については説明を終えています。今度は、ボックスを表示領域に関連して適切な場所に配置する方法を見てみましょう。必要な堰堤条件についてはすでに終えているので、 CSS のレイアウト、様々な display の設定、浮動 (float) と位置指定 (positioning) を含む従来のレイアウト方法、フレックスボックスのような新しいレイアウトツールなどについて詳しく調べることができます。
- CSS リファレンス CSS の完全なリファレンスです。Firefox やその他のブラウザーの対応の詳細もあります。
-
-
-
- 流動グリッド 前からある植字用のグリッドを使いながら、ブラウザーのウィンドウに合わせて可変的にリサイズするレイアウトを設計することができます。
- CSS Challenges (英語)CSS スキルを確認し、何を勉強すべきかを知ることができます。
-
-
-上級レベル
-
-
- CSS 変換の使用 CSS を使って、回転、傾き、拡大、縮小、移動を行います。
- CSS トランジション CSS3 草稿の仕様の一部である CSS トランジションでは、即時に変化させるのではなく、CSS のプロパティで時間的に連続して変化させることができます。
-
-
-
- @font-face によるウェブフォント指定のクイックガイド CSS3 の @font-face 機能を使うと、ウェブ上にある独自の書体を使うことができます。使いやすく、フォントの操作、拡大縮小が可能です。
- CSS を書き始める 簡潔で保守が容易、スケーラブルな CSS を書くためのツールや方法論の紹介です。
-
-
-
- Canvas チュートリアル canvas 要素を使用するスクリプトを書いてグラフィックを描く方法を学ぶことができます。
- HTML5 Doctor HTML5 をすぐに使うための記事があります。
-
-
-Javascript チュートリアル
-
-入門レベル
-
-
- JavaScript の第一歩 最初の JavaScript のモジュールでは、初めて JavaScript を書く実践的な体験をしていただく前に「JavaScript とは何？」や「どのように見える？」や「何ができる？」といったような基本的な質問に答えます。その後 JavaScript を理解する重要な特徴、たとえば変数や文字列、数値、配列などについてお話します。
- JavaScript の構成要素 このモジュールでは、条件付きステートメント、ループ、関数、イベントなど一般的に発生するコードブロックの種類に注目し、JavaScript の重要な基本機能をすべてカバーしていきます。これまでの勉強で詰め込み、とおりすぎてしまっているかもしれませんが、ここではすべて明示的に説明を行います。
-
-
-
- JavaScript を始める JavaScript とは何か? 何の役に立つのかを学べます。
- Codecademy Codecademy では簡単に JavaScript コーディングの方法を学べます。対話形式で学習でき、友人と一緒に進めることができます。
- freeCodeCamp (英語)では、ウェブ開発のための様々な言語やフレームワークを教えています。フォーラム 、インターネットラジオ局 、ブログ もあります。
-
-
-
-
-
- JavaScript オブジェクトの紹介 JavaScript では、文字列や配列などの JavaScript のコア機能から、JavaScript の上に構築されたブラウザー API まで、ほとんどのものがオブジェクトです。関連する関数や変数を効率的なパッケージにカプセル化する独自のオブジェクトを作成することもできます。 JavaScript のオブジェクト指向の性質を理解することは、言語に関する知識をさらに深め、より効率的なコードを書く場合に重要です。したがって、このモジュールを用意しました。ここではオブジェクトの理論と構文を詳しく説明し、独自のオブジェクトを作成する方法を見て、JSON のデータとその使い方を説明します。
- クライアント側 Web API ウェブサイトやアプリケーションのためにクライアント側 JavaScript を書くとき、API (様々なブラウザーやサイトを動かしている OS 、さらに他のウェブサイトやサービスのデータを操作するインターフェイス) の使用が不可欠です。このモジュールでは、API とはどういったものかや開発の多くで使われる最もよくある API の使い方を調べられます。
-
-
-
- JavaScript 「再」入門 中級レベルの開発者向けの JavaScript プログラム言語復習用まとめです。
- Eloquent JavaScript JavaScript の中級・上級の方法論への包括的ガイドです。
- Speaking JavaScript (英語)JavaScript の学習をすばやく正確に学びたいプログラマーや特定のトピックスを探したり、スキルを上げたいプログラマーのためのサイトです。
- Essential JavaScript Design Patterns (英語)JavaScript デザイン パターンの真髄に触れてみましょう。
-
-
-上級レベル
-
-
- JavaScript ガイド 初心者から上級者まですべてのレベル向けの分かりやすい JavaScript ガイドです。定期的に更新されています。
- You Don't Know JS (英語)このシリーズは、JavaScript のコアなメカニズムを深める本です。
- JavaScript Garden (英語)JavaScript で最もはまりやすい部分をドキュメント化したものです。
- Exploring ES6 (英語)ECMAScript 2015 の信頼できる詳しい情報元です。
-
-
-
- JavaScript Patterns (英語)Javascript のパターンと不適切な例であるアンチパターンを集めたものです。関数パターン、jQuery パターン、jQuery プラグイン パターン、デザイン パターン、よくあるパターン、リテラルおよびコンストラクター パターン、オブジェクト生成パターン、コード再利用パターン、DOM をカバーしています。
- How browsers work モダンブラウザーのエンジンやページレンダリングなどの違いが詳しく研究され、説明された論文です。
- JavaScript Videos (GitHub)見ておきたい JavaScript についての映像を集めたものです。
-
-
-拡張機能の開発
-
-
- WebExtensions WebExtensions は、ブラウザーのアドオンを開発するための、ブラウザー間互換システムです。多くの部分において、このシステムは Google Chrome や Opera が対応している拡張機能 API と大体において互換性があります。これらのブラウザー用に書かれたアドオンは大抵の場合、 Firefox や Microsoft Edge でも ほんの少し変更を加えるだけで 、動かすことができます。この API はマルチプロセス Firefox とも完全な互換性があります。
-
diff --git a/files/ja/web/tutorials/index.md b/files/ja/web/tutorials/index.md
new file mode 100644
index 00000000000000..3654460036ae94
--- /dev/null
+++ b/files/ja/web/tutorials/index.md
@@ -0,0 +1,184 @@
+---
+title: チュートリアル
+slug: Web/Tutorials
+tags:
+ - CSS
+ - GitHub
+ - HTML
+ - JavaScript
+ - MDN
+ - ウェブ記事
+ - ウェブ開発
+ - ガイド
+ - コード
+ - チュートリアル
+ - ブラウザー
+ - 初心者
+translation_of: Web/Tutorials
+---
+このページには、さまざまなチュートリアルとトレーニング用教材へのリンクがあります。これからウェブ開発を始めようとしている方、基礎を学ぼうとしている方、ウェブ開発に慣れている方など、ベストプラクティスを学習するのに役立つ教材をここで見つけることができます。
+
+これらの教材は、先見の明のある企業やウェブ開発者が、オープン標準やウェブ開発のベストプラクティスを支持して、クリエティブ・コモンズなどのオープンコンテンツライセンスに準じて提供や翻訳を許可しています。
+
+## ウェブについて全くの初心者の人たちへ
+
+- [ウェブ入門](/ja/docs/Learn/Getting_started_with_the_web)
+ - : *ウェブ入門*は、実用的なウェブ開発の入門シリーズです。まずはじめに、簡単なウェブページを作るのに必要なツールを準備します。そして、簡単なコードを書いたら、それを実際にウェブに公開します。
+
+## HTML チュートリアル
+
+### 入門レベル
+
+- [HTML 入門](/ja/docs/Learn/HTML/Introduction_to_HTML)
+ - : HTML とは何か、HTML がどのように動くか、HTML の簡単な歴史について、HTML 文書の構造がどのようなものかを解説します。次に、HTML の構成部分をそれぞれ詳細に見ていきます。
+- **[MDN HTML 要素リファレンス](/ja/docs/Web/HTML/Element)**
+ - : HTML 要素の包括的なリファレンスです。ブラウザーごとの対応状況も分かります。
+
+
+
+- **[Creating a Simple Web Page with HTML](https://www.theblogstarter.com/html-for-beginners) (英語)**
+ - : この HTML ガイドは、初心者向けに HTML5 タグを含めた、よくあるタグを紹介しています。また、段階ごとに基本的なウェブページを作成するためのコード例を載せています。
+- **[HTML Challenges](https://wikiversity.org/wiki/Web_Design/HTML_Challenges) (英語)**
+ - : 問題に挑戦し HTML のスキルを磨きましょう。マークアップが意味のあるものになっているか (例: \ か \ のどちらをを使うべきか) がポイントです。
+
+### 中級レベル
+
+- [マルチメディアと埋め込み](/ja/docs/Learn/HTML/Multimedia_and_embedding)
+ - : このモジュールでは、ウェブページに、HTML をどのようにして用いればマルチメディアを含むことができるかについて学びます。また、画像を挿入するためのさまざまな方法や、どのようにして動画・音声、そして他のウェブページ全体を挿入するのかについても触れています。
+
+
+
+- [HTML 表](/ja/docs/Learn/HTML/Tables)
+ - : ウェブページにおいて、表の形のデータを理解可能な形、そしてアクセシビリティに配慮した形で表現することは少し難しいでしょう。このモジュールは、基本的な表のマークアップ、そしてさらに注や要約を付加など、もっと複雑な機能を扱います。
+
+### 上級レベル
+
+- [HTML フォーム](/ja/docs/Learn/Forms)
+ - : HTML フォームは、ウェブの重要な部品です。フォームは多くの機能を提供し、ユーザーがウェブサイトとやり取りする際に必要なものとなっています。例えば登録、ログイン、フィードバックの送信、商品の購入、などなど。このモジュールではフォームのクライアント側の部分を作成するところから始めます。
+
+
+
+- **[読み込みが速い HTML ページを作成するヒント](/ja/docs/Learn/HTML/Howto/Author_fast-loading_HTML_pages)**
+ - : ウェブページを最適化することでサイト表示の待ち時間を短くし、サーバーとインターネット接続経路の負荷を軽減する方法を学ぶことができます。
+
+## CSS チュートリアル
+
+### 入門レベル
+
+- [CSS の基本](/ja/docs/Learn/Getting_started_with_the_web/CSS_basics)
+ - : CSS (Cascading Style Sheets) は、ウェブページのスタイルを設定するコードです。CSS の基本ではあなたが始めるのに必要なものを紹介します。私たちは次のような質問に答えます：テキストを黒または赤にするにはどうすればいいですか？ そのような場所でコンテンツを画面に表示させるにはどうすればよいですか？ 背景画像と色を使ってウェブページをどのように飾るのですか？
+- [CSS 入門](/ja/docs/Learn/CSS/First_steps)
+ - : CSS (Cascading Style Sheets) は、ウェブページのスタイルづけやレイアウトに使用されます。例えば、コンテンツのフォント、色、サイズ、間隔を変更したり、複数の段に分割したり、アニメーションやその他の装飾機能を追加したりすることができます。このモジュールでは、 CSS がどのように機能するか、どのような構文になっているか、そして HTML にスタイルを追加するためにどのように使い始めるか、といった基本的な内容で、 CSS マスターへの道を順番に始めます。
+
+
+
+- [CSS の構成要素](/ja/docs/Learn/CSS/Building_blocks)
+
+ - : このモジュールは [CSS 入門](/ja/docs/Learn/CSS/First_steps)の続きです。言語とその構文に慣れ、基本的な使用方法を身につけたところで、もう少し深く掘り下げてみましょう。このモジュールでは、カスケードと継承、利用可能なすべてのセレクターの種類、単位、サイズ調整、背景や境界線のスタイル、デバッグなどについて学びます。
+
+ このモジュールの目的は、有能な CSS を書くためのツールキットを提供し、
+
+- [テキストのスタイル付け](/ja/docs/Learn/CSS/Styling_text)や [CSS レイアウト](/ja/docs/Learn/CSS/CSS_layout)などのより具体的な分野に進む前に、すべての基本的な理論を理解してもらうことです。
+
+ [テキストのスタイル付け](/ja/docs/Learn/CSS/Styling_text)
+
+ - : ここでは、フォント、太字、イタリック体、線、文字間隔、影、その他のテキストの機能の設定を含むテキストのスタイル付けの基礎を確認します。ページにカスタムフォントを適用し、リストとリンクにスタイルを適用することでこのモジュールを締めくくります。
+
+- [CSS に関するよくある質問](/ja/docs/Learn/CSS/Howto/CSS_FAQ)
+ - : 初心者から寄せられるよくある質問とその回答です。
+
+### 中級レベル
+
+- [CSS レイアウト](/ja/docs/Learn/CSS/CSS_layout)
+ - : この時点で、 CSS の基本、テキストスタイルの設定方法、コンテンツが内部にあるボックスのスタイルと操作方法については説明を終えています。今度は、ボックスを表示領域に関連して適切な場所に配置する方法を見てみましょう。必要な堰堤条件についてはすでに終えているので、 CSS のレイアウト、様々な display の設定、浮動 (float) と位置指定 (positioning) を含む従来のレイアウト方法、フレックスボックスのような新しいレイアウトツールなどについて詳しく調べることができます。
+- **[CSS リファレンス](/ja/docs/Web/CSS/Reference)**
+ - : CSS の完全なリファレンスです。Firefox やその他のブラウザーの対応の詳細もあります。
+
+
+
+- **[流動グリッド](https://www.alistapart.com/articles/fluidgrids/)**
+ - : 前からある植字用のグリッドを使いながら、ブラウザーのウィンドウに合わせて可変的にリサイズするレイアウトを設計することができます。
+- **[CSS Challenges](https://en.wikiversity.org/wiki/Web_Design/CSS_challenges) (英語)**
+ - : CSS スキルを確認し、何を勉強すべきかを知ることができます。
+
+### 上級レベル
+
+- **[CSS 変換の使用](/ja/docs/Web/CSS/CSS_Transforms/Using_CSS_transforms)**
+ - : CSS を使って、回転、傾き、拡大、縮小、移動を行います。
+- [CSS トランジション](/ja/docs/Web/CSS/CSS_Transitions/Using_CSS_transitions)
+ - : CSS3 草稿の仕様の一部である CSS トランジションでは、即時に変化させるのではなく、CSS のプロパティで時間的に連続して変化させることができます。
+
+
+
+- [@font-face によるウェブフォント指定のクイックガイド](https://www.html5rocks.com/tutorials/webfonts/quick/)
+ - : CSS3 の @font-face 機能を使うと、ウェブ上にある独自の書体を使うことができます。使いやすく、フォントの操作、拡大縮小が可能です。
+- [CSS を書き始める](https://davidwalsh.name/starting-css)
+ - : 簡潔で保守が容易、スケーラブルな CSS を書くためのツールや方法論の紹介です。
+
+
+
+- [Canvas チュートリアル](/ja/docs/Web/API/Canvas_API/Tutorial)
+ - : canvas 要素を使用するスクリプトを書いてグラフィックを描く方法を学ぶことができます。
+- **[HTML5 Doctor](https://html5doctor.com/)**
+ - : HTML5 をすぐに使うための記事があります。
+
+## Javascript チュートリアル
+
+### 入門レベル
+
+- [JavaScript の第一歩](/ja/docs/Learn/JavaScript/First_steps)
+ - : 最初の JavaScript のモジュールでは、初めて JavaScript を書く実践的な体験をしていただく前に「JavaScript とは何？」や「どのように見える？」や「何ができる？」といったような基本的な質問に答えます。その後 JavaScript を理解する重要な特徴、たとえば変数や文字列、数値、配列などについてお話します。
+- [JavaScript の構成要素](/ja/docs/Learn/JavaScript/Building_blocks)
+ - : このモジュールでは、条件付きステートメント、ループ、関数、イベントなど一般的に発生するコードブロックの種類に注目し、JavaScript の重要な基本機能をすべてカバーしていきます。これまでの勉強で詰め込み、とおりすぎてしまっているかもしれませんが、ここではすべて明示的に説明を行います。
+
+
+
+- [JavaScript を始める](/ja/docs/Learn/Getting_started_with_the_web/JavaScript_basics)
+ - : JavaScript とは何か? 何の役に立つのかを学べます。
+- **[Codecademy](https://www.codecademy.com/)** (英語)
+ - : Codecademy では簡単に JavaScript コーディングの方法を学べます。対話形式で学習でき、友人と一緒に進めることができます。
+- [freeCodeCamp](https://learn.freecodecamp.org/) (英語)
+ - : では、ウェブ開発のための様々な言語やフレームワークを教えています。[フォーラム](https://freecodecamp.org/forum)、[インターネットラジオ局](https://coderadio.freecodecamp.org)、[ブログ](https://freecodecamp.org/news)もあります。
+
+### 中級レベル
+
+- [JavaScript オブジェクトの紹介](/ja/docs/Learn/JavaScript/Objects)
+ - : JavaScript では、文字列や配列などの JavaScript のコア機能から、JavaScript の上に構築されたブラウザー API まで、ほとんどのものがオブジェクトです。関連する関数や変数を効率的なパッケージにカプセル化する独自のオブジェクトを作成することもできます。 JavaScript のオブジェクト指向の性質を理解することは、言語に関する知識をさらに深め、より効率的なコードを書く場合に重要です。したがって、このモジュールを用意しました。ここではオブジェクトの理論と構文を詳しく説明し、独自のオブジェクトを作成する方法を見て、JSON のデータとその使い方を説明します。
+- [クライアント側 Web API](/ja/docs/Learn/JavaScript/Client-side_web_APIs)
+ - : ウェブサイトやアプリケーションのためにクライアント側 JavaScript を書くとき、API (様々なブラウザーやサイトを動かしている OS 、さらに他のウェブサイトやサービスのデータを操作するインターフェイス) の使用が不可欠です。このモジュールでは、API とはどういったものかや開発の多くで使われる最もよくある API の使い方を調べられます。
+
+
+
+- **[JavaScript 「再」入門](/ja/docs/Web/JavaScript/A_re-introduction_to_JavaScript)**
+ - : 中級レベルの開発者向けの JavaScript プログラム言語復習用まとめです。
+- **[Eloquent JavaScript](https://eloquentjavascript.net/)** (英語)
+ - : JavaScript の中級・上級の方法論への包括的ガイドです。
+- **[Speaking JavaScript](http://speakingjs.com/es5/) (英語)**
+ - : JavaScript の学習をすばやく正確に学びたいプログラマーや特定のトピックスを探したり、スキルを上げたいプログラマーのためのサイトです。
+- [Essential JavaScript Design Patterns](https://www.addyosmani.com/resources/essentialjsdesignpatterns/book/) (英語)
+ - : JavaScript デザイン パターンの真髄に触れてみましょう。
+
+### 上級レベル
+
+- [JavaScript ガイド](/ja/docs/Web/JavaScript/Guide)
+ - : 初心者から上級者まですべてのレベル向けの分かりやすい JavaScript ガイドです。定期的に更新されています。
+- **[You Don't Know JS](https://github.com/getify/You-Dont-Know-JS) (英語)**
+ - : このシリーズは、JavaScript のコアなメカニズムを深める本です。
+- **[JavaScript Garden](https://bonsaiden.github.io/JavaScript-Garden/) (英語)**
+ - : JavaScript で最もはまりやすい部分をドキュメント化したものです。
+- **[Exploring ES6](https://exploringjs.com/es6/) (英語)**
+ - : ECMAScript 2015 の信頼できる詳しい情報元です。
+
+
+
+- **[JavaScript Patterns](http://shichuan.github.io/javascript-patterns) (英語)**
+ - : Javascript のパターンと不適切な例であるアンチパターンを集めたものです。関数パターン、jQuery パターン、jQuery プラグイン パターン、デザイン パターン、よくあるパターン、リテラルおよびコンストラクター パターン、オブジェクト生成パターン、コード再利用パターン、DOM をカバーしています。
+- **[How browsers work](https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/)** (英語)
+ - : モダンブラウザーのエンジンやページレンダリングなどの違いが詳しく研究され、説明された論文です。
+- [JavaScript Videos](https://github.com/bolshchikov/js-must-watch) (GitHub)
+ - : 見ておきたい JavaScript についての映像を集めたものです。
+
+### 拡張機能の開発
+
+- [WebExtensions](/ja/docs/Mozilla/Add-ons/WebExtensions)
+ - : WebExtensions は、ブラウザーのアドオンを開発するための、ブラウザー間互換システムです。多くの部分において、このシステムは Google Chrome や Opera が対応している[拡張機能 API](https://developer.chrome.com/extensions) と大体において互換性があります。これらのブラウザー用に書かれたアドオンは大抵の場合、 Firefox や [Microsoft Edge](https://developer.microsoft.com/en-us/microsoft-edge/platform/documentation/extensions/) でも [ほんの少し変更を加えるだけで](https://extensionworkshop.com/documentation/develop/porting-a-google-chrome-extension/)、動かすことができます。この API は[マルチプロセス Firefox](/ja/docs/Mozilla/Firefox/Multiprocess_Firefox) とも完全な互換性があります。
diff --git a/files/ja/web/webdriver/index.html b/files/ja/web/webdriver/index.html
deleted file mode 100644
index 1773f89a6678e3..00000000000000
--- a/files/ja/web/webdriver/index.html
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: WebDriver
-slug: Web/WebDriver
-tags:
- - Automation
- - Index
- - Landing
- - Reference
- - Testing
- - Web
- - WebDriver
- - 自動化
-translation_of: Web/WebDriver
----
-WebDriver は、ユーザーエージェントの観察と制御を可能にする遠隔制御インターフェイスです。プロセスの外のプログラムがウェブブラウザーの動作を遠隔で指示する方法として、プラットフォームと言語に中立なワイヤープロトコルを提供します。
-
-ユーザーに一貫した使い勝手を提供するには、異なるプラットフォーム上の多くのブラウザーで相互に実行できる命令セットを書くことができることが重要です。ウェブプラットフォームでの新しい開発の波、端末の多様性の増加、テクノロジー間の実際の相互運用性の要求を背景に、 WebDriver はクロスブラウザーテスト のためののツールを提供します。
-
-提供されるものは、ウェブ文書内の DOM 要素を検出したり操作したり、ユーザーエージェントの動作を制御したりするためのインターフェイスです。これは主に、ユーザーエージェントを別な制御プロセスから自動制御するテストを、ウェブ作者が書くことができるようにすることが目的ですが、場合によってはブラウザー内のスクリプトが — おそらく他の — ブラウザーを制御するために使用することもできます。
-
-使い方
-
-それでは、 WebDriver で何が実現でき、どのように見えるのでしょうか。 WebDriver はプログラミング言語に中立なので、この質問に対する答えは、使用している WebDriver クライアント と言語の選択によって異なります。
-
-しかし、 Python で書かれた有名なクライアントを使用すると、 WebDriver との対話は次のようになるでしょう。
-
-from selenium import webdriver
-from selenium.webdriver.common.by import By
-from selenium.webdriver.common.keys import Keys
-from selenium.webdriver.support.ui import WebDriverWait
-from selenium.webdriver.support.expected_conditions import presence_of_element_located
-
-wait = WebDriverWait(driver, 10)
-
-with webdriver.Firefox() as driver:
- driver.get("http://google.com/ncr")
- driver.find_element_by_name("q").send_keys("cheese" + Keys.RETURN)
-
- wait.until(presence_of_element_located((By.CSS_SELECTOR, "h3>a")))
-
- results = driver.find_elements_by_css_selector("h3>a")
- for i, result in results.iteritems():
- print("#{}: {} ({})".format(i, result.text, result.get_property("href")))
-
-これは次のような出力結果になります。
-
-#1 Cheese - Wikipedia (https://en.wikipedia.org/wiki/Cheese)
-
-
-リファレンス
-
-
-
-
-
-
{{ListSubpages("/ja/docs/Web/WebDriver/Commands")}}
-
-
-
-
-
-
-
-
-
-
{{ListSubpages("/ja/docs/Web/WebDriver/Capabilities")}}
-
-
-
-
{{ListSubpages("/ja/docs/Web/WebDriver/Errors")}}
-
-
仕様書
-
-
-
-
- 仕様書
- 状態
- 備考
-
-
- {{SpecName('WebDriver')}}
- {{Spec2('WebDriver')}}
- 初回定義
-
-
-
-
-ブラウザーの互換性
-
-{{Compat("webdriver", 2)}}
-
-関連情報
-
-
-
-{{QuickLinksWithSubpages}}
diff --git a/files/ja/web/webdriver/index.md b/files/ja/web/webdriver/index.md
new file mode 100644
index 00000000000000..9e979f53cf39e3
--- /dev/null
+++ b/files/ja/web/webdriver/index.md
@@ -0,0 +1,89 @@
+---
+title: WebDriver
+slug: Web/WebDriver
+tags:
+ - Automation
+ - Index
+ - Landing
+ - Reference
+ - Testing
+ - Web
+ - WebDriver
+ - 自動化
+translation_of: Web/WebDriver
+---
+WebDriver は、ユーザーエージェントの観察と制御を可能にする遠隔制御インターフェイスです。プロセスの外のプログラムがウェブブラウザーの動作を遠隔で指示する方法として、プラットフォームと言語に中立なワイヤープロトコルを提供します。
+
+ユーザーに一貫した使い勝手を提供するには、異なるプラットフォーム上の多くのブラウザーで相互に実行できる命令セットを書くことができることが重要です。ウェブプラットフォームでの新しい開発の波、端末の多様性の増加、テクノロジー間の実際の相互運用性の要求を背景に、 WebDriver は[クロスブラウザーテスト](/ja/Learn/Tools_and_testing/Cross_browser_testing/Introduction)のためののツールを提供します。
+
+提供されるものは、ウェブ文書内の DOM 要素を検出したり操作したり、ユーザーエージェントの動作を制御したりするためのインターフェイスです。これは主に、ユーザーエージェントを別な制御プロセスから自動制御するテストを、ウェブ作者が書くことができるようにすることが目的ですが、場合によってはブラウザー内のスクリプトが — おそらく他の — ブラウザーを制御するために使用することもできます。
+
+## 使い方
+
+それでは、 WebDriver で何が実現でき、どのように見えるのでしょうか。 WebDriver はプログラミング言語に中立なので、この質問に対する答えは、[使用している WebDriver クライアント](/ja/docs/Web/WebDriver/Clients)と言語の選択によって異なります。
+
+しかし、 Python で書かれた有名なクライアントを使用すると、 WebDriver との対話は次のようになるでしょう。
+
+```
+from selenium import webdriver
+from selenium.webdriver.common.by import By
+from selenium.webdriver.common.keys import Keys
+from selenium.webdriver.support.ui import WebDriverWait
+from selenium.webdriver.support.expected_conditions import presence_of_element_located
+
+wait = WebDriverWait(driver, 10)
+
+with webdriver.Firefox() as driver:
+ driver.get("http://google.com/ncr")
+ driver.find_element_by_name("q").send_keys("cheese" + Keys.RETURN)
+
+ wait.until(presence_of_element_located((By.CSS_SELECTOR, "h3>a")))
+
+ results = driver.find_elements_by_css_selector("h3>a")
+ for i, result in results.iteritems():
+ print("#{}: {} ({})".format(i, result.text, result.get_property("href")))
+```
+
+これは次のような出力結果になります。
+
+```
+#1 Cheese - Wikipedia (https://en.wikipedia.org/wiki/Cheese)
+```
+
+## リファレンス
+
+### [コマンド](/ja/docs/Web/WebDriver/Commands)
+
+{{ListSubpages("/ja/docs/Web/WebDriver/Commands")}}
+
+### [種類](/ja/docs/Web/WebDriver/Types)
+
+- [Error object](/ja/docs/Web/WebDriver/Errors#payload)
+- [Timeouts object](/ja/docs/Web/WebDriver/Timeouts)
+- [WebElement](/ja/docs/Web/WebDriver/WebElement)
+- [WebWindow](/ja/docs/Web/WebDriver/WebWindow)
+
+### [能力](/ja/docs/Web/WebDriver/Capabilities)
+
+{{ListSubpages("/ja/docs/Web/WebDriver/Capabilities")}}
+
+### [エラー](/ja/docs/Web/WebDriver/Errors)
+
+{{ListSubpages("/ja/docs/Web/WebDriver/Errors")}}
+
+## 仕様書
+
+| 仕様書 | 状態 | 備考 |
+| -------------------------------- | ---------------------------- | -------- |
+| {{SpecName('WebDriver')}} | {{Spec2('WebDriver')}} | 初回定義 |
+
+## ブラウザーの互換性
+
+{{Compat("webdriver", 2)}}
+
+## 関連情報
+
+- [クロスブラウザーテスト](/ja/docs/Learn/Tools_and_testing/Cross_browser_testing)
+- [Selenium documentation](https://seleniumhq.github.io/docs/) (制作中)
+
+{{QuickLinksWithSubpages}}
diff --git a/files/ja/web/xml/index.html b/files/ja/web/xml/index.html
deleted file mode 100644
index 7881523f70e757..00000000000000
--- a/files/ja/web/xml/index.html
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: 'XML: Extensible Markup Language'
-slug: Web/XML
-tags:
- - Draft
- - Landing
- - NeedsTranslation
- - TopicStub
- - Web
- - XML
-translation_of: Web/XML
----
-{{QuickLinksWithSubpages("/en-US/docs/Web/XML")}}
-
-The Extensible Markup Language is a strict serialisation of the Document Object Model .
-
-{{LandingPageListSubpages}}
diff --git a/files/ja/web/xml/index.md b/files/ja/web/xml/index.md
new file mode 100644
index 00000000000000..7017dedcba9ef1
--- /dev/null
+++ b/files/ja/web/xml/index.md
@@ -0,0 +1,17 @@
+---
+title: 'XML: Extensible Markup Language'
+slug: Web/XML
+tags:
+ - Draft
+ - Landing
+ - NeedsTranslation
+ - TopicStub
+ - Web
+ - XML
+translation_of: Web/XML
+---
+{{QuickLinksWithSubpages("/en-US/docs/Web/XML")}}
+
+The **Extensible Markup Language** is a strict serialisation of the [Document Object Model](/ja/docs/Web/API/Document_Object_Model).
+
+{{LandingPageListSubpages}}
diff --git a/files/ja/web/xml/xml_introduction/index.html b/files/ja/web/xml/xml_introduction/index.html
deleted file mode 100644
index a09d63f221d9b4..00000000000000
--- a/files/ja/web/xml/xml_introduction/index.html
+++ /dev/null
@@ -1,157 +0,0 @@
----
-title: XML のイントロダクション
-slug: Web/XML/XML_Introduction
-tags:
- - XML
- - イントロダクション
- - 初心者
-translation_of: Web/XML/XML_introduction
----
-XML は HTML に似たマークアップ言語です。 これは Extensible Markup Language の略で、汎用マークアップ言語として W3C が推奨する 仕様です。つまり、他のマークアップ言語とは異なり、XML は事前定義されていないため、独自のタグを定義する必要があります。この言語の主な目的は、インターネットなどのさまざまなシステム間でデータを共有することです。
-
-XML に基づいた言語はたくさんあります。XHTML 、MathML 、SVG 、XUL 、XBL 、RSS 、RDF などがあります。 あなた自身のものを作ることもできます。
-
-XML 文書構造
-
-
-
-XML および XML ベースの言語の全体の構造は {{Glossary("tag")}} に基づいています。
-
-XML 宣言
-
-XML 宣言はタグではありません。文書の送信メタデータに使用しました。
-
-<?xml version="1.0" encoding="UTF-8"?>
-
-属性:
-
-
- version :
- この文書で使用されている XML のバージョン
- encoding :
- この文書で使用されているエンコーディング。
-
-
-コメント
-
-<!-- Comment -->
-
-"正しい" XML (妥当であり、整形式であること)
-
-正しいデザインルール
-
-XML 文書を正しくするには、次の条件を満たす必要があります。
-
-
- 文書は整形式でなければなりません。
- 文書はすべての XML 構文規則に準拠している必要があります。
- 文書は、通常 XML スキーマまたは DTD (文書型定義 ) で設定されているセマンティックルールに準拠する必要があります。
-
-
-例
-
-<?xml version="1.0" encoding="UTF-8"?>
-< message> < warning> </ message> 整形式に適合した正しい例は以下です。
-
-<?xml version="1.0" encoding="UTF-8"?>
-< message> < warning> </ warning> </ message> 未定義のタグを含む文書は無効です。たとえば、<warning> タグを定義しなかった場合、上記の文書は無効になります。
-
-
-
ほとんどのブラウザは、形式が不適切な XML 文書を識別できるデバッガを提供しています。
-
エンティティ
-
-HTML と同様に、XML には特別な予約文字 (タグに使用される大なり記号など) を参照するための (エンティティと呼ばれる) メソッドがあります。知っておくべきこれらの文字は5つあります。
-
-
-
-
- エンティティ
- 文字
- 説明
-
-
-
-
- <
- <
- 小なり記号
-
-
- >
- >
- 大なり記号
-
-
- &
- &
- アンパサンド
-
-
- "
- "
- 二重引用符
-
-
- '
- '
- 1つのアポストロフィ (または単一引用符)
-
-
-
-
-宣言されたエンティティは5つしかありませんが、ドキュメントの Document Type Definition を使用して追加することができます。たとえば、新しい &warning; エンティティを作成する場合。このようにして行うことができます：
-
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE body [
- <!ENTITY warning "Warning: Something bad happened... please refresh and try again.">
-]>
-< body> < message> &warning; </ message> </ body> 数字参照を使用して特殊文字を指定することもできます。 たとえば、© は "©" 記号です。
-
-XML の表示
-
-XML は説明のためにたいてい用いられますが、XML データを表示するための方法があります。その方法を定義しなければ、生の XML コードがブラウザに表示されます。
-
-XML ページに見た目を持たせる方法の一つは、xml-stylesheet 宣言で CSS を用いることです。
-
-<?xml-stylesheet type="text/css" href="stylesheet.css"?>
-
-XML を表示するもう1つのより強力な方法もあります。XSL を HTML などの他の言語に変換するために使用できるExtensible Stylesheet Language Transformation (XSLT ) です。 これにより、XML は非常に用途が広くなります。
-
-<?xml-stylesheet type="text/xsl" href="transform.xsl"?>
-
-推奨
-
-この記事は、XML の概要についてごく簡単に紹介したもので、始めるためのいくつかの小さな例と参照が含まれています。XML の詳細については、Web でもっと詳細な記事を調べてください。
-
-ハイパーテキストマークアップ言語 (HTML ) を学ぶと、XML をよりよく理解するのに役立ちます。
-
-あわせて参照
-
-
-
-上記の Using XML の記事は、あなた自身の言語を変換したり作成したりするための情報に関する素晴らしいリソースです。
diff --git a/files/ja/web/xml/xml_introduction/index.md b/files/ja/web/xml/xml_introduction/index.md
new file mode 100644
index 00000000000000..3423f4dcf36851
--- /dev/null
+++ b/files/ja/web/xml/xml_introduction/index.md
@@ -0,0 +1,132 @@
+---
+title: XML のイントロダクション
+slug: Web/XML/XML_Introduction
+tags:
+ - XML
+ - イントロダクション
+ - 初心者
+translation_of: Web/XML/XML_introduction
+---
+概要: この記事は、'eXtensible Markup Language' (XML、拡張可能マークアップ言語) を紹介し、その使い道について XML は HTML に似たマークアップ言語です。 これは Extensible Markup Language の略で、汎用マークアップ言語として [W3C が推奨する](https://www.w3.org/TR/xml/)仕様です。つまり、他のマークアップ言語とは異なり、XML は事前定義されていないため、独自のタグを定義する必要があります。この言語の主な目的は、インターネットなどのさまざまなシステム間でデータを共有することです。
+
+XML に基づいた言語はたくさんあります。[XHTML](/ja/docs/XHTML)、[MathML](/ja/docs/Web/MathML)、[SVG](/ja/docs/Web/SVG)、[XUL](/ja/docs/Mozilla/Tech/XUL)、[XBL](/ja/docs/XBL)、[RSS](/ja/docs/Archive/RSS)、[RDF](/ja/docs/RDF) などがあります。 あなた自身のものを作ることもできます。
+
+## XML 文書構造
+
+> **Warning:** このサブ記事は執筆中です...
+
+XML および XML ベースの言語の全体の構造は {{Glossary("tag")}} に基づいています。
+
+### XML 宣言
+
+XML 宣言はタグではありません。文書の送信メタデータに使用しました。
+
+```
+
+```
+
+#### 属性:
+
+- version :
+ - : この文書で使用されている XML のバージョン
+- encoding :
+ - : この文書で使用されているエンコーディング。
+
+### コメント
+
+```
+
+```
+
+## "正しい" XML (妥当であり、整形式であること)
+
+### 正しいデザインルール
+
+XML 文書を正しくするには、次の条件を満たす必要があります。
+
+- 文書は整形式でなければなりません。
+- 文書はすべての XML 構文規則に準拠している必要があります。
+- 文書は、通常 XML スキーマまたは DTD ([文書型定義](/ja/docs/Glossary/DTD)) で設定されているセマンティックルールに準拠する必要があります。
+
+### 例
+
+```xml
+
+
+
+ Hello World
+
+
+```
+
+整形式に適合した正しい例は以下です。
+
+```xml
+
+
+
+ Hello World
+
+
+```
+
+未定義のタグを含む文書は無効です。たとえば、`` タグを定義しなかった場合、上記の文書は無効になります。
+
+> **Note:** ほとんどのブラウザは、形式が不適切な XML 文書を識別できるデバッガを提供しています。
+
+## エンティティ
+
+HTML と同様に、XML には特別な予約文字 (タグに使用される大なり記号など) を参照するための (エンティティと呼ばれる) メソッドがあります。知っておくべきこれらの文字は 5 つあります。
+
+| エンティティ | 文字 | 説明 |
+| ------------ | ---- | --------------------------------------- |
+| \< | < | 小なり記号 |
+| \> | > | 大なり記号 |
+| \& | & | アンパサンド |
+| \" | " | 二重引用符 |
+| \' | ' | 1 つのアポストロフィ (または単一引用符) |
+
+宣言されたエンティティは 5 つしかありませんが、ドキュメントの [Document Type Definition](/ja/docs/Glossary/DTD) を使用して追加することができます。たとえば、新しい `&warning;` エンティティを作成する場合。このようにして行うことができます：
+
+```html
+
+
+]>
+
+ &warning;
+
+```
+
+数字参照を使用して特殊文字を指定することもできます。 たとえば、\© は "©" 記号です。
+
+## XML の表示
+
+XML は説明のためにたいてい用いられますが、XML データを表示するための方法があります。その方法を定義しなければ、生の XML コードがブラウザに表示されます。
+
+XML ページに見た目を持たせる方法の一つは、`xml-stylesheet` 宣言で [CSS](/ja/docs/Web/CSS) を用いることです。
+
+```
+
+```
+
+XML を表示するもう 1 つのより強力な方法もあります。XSL を HTML などの他の言語に変換するために使用できる Extensible Stylesheet Language Transformation ([XSLT](/ja/docs/Web/XSLT)) です。 これにより、XML は非常に用途が広くなります。
+
+```
+
+```
+
+## 推奨
+
+この記事は、XML の概要についてごく簡単に紹介したもので、始めるためのいくつかの小さな例と参照が含まれています。XML の詳細については、Web でもっと詳細な記事を調べてください。
+
+ハイパーテキストマークアップ言語 ([HTML](/ja/docs/Web/HTML)) を学ぶと、XML をよりよく理解するのに役立ちます。
+
+## あわせて参照
+
+- [XML.com](http://www.xml.com/)
+- [Extensible Markup Language (XML) @ W3.org](https://www.w3.org/XML/)
+- [XML Example: A List Apart](http://www.alistapart.com/d/usingxml/xml_uses_a.html)
+- [Using XML: A List Apart](http://www.alistapart.com/articles/usingxml/)
+
+上記の [Using XML](http://www.alistapart.com/articles/usingxml/) の記事は、あなた自身の言語を変換したり作成したりするための情報に関する素晴らしいリソースです。
+