キャッシュを大切に ❤️

サイトを 2 度目に読み込んだユーザーは HTTP キャッシュを使用するため、 うまくいきます

Sam Thorogood

この投稿は、Love your cache の動画に付随する、Extended Chrome Dev Summit 2020 のコンテンツ。以下の動画もぜひご覧ください。

ユーザーがサイトを再度読み込むと、ブラウザはサイト内のリソースを使用します。 HTTP キャッシュにキャッシュして 読み込みを高速化しますただし、オンプレミスでのキャッシュの標準は ウェブは 1999 年にまでさかのぼります。 CSS や画像などのファイルがネットワークから再度取得される可能性があるかどうか キャッシュからの読み込みか、

今回の投稿では、キャッシュの適切な最新デフォルトについて説明します。 実際には一切キャッシュされません。これがデフォルトです ただ「オフにする」だけではありません。ご一読ください。

目標

2 回目のサイトの読み込みには、次の 2 つの目標があります。

  1. ユーザーが利用可能な場合、常に最新バージョンを 変更内容はすぐに反映されます。
  2. 1. ネットワークからの取得回数をできるだけ少なくする

大まかに言えば、クライアントに送信するのはごくわずかな変更のみです。 ユーザーがサイトを再度読み込んだときに 警告を表示することですそして、最大限の成果が得られるように 変更を効率的に分散させることは困難です（これについては後述 。

とはいえ、キャッシュについて検討する際は、他にも調整手段があります。 ユーザーのブラウザの HTTP キャッシュがサイトに長期間保持されることにした場合 ネットワーク リクエストをまったく必要とせずに済みます。または、 それまでに完全にオフラインでサイトを提供する Service Worker を 確認しています。これは極端な選択肢です。 多くのオフラインファーストのアプリのようなウェブ体験が対象となりますが、ウェブを キャッシュのみ、または完全にネットワークのみに 対応できます

背景

ウェブ デベロッパーなら誰でも、「古いキャッシュ」を使用するという考え方をよくご存じでしょう。 しかし、私たちはほぼ直感的に、この問題を解決するために利用できるツールを知っています。 更新するか、シークレット ウィンドウを開くか、ブラウザの デベロッパー ツールを使用してサイトのデータを消去する。

インターネットの常連ユーザーは、それほど贅沢な買い物をしていません。このように ユーザーが 2 回目のイベントで優れた時間を過ごせるようにするという重要な目標があります。 悪い時間や 行き詰まります。（Google Cloud のソリューションについて詳しく知りたい場合は、 web.dev/live サイトが先に進まなくなります）。

「古いキャッシュ」の一般的な原因は、実際には 1999 年代のキャッシュ保存のデフォルト設定ですこれは Last-Modified ヘッダーに依存します。

<ph type="x-smartling-placeholder">
</ph> ユーザーのブラウザでさまざまなアセットがキャッシュされる期間を示す図
異なる時間に生成されたアセット（グレーで表示）は、 これにより、2 回目の読み込みで、キャッシュに保存されたアセットと最新のアセットの組み合わせを取得できます

読み込まれたすべてのファイルは、現在の保持期間の 10% が追加されます。 ブラウザが認識します。たとえば、index.html が 1 か月前に作成された場合、 ブラウザによってさらに 3 日間キャッシュされます。

これは当時の意図的なアイデアでしたが、 このようなデフォルトの動作によって さまざまなリリース向けに設計されたファイルを ユーザーが持っている状態に （例: 火曜日のリリースの JS、金曜日のリリースの CSS） リリースされるなど）に注意する必要があります。

明るさが十分にある道

最新のキャッシュ保存のデフォルト設定では、実際にはまったくキャッシュ保存を行わず、 CDN: コンテンツを近似させる 提供しますユーザーはサイトを読み込むたびに、ネットワークにアクセスして 確認します。このリクエストは、次のとおり、低レイテンシで 各エンドユーザーに地理的に近い CDN から提供されます。

ウェブ リクエストに対し、このヘッダーで応答するようにウェブホストを構成できます。

Cache-Control: max-age=0,must-revalidate,public

基本的には、ファイルは無期限に有効であるため、検証する必要があります。 再使用する前にネットワークから切断する必要があります 「推奨」）。

この検証プロセスは、転送されたバイト数の点で比較的安価です。 大きな画像ファイルが変更されていない場合、ブラウザに小さな 304 ただし、ユーザーがネットワークにアクセスしてそれを見つける必要があるため、レイテンシが犠牲になります。 できます。これがこのアプローチの主なデメリットです。これは非常に効果的な方法ですが、 お好みの CDN プロバイダが 対応範囲は広いが、低速なモバイルを使用しているユーザーには適していない 不十分なインフラを使うのは避けたいところです。

いずれにせよ、これは 一般的な CDN Netlify のデフォルトです ほぼすべての CDN で設定できますFirebase Hosting の場合、 このヘッダー 示しています 次の要素に置き換えます。

"headers": [
  // Be sure to put this last, to not override other headers
  {
    "source": "**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=0,must-revalidate,public"
    }
  }
]

現実的なデフォルトとしておすすめしますが、これはデフォルトにすぎません。 ここでは、デフォルトの設定にアップグレードしてアップグレードする方法を紹介します。

フィンガープリント URL

アセットや画像などの名前にファイルのコンテンツのハッシュを含める。 使用する場合は、これらのファイルには常に一意のキー名を content - 結果として、たとえば sitecode.af12de.js という名前のファイルが出力されます。日時 サーバーがこれらのファイルに対するリクエストに応答する場合、 キャッシュに保存できるように、 header:

Cache-Control: max-age=31536000,immutable

この値は年（秒単位）です。仕様によれば、これは実質的には 「永久」に等しいことを意味します。

重要なのは、これらのハッシュを手作業で生成しないことです。手作業が多すぎるからです。マイページ Webpack や Rollup などのツールを利用できます必ず 詳しくは、ツールに関するレポートをご覧ください。

フィンガープリントによる URL のメリットを得られるのは JavaScript だけではありません。 アイコン、CSS、その他のイミュータブル データファイルなどのアセットには、この名前を できます。（コードの詳細については、上の動画をご覧ください）。 分割することで、サイトの変更時に配布するコードを減らすことができます）。

サイトのキャッシュ保存の仕組みにかかわらず、この種のフィンガープリントは どんなサイトでも非常に価値があります。ほとんどのサイトは すべてのリリースで変更されるわけではありません

もちろん、ユーザーに表示されるページの名前を「フレンドリー」に変更することはできません。名前の変更 index.html ファイルを index.abcd12.html にアタッチすることは不可能です。 ユーザーがサイトを読み込むたびに新しい URL に移動するよう誘導しています。これらの「友好的」なURL この方法では名前の変更やキャッシュができないため、 必要があります。

中点

キャッシュに関しては、明らかに中間の余地があります。CANNOT TRANSLATE 2 つの極端な選択肢が提示されました。キャッシュなし、または永久キャッシュです。すると、 一定期間キャッシュに保存できるファイル数を指定します。 「友好的」先ほど述べた URL です

これらの「フレンドリーな」ルールを使用するだけではなく、 どのような依存関係が含まれるか、どのようにそれらがキャッシュに保存されるのか、どのように しばらく URL をキャッシュに保存すると、影響が出る可能性があります。次の HTML ページを見てみましょう 次のような画像が含まれています。

<img src="/images/foo.jpeg" loading="lazy" />

この遅延読み込み設定を削除または変更してサイトを更新または変更すると、 キャッシュされたバージョンの HTML を表示すると、正しくないまたは 画像がない。元の /images/foo.jpeg がまだキャッシュされている サイトに再訪問する可能性が高まります

気をつければ、影響がないかもしれません。大まかに言うと エンドユーザーがキャッシュしたサイトは 管理しますエンドユーザーのキャッシュ内の断片として存在することもあります。 できます。

一般的に、キャッシュに関するほとんどのガイドでは、この種のキャッシュについて 1 時間、数時間など、どの方法でキャッシュ保存するかを指定できます。これを設定するには 使用する場合は、このようなヘッダーを使用します（このヘッダーは 3,600 秒間、 時間）:

Cache-Control: max-age=3600,immutable,public

最後にもう 1 つお伝えします。タイムリーなコンテンツを作成する場合、 ニュース記事のように 1 回しかアクセスしないものではなく、 また、上記の適切なデフォルト値を使用する必要があります。私はよく 常に最新データを表示したいというユーザーの要望を考慮し、キャッシュの価値を過大評価する 重要な最新情報や最新のニュースや 最新のコンテンツなどを イベントです。

HTML 以外のオプション

HTML とは別に、中間に位置するファイル用のその他のオプション 含める:

  • 一般的に、他に影響を与えないアセットを探します

    • たとえば、CSS を使用すると HTML のレイアウトが変わるため、使用しないようにします。 レンダリング済み

  • タイムリーな記事の一部として使用される大きな画像

    • ユーザーはおそらく、今後どの記事にもアクセスしないでしょう 失敗する可能性があるため、写真やヒーロー画像を永久にキャッシュに保存しないようにしてください。 廃棄物保管

  • それ自体が存続しているものを表すアセット

    • 天気に関する JSON データは 1 時間ごとにしかパブリッシュされないので、 前の結果を 1 時間キャッシュできる。ウィンドウ中では変更されない
    • オープンソース プロジェクトのビルドにはレート制限が適用されることがあるため、 ステータスが変化するまで、ステータス イメージをビルド

概要

ユーザーがサイトを 2 回目に読み込んだときに、すでに賛成票を投じています リピーターの獲得を目指します。この 単に読み込み時間を短くするだけでは不十分で さまざまなオプションが用意されています。 高速かつ最新のエクスペリエンスの両方を提供する必要があります

キャッシュという概念はウェブでは新しいものではありませんが、 デフォルト（1 つの使用を検討し、より適切なキャッシュ戦略にオプトインすることを強くおすすめします） できます。今後ともよろしくお願いいたします。

関連情報

HTTP キャッシュに関する一般的なガイドについては、 HTTP キャッシュを使用して不要なネットワーク リクエストを防ぐ。