` タグのリンクの先読みにも対応するようになるかもしれません。そうすれば、コンテンツ提供者が先読みリンクを更新し忘れるという問題を回避しやすくなるでしょう。
-
-### リンクの先読み機能は標準に準拠していますか?
-
-はい。ここで述べているリンクの先読み機能は、既存のウェブ標準に違反していません。実際、HTML 4.01 仕様書では新たなリンク形式の定義が明確に許されています([Section 6.12: Link types を参照](http://www.w3.org/TR/html4/types.html#type-links))。しかし、Mozilla で採用した手法自体はまだ標準化されていません。 Internet Draft を現在準備中です。
-
-この手法の標準化は HTML5 の範囲の一部です。現在のワーキングドラフトの [section §5.11.3.13. Link type "prefetch"](https://www.whatwg.org/specs/web-apps/current-work/#link-type-prefetch) を参照してください。
-
-### ブラウザーのアイドル時間はどのように判定されますか?
-
-現在の実装（Mozilla 1.2）では、アイドル時間は `nsIWebProgressListener` API を用いて判定されます。トップレベルの `nsIWebProgress` オブジェクトにリスナーを追加しました（"@[mozilla.org/docloaderservice;1](http://mozilla.org/docloaderservice;1)"）。このリスナーから、文書の開始と停止の通知を受け取って、前の文書の停止と次の文書の開始の間の時間をアイドル時間として概算します。前の文書の停止通知は、大まかに言って、トップレベル文書の onLoad ハンドラが起動した時に行われます。この時が先読みリクエストを行う時になります。サブフレームが先読みのヒントを含む場合にも、先読みは最上位のフレームとその「子」フレームの読み込みが終了するまで始まりません。
-
-### 先読みの取得中に別のリンクをクリックするとどうなりますか?
-
-ユーザーがリンクをクリックしたり、何らかの種類のページ読み込みを発生させたりすると、先読みは停止し、先読みのヒントは捨てられます。先読みしている文書が部分的にダウンロードされている場合は、途中までの文書をサーバから送られた "Accept-Ranges: bytes" レスポンスヘッダー付きでキャッシュに蓄積されます。このヘッダーは、大抵、ウェブサーバが静的なコンテンツを提供する際に生成するものです。ユーザーが先読みした文書を実際に訪問する際には、その文書の残りの部分を HTTP の byte-range リクエストを使って取得します。
-
-### バックグラウンドで何かをダウンロードしている場合はどうですか? リンクの先読み機能は回線容量を奪い合いますか?
-
-「イエス」であり、「ノー」でもあります。まず、Mozilla を使って何かをダウンロードしている場合は、全てのダウンロードが終わるまでリンクの先読み機能を遅らせます。例えば、ブックマーク・グループを読み込んでいる（複数のタブを開く）場合には、そのブックマークされたページで発生した先読みリクエストは、全てのタブがロードし終わるまで、開始されません。一方、別のアプリケーションがネットワークを使っている場合は、Mozilla のリンクの先読みはその他のアプリケーションと回線容量を奪い合います。将来的には、ネットワークのアイドル時間を監視するオペレーティングシステムのサービスを利用して、この問題を解決したいと思っています
-
-### 先読みできるものに何か制限はありますか?
-
-はい。 (と Gecko 1.9.1 からは )URL だけが先読み可能です。（FTP などの）その他のプロトコルはクライアントサイドのキャッシュへの対応が十分でありません。
-
-### Mozilla は別のホストからも文書を先読みしますか?
-
-はい。先読みには、 同一オリジン (same-origin) についての制限はありません。リンクの先読みを同一サーバの URL に限定したとしても、ブラウザーのセキュリティ向上にはならないでしょうから。
-
-### 先読みのリクエストには Referer: ヘッダーが付きますか?
-
-はい。先読みリクエストには、どの文書から先読みヒントを取ったかを示す、HTTP の `Referer:` ヘッダーが付きます。
-
-このことは、多くのサイトで広く行われている参照元の追跡に影響するかもしれません。このため、リンクの先読みは全てのコンテンツに対して向くものではないかもしれません。そこで、`Cache-control: must-revalidate` HTTP レスポンスヘッダーを指定することにより、ユーザーが先読みされた文書へのリンクを辿った際に、Mozilla にその先読みされた文書を検証させることができるようにしています。このヘッダーが使われると、キャッシュは有効なままですが、ブラウザーのキャッシュから文書を取り出す前には、`If-Modified-Since` もしくは `If-None-Match` の検証用リクエストが必要になります。
-
-### サーバ管理者ですが、先読みのリクエストを通常のリクエストと区別する方法はありますか?
-
-はい。先読みのリクエストには、次のようなヘッダーが付きます。
-
-```
-X-moz: prefetch
-```
-
-もちろん、このリクエストヘッダーは全く標準化されていないものですので、将来の Mozilla リリースでは変更される可能性もあります。
-
-### リンクの先読み機能を無効化する設定はありますか?
-
-はい。リンクの先読み機能を無効化できる隠し設定があります。 あなたのプロファイルディレクトリにある prefs.js ファイルに次の行を追加してください（もしくは、about:config 経由で変更してください）。
-
-```
-user_pref("network.prefetch-next", false);
-```
-
-しかし、リンクの先読み機能を無効にしたいという場合には、この先読みの実装に何か不具合があるのではないかと思います。我々としては、不具合がある場合には、ユーザーに設定ユーザーインターフェイスの中から目立たない設定項目を探させて変更させるよりも、実装を改善したいと思っています。
-
-### ネットワーク回線を従量制課金で使っている人たちについてはどうですか?
-
-基本的には、この問題は二つの観点から見ることができます。ウェブサイトでは既に JavaScript や DOM 等の小技を使って、暗黙のダウンロードが行われていること。先読みはブラウザーの機能の一つであり、ユーザーが簡単に無効化できるようにしておくべきだということです。
-
-ウェブサイトで JavaScript や DOM の色々な小技を使用して暗黙にダウンロードをどんどん進めようとする代わりに、 `` タグを使った先読みを採用してもらうことが重要です。 `` タグにより、ブラウザーはどのサイトが最新であるかを知ることができ、文書の先読みの優先順序をより良く付けることができます。ユーザー設定で `` タグによる先読みを無効化できるようにすると、単に JavaScript や DOM による小技を推奨させることにつながり、ユーザーにとって良い結果にはなり m 差円。先読み機能が既定で有効なのは、このためです。
-
-### どのブラウザーがリンクの先読み機能に対応していますか?
-
-Mozilla 1.2 以降ベースおよび Mozilla 1.0.2 以降ベースのブラウザーが先読み機能に対応しています。これには Netscape 7.01 以降と Phoenix ビルドも含まれます。 2003 年 3 月現在の Chimera ビルドは Mozilla 1.0.1 ベースですので、先読み機能に対応していません。あなたのブラウザーがリンクの先読みに対応しているかどうか[テスト](http://gemal.dk/browserspy/prefetch.php)できます。
-
-### プライバシーとの関わり
-
-参照元と URL の追跡との関係はすでに上記で説明されているとおりであり、先読みは一般的に先読みサイトの Cookie へのアクセスを引き起こします。（例えば、 amazon を Google で検索するとき、 Google の結果ページは www\.amazon.com google.co.jp で検索した場合は www\.amazon.co.jp を先読みし、ブラウザーに Cookie が送られてきます。 Firefox で サードパーティの Cookie をブロックするには、[Disabling third party cookies](http://support.mozilla.com/kb/Disabling+third+party+cookies) を参照してください。）
-
-### 他には...?
-
-リンクの先読み機能について質問やコメントなどありましたら、私の方までお気軽にどうぞ。 :-)
-
-#### 関連情報...
-
-[Prefetching Hints](http://www.edochan.com/programming/pf.htm)
-
-## 原文情報
-
-- 著者: Darin Fisher (darin at meer dot net)
-- 最終更新日: Updated: March 3, 2003
diff --git a/files/ja/web/progressive_web_apps/guides/structural_overview/index.md b/files/ja/web/progressive_web_apps/guides/structural_overview/index.md
deleted file mode 100644
index 56a6e9d9bdf6cd..00000000000000
--- a/files/ja/web/progressive_web_apps/guides/structural_overview/index.md
+++ /dev/null
@@ -1,307 +0,0 @@
----
-title: プログレッシブウェブアプリの構造的な概要
-slug: Web/Progressive_web_apps/Guides/Structural_overview
-original_slug: Web/Progressive_web_apps/Structural_overview
----
-
-プログレッシブウェブアプリ (PWA) はあらゆるウェブコンテンツに対応していますが、ウェブ上で使用することも、ローカルアプリケーションとしてインストールして実行することも可能なウェブアプリとして認識されるためには、特定の構造を持ち、特定のコンポーネントを含む必要があります。この構造概要では、標準的なウェブアプリケーションを構成する機能と、PWA を構築する際に従うことができるいくつかのデザインパターンを見ていきます。
-
-## アプリの構造
-
-ウェブサイトのレンダリングには、大きく分けて、サーバー上で行う方法と、クライアント上で行う方法があります。どちらも一長一短がありますが、この 2 つのアプローチをある程度混合することも可能です。
-
-- **サーバーサイドレンダリング** (**SSR**) とは、ウェブサイトがサーバー上でレンダリングされることで、初回の読み込みは速くなりますが、ページ間の移動には新しい HTML コンテンツのダウンロードが必要になります。これはブラウザーを問わず動作しますが、ページ間の移動に時間がかかるため、一般的に認識されるパフォーマンスに影響を与えます。ページを読み込むのにサーバーへの新しいラウンドトリップが必要となるからです。
-- **クライアントサイドレンダリング** (**CSR**) は、異なるページに移動した際に、ほぼ瞬時にブラウザー内でウェブサイトを更新することができますが、最初のダウンロードとクライアントでの余分なレンダリングが必要になります。最初の訪問時にはウェブサイトの表示速度が遅くなりますが、移動時には速くなります。
-
-クライアントサイドレンダリングとサーバーサイドレンダリングの両方を使用すると、最良の結果が得られます。サーバー上でウェブサイトをレンダリングし、そのコンテンツをキャッシュし、必要に応じてクライアントサイドでレンダリングを更新します。SSR のおかげで最初のページロードが早く、クライアントが変更部分のみを再レンダリングできるので、ページ間の移動がスムーズになります。
-
-PWA はどのようなアプローチでも構築できますが、一部のアプローチは他のアプローチよりもうまく機能します。最も一般的なアプローチは、**アプリシェル** (app shell) の概念です。これは、SSR と CSR を前述の方法で正確に組み合わせたもので、さらに「オフラインファースト」の方法論に従っています。これについては、今後の記事で詳しく説明し、サンプルアプリケーションで使用します。また、Streams API を使った新しいアプローチもありますが、これについても簡単に説明します。
-
-## アプリシェルの概念
-
-アプリシェルの概念は、最小限のユーザーインターフェースとコンテンツをできるだけ早く読み込み、それをキャッシュしてオフラインでも次回のアクセス時に利用できるようにしてから、アプリの残りのコンテンツを読み込むというものです。そうすることで、端末からアプリにアクセスしたときに、UI がすぐにキャッシュから読み込まれ、新しいコンテンツは (キャッシュにない場合は) サーバーにリクエストされます。
-
-この構造は高速であり、ユーザーはローディングスピナーや空白のページではなく、即座に「何か」を目にするため、高速であると感じます。また、ネットワーク接続が利用できない場合でも、オフラインでウェブサイトにアクセスすることができます。
-
-[サービスワーカー](/ja/docs/Web/API/Service_Worker_API)を使うと、サーバーからのリクエストとキャッシュからの取得を制御することができますが、これについては次回詳しく説明します。
-
-### アプリシェルパターンの利点
-
-このアーキテクチャにより、ウェブサイトは PWA のすべての機能の恩恵を受けることができます。アプリシェルをキャッシュし、動的コンテンツを管理することで、パフォーマンスが大幅に向上します。基本的なシェルに加えて、[ホーム画面への追加](/ja/docs/Web/Progressive_web_apps/Add_to_home_screen)や[プッシュ通知](/ja/docs/Web/API/Push_API)などの機能を追加することができます。これらの機能がユーザーのブラウザーで対応していなくても、アプリは問題なく動作します。これがプログレッシブエンハンスメントの優れた点です。
-
-ウェブサイトは、ウェブの利点を維持しながら、即時の操作性と確かなパフォーマンスを備えたネイティブアプリのように感じられるようになります。
-
-### リンク可能で、プログレッシブ性、レスポンシブ性を兼ね備えたデザイン
-
-PWA の利点を覚えておき、アプリケーションを設計する際に念頭に置いておくことが重要です。アプリシェルのアプローチにより、ウェブサイトは以下のようになります。
-
-- リンク可能であること。ページ内のリンクをクリックしたり、共有したい場合は URL を誰かに送ったりすることができ、ネイティブアプリのように動作しても、ウェブサイトであることに変わりはありません。
-- プログレッシブであること。「古き良き基本的なウェブサイト」から始めて、徐々に新しい機能を追加していきます。その際、ブラウザーで利用可能かどうかを検出し、対応していない場合に発生するエラーを優雅に処理することを忘れないでください。例えば、サービスワーカーの助けを借りたオフラインモードは、ウェブサイトの使い勝手をより良いものにするための付加的な特徴に過ぎませんが、それがなくても全く問題なく使用できます。
-- レスポンシブであること。レスポンシブウェブデザインは、プログレッシブウェブアプリにも適用されます。どちらも主にモバイル端末向けのデザインだからです。ブラウザーが搭載されている端末の種類は非常に多く、[meta viewport タグ](/ja/docs/Mozilla/Mobile/Viewport_meta_tag)、[CSS メディアクエリー](/ja/docs/Web/CSS/Media_queries)、[フレックスボックス](/ja/docs/Learn/CSS/CSS_layout/Flexbox)、[CSS グリッド](/ja/docs/Web/CSS/CSS_Grid_Layout)などの技術を使用して、様々な画面やビューポートの大きさ、ピクセル密度でも動作するようにウェブサイトを準備することが重要です。
-
-## もう一つのアプローチ: ストリーム
-
-[Streams API](/ja/docs/Web/API/Streams_API) を使用すると、サーバーサイドまたはクライアントサイドのレンダリングに対して、まったく異なるアプローチをとることができます。サービスワーカーの助けを借りれば、ストリームはコンテンツを解析する方法を大幅に改善することができます。
-
-アプリシェルモデルでは、ウェブサイトがレンダリングを開始する前に、すべてのリソースが利用可能であることが必要です。HTML の場合は違います。実際にはブラウザーがすでにデータをストリーミングしており、要素が読み込まれてウェブサイトにレンダリングされたことを確認することができます。しかし、JavaScript を実際に動作させるためには、JavaScript をすべてダウンロードする必要があります。
-
-Streams API を使用すると、開発者はサーバーからストリーミングされるデータに直接アクセスすることができます。データに対して何らかの操作を行いたい場合 (例えば、動画にフィルターを追加するなど)、すべてのデータがダウンロードされ、blob (またはその他のもの) に変換されるのを待つ必要はもうありません。その代わりに、すぐに始めることができます。ストリームの開始、他のストリームとの連結、キャンセル、エラーのチェックなど、きめ細かな制御が可能になります。
-
-理論的には、ストリーミングはアプリのシェルモデルよりも優れたモデルですが、より複雑であり、 Streams API は主要なブラウザーはまだ完全に対応していません。しかし、Streams API が利用可能になれば、アプリのコンテンツを提供する最速の方法になります。パフォーマンス面でのメリットは、まさに目を見張るものがあります。
-
-動作する例や詳しい情報は、[Streams API のドキュメント](/ja/docs/Web/API/Streams_API)を参照してください。
-
-## サンプルアプリケーションの構造
-
-js13kPWA のウェブサイトの構造はとてもシンプルです。1 つの HTML ファイル (index.html) で構成されており、基本的な CSS スタイルは style.css で提供されています。また、画像やスクリプト、フォントなどもいくつか含まれています。ファイルとフォルダーの階層は次のようになっています。
-
-- `app.js`
-- `data/`
-
- - `games.js`
- - `img/`
-
-- `favicon.ico`
-- `fonts/`
-- `icons/`
-- `img/`
-
- - `bg.png`
- - `js13kgames.png`
-
-- `index.html`
-- `js13kpwa.webmanifest`
-- `style.css`
-- `sw.js`
-
-### HTML
-
-ファイル `index.html` の中の HTML がアプリの構造を作ります。アプリのシェルモデルに直接関連する部分は、このページ内の {{HTMLElement("section")}} のうち ID が `content` であるものの外側にあります。
-
-```html
-
-
-
-
- js13kGames A-Frame entries
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
-
-
- js13kGames A-Frame entries
- List of games submitted to the
- A-Frame category in the js13kGames 2017
- competition. You can
- fork js13kPWA on GitHub to check its source code.
-
-
- // Content inserted in here
-
-
-
-
-
-```
-
-{{HTMLElement("head")}} セクションには、アプリのタイトル、説明、CSS ファイルへの必要な参照、ウェブマニフェスト、メインアプリケーションの JavaScript ファイル (アプリを初期化する `app.js`)、追加の JavaScript コードファイルなど、アプリに関する基本的な情報が含まれています。{{HTMLElement("body")}} は、画像を表示する {{HTMLElement("header")}} と、 {{HTMLElement("main")}} 要素の中にあるアプリの本文に分かれています。アプリは、タイトル、説明文、そしてアプリのコンテンツを表示する場所 (ID が `content` である {{HTMLElement("section")}} 要素) を表示します。コンテンツの下には、著作権表示と各種リンクを提供する{{HTMLElement("footer")}}があります。
-
-このアプリの唯一の仕事は、js13kGames 2017 のコンペティションに参加した [A-Frame](https://aframe.io/) 作品をすべてリストアップすることです。ご覧の通り、これはごく普通の 1 ページのウェブサイトです。このアプリの唯一の目的は、実際の PWA 機能の実装を検討するために使用できるシンプルなものを用意することです。
-
-### CSS
-
-このシンプルな例では、CSS も可能な限りシンプルにしています。{{cssxref("@font-face")}} を使用してカスタムフォントを読み込んで使用し、HTML 要素に簡単なスタイルを施しています。全体的なアプローチとしては、モバイル (レスポンシブウェブデザインのアプローチ) とデスクトップの両方で見栄えのするデザインを目指しています。
-
-### app.js: メインアプリの JavaScript
-
-`app.js` というファイルは、アプリが最初にロードされたときに実行されます。このファイルの役割は、主にアプリの初期化ですが、それ以外のこともできます。アプリがどのように機能するかは、このガイドの後の記事で詳しく説明します。
-
-このアプリが最初に行うことは、次のテンプレートを使ってアプリの表示内容を生成することです。
-
-```js
-const template = `
- 
- #POS. NAME
-
-`;
-let content = '';
-for (let i = 0; i < games.length; i++) {
- let entry = template.replace(/POS/g, (i + 1))
- .replace(/SLUG/g, games[i].slug)
- .replace(/NAME/g, games[i].name)
- .replace(/AUTHOR/g, games[i].author)
- .replace(/TWITTER/g, games[i].twitter)
- .replace(/WEBSITE/g, games[i].website)
- .replace(/GITHUB/g, games[i].github);
- entry = entry.replace('
-