プリフェッチ、事前レンダリング、Service Worker の事前キャッシュ

前のいくつかのモジュールでは、テストの延期、 JavaScript の読み込みと画像と <iframe> 要素の遅延読み込み。 リソースの読み込みを遅らせることで、初期状態ではネットワークと CPU の使用量が減少します。 必要なタイミングでリソースをダウンロードすることで、ページを読み込むことができます。 使用されない可能性があるためです。 これにより最初のページ読み込み時間は短縮できますが、その後の操作は 電力の供給に必要なリソースがその時点でまだ読み込まれていない場合に遅延が発生する 発生します。

たとえば、ページにカスタム日付選択ツールが含まれている場合は、日付を遅らせることができます。 ユーザーが操作するまで、選択ツールのリソースがない可能性があります。ただし、 日付選択ツールのオンデマンド リソースにより遅延が生じる可能性がありますが、 ユーザーのネットワーク接続、デバイスの機能、 リソースのダウンロードと解析が行われ、実行可能な状態になります。

バランスが複雑です。読み込みに帯域幅を浪費したくない 使用されなくなる可能性があるものの、インタラクションや後続のページを遅らせる 最適とは言えません幸い、Google Cloud のロードバランサを使用して これら 2 つの極端なバランスを取る方法を学びます。このモジュールでは、 そのための手法として、リソースのプリフェッチ、 ページ全体の事前レンダリング、Service Worker を使用したリソースのプレキャッシュがあります。

近い将来必要なリソースを低い優先度でプリフェッチする

画像、スタイルシート、ファイル、ファイルなどのリソースを （<link rel="prefetch"> リソースヒントを使用します）。「 prefetch ヒントは、リソースが必要な可能性が高いことをブラウザに通知します。 説明します

prefetch ヒントを指定すると、ブラウザはリクエストを開始できます。 リソースとの競合を避けるために、そのリソースに最も低い優先度で割り当てます。 現在のページに必要です。

<ph type="x-smartling-placeholder">

リソースをプリフェッチすると、ユーザーが事前に リソースが想定どおりにダウンロードされるのを待つ必要があるため、 ディスク キャッシュから必要なときに即座に取得できます。

<head>
  <!-- ... -->
  <link rel="prefetch" as="script" href="/date-picker.js">
  <link rel="prefetch" as="style" href="/date-picker.css">
  <!-- ... -->
</head>

上記の HTML スニペットは、プリフェッチできることをブラウザに通知します。 アイドル状態のときは date-picker.js と date-picker.css。新しい P-MAX キャンペーンを ユーザーがページを操作すると、リソースが動的にプリフェッチされます。 使用できます。

prefetch は、Safari を除くすべての最新ブラウザでサポートされています。 使用できます。データをプリエンプティブに読み込む必要がある場合は、 すべてのブラウザで動作するように 使用する必要がある場合は、このモジュールの後半にあるプリキャッシュ Service Worker でリソースを作成できます。

ページをプリフェッチして以降の操作をすばやく行えるようにする

次のように指定して、ページとそのすべてのサブリソースをプリフェッチすることもできます。 as="document" 属性（HTML ドキュメントを指す場合）:

<link rel="prefetch" href="/page" as="document">

ブラウザがアイドル状態のときに、/page に対して優先度の低いリクエストが開始されることがあります。

<ph type="x-smartling-placeholder">

Chromium ベースのブラウザでは、 Speculation Rules API。推測ルールは JSON オブジェクトとして定義される または JavaScript によって動的に追加する:

<script type="speculationrules">
{
  "prefetch": [{
    "source": "list",
    "urls": ["/page-a", "/page-b"]
  }]
}
</script>

JSON オブジェクトには、1 つ以上のアクションが記述されます。現在サポートされているのは、 prefetch、prerender、およびそのアクションに関連付けられた URL のリスト。イン 前の HTML スニペットでは、ブラウザは /page-a をプリフェッチするように指示されています。 および /page-b。<link rel="prefetch"> と同様に、投機ルールは 特定の状況でブラウザが無視する場合があるというヒント。

<ph type="x-smartling-placeholder">

Quicklink などのライブラリは、ページ ナビゲーションを動的かつ動的に改善 表示できます。そのため、ユーザーが最終的には （ページ上のすべてのリンクのプリフェッチと比較した場合）

<ph type="x-smartling-placeholder">

ページの事前レンダリング

リソースのプリフェッチに加え、ブラウザに新しいヒントを ユーザーが移動する前にページを事前レンダリングする。これにより、 ページが瞬時に読み込まれるように構成されます。ページとそのリソースは、 できます。ユーザーがページに移動すると、ページは 使用します。

事前レンダリングは、Speculation Rules API でサポートされます。

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/page-a", "page-b"]
    }
  ]
}
</script>
<ph type="x-smartling-placeholder">で確認できます。 <ph type="x-smartling-placeholder">

プリフェッチと事前レンダリングのデモ

Service Worker のプレキャッシュ

Service Worker を使用して、投機的にリソースをプリフェッチすることもできます。 Service Worker のプレキャッシュでは、Cache API を使用してリソースをフェッチして保存できます。 これにより、ブラウザは Cache API を使用して、 通信できます。Service Worker のプリキャッシュでは、非常に効果的な Service Worker これはキャッシュ専用戦略と呼ばれます。このパターンは なぜなら、リソースが Service Worker のキャッシュに配置されると、 リクエストに応じてほぼ即座に取得されます。

<ph type="x-smartling-placeholder">
</ph> ページから Service Worker やキャッシュへの Service Worker のキャッシュ フローを示します。 <ph type="x-smartling-placeholder">
</ph> キャッシュのみの戦略では、キャッシュから有効なリソースのみが インスタンスに通信する必要があります。インストールすると、キャッシュに保存された Service Worker のキャッシュからのみ取得されます。
で確認できます。
<ph type="x-smartling-placeholder">

Service Worker を使用してリソースを事前キャッシュに保存するには、Workbox を使用します。もし 事前定義されたデータセットをキャッシュに保存する独自のコードを できます。いずれの場合も、Service Worker を使用して事前キャッシュに 重要な点として、プリキャッシュはサービスが ワーカーがインストールされていることを確認できます。インストール後、プリキャッシュされたリソースは Service Worker で制御されているウェブサイトであれば、どのページでも取得できます。

<ph type="x-smartling-placeholder">

ワークボックスはプレキャッシュ マニフェストを使用して、実行するリソースを決定します。 キャッシュに保存されます。プリキャッシュ マニフェストは、ファイルとバージョニング情報のリスト 「信頼できる情報源」としての役割を果たします。リソースをプリキャッシュする時間間隔を 定義します

[{  
    url: 'script.ffaa4455.js',
    revision: null
}, {
    url: '/index.html',
    revision: '518747aa'
}]

上記のコードは、次の 2 つのファイルを含むマニフェストのサンプルです。 script.ffaa4455.js と /index.html。リソースに「version」と （ファイル ハッシュと呼ばれます）、revision ファイルはすでにバージョニングされているため、null のままで構いません（例: ffaa4455 を script.ffaa4455.js します）。対象 バージョニングされていないリソースに対しては、ビルド時にリビジョンを生成できます。

設定が完了すると、Service Worker を使用して静的ページや 後続のページ移動を高速化します。

workbox.precaching.precacheAndRoute([
  '/styles/product-page.ac29.css',
  '/styles/product-page.39a1.js',
]);

たとえば、e コマースの商品リスティングページでは、Service Worker を使って 商品の詳細ページの表示に必要な CSS と JavaScript を事前キャッシュする 商品詳細ページに移動するまでの時間が大幅に短縮されます。 上記の例の product-page.ac29.css と product-page.39a1.js は、 キャッシュに保存されます。workbox-precaching で利用可能な precacheAndRoute メソッド 必要なハンドラが自動的に登録され、プリキャッシュされたリソースが 必要に応じて Service Worker API から フェッチされます

Service Worker は広くサポートされているため、Service Worker で 状況で必要な場合は最新のブラウザで プレキャッシュを実行できます

<ph type="x-smartling-placeholder">で確認できます。 <ph type="x-smartling-placeholder">

理解度テスト

prefetch ヒントはどの優先度で発生しますか？

ドライブ
高い。
中程度

プリフェッチと ページの事前レンダリング

ページのプリフェッチと事前レンダリングはどちらも、1 つのページを取得し、 そのサブリソースがある場合、プリフェッチはページとその 事前レンダリングによってさらに一歩進んで、 ユーザーがそのページに移動するまで、背景がページ全体に残っていません。
どちらもほぼ同じで、事前レンダリングによってページのすべての プリフェッチはサポートしません

Service Worker のキャッシュと HTTP のキャッシュは同じです。

False
正しい

次のステップ: ウェブ ワーカーの概要

ここまで、プリフェッチ、事前レンダリング、Service Worker のプレキャッシュの仕組みを ナビゲーションをスピードアップして これをどのように実現すればよいかについて ウェブサイトとユーザーにとって有益です

次に、ウェブ ワーカーの概要と、ウェブワーカーが高コストになる理由について説明します。 処理し、メインスレッドがより多くの時間を費やせるよう 向上しますメインファイルに 次の 2 つのモジュールは、時間をかける価値があります。