ブラウザのキャッシュ、愛していると言うのは簡単ではありません_html/css_WEB-ITnose

今日、Xiaowei Kaidianbao がテスト環境でアップデートをリリースしたとき、同僚が次のように尋ねました。「変更を確認するためにブラウザのキャッシュを手動でクリアする必要があるのはなぜですか? システムの終了後、顧客もブラウザのキャッシュを自分でクリアする必要がありますか?」オンラインになりますか？ 「この穴を埋める必要があるようです。

ブラウザー キャッシュとは何ですか?

ブラウザー キャッシュとは、ユーザーが最近リクエストしたドキュメントをブラウザーがローカル ディスクに保存し、訪問者が同じページに再度アクセスしたときに、ブラウザーがドキュメントをローカル ディスクから直接ロードできることを意味します。

ブラウザキャッシュの利点は次のとおりです:

1. 冗長なデータ送信を削減し、ネットワーク料金を節約します
2. サーバーの負担を軽減し、Webサイトのパフォーマンスを大幅に向上させます
3. クライアントのWebページの読み込み速度を高速化します

前に-開発面接の終わりに、ブラウザ キャッシュは Web パフォーマンス最適化面接の質問において非常に重要な知識ポイントであり、ブラウザ キャッシュが Web パフォーマンスを向上させる優れたツールであることを示しています。しかし、ブラウザ キャッシュが不適切に使用されると、多くの問題も発生します。問題は、よく言われるように、愛していると言うのが簡単ではないことです。したがって、この記事では、最近遭遇した事例と組み合わせて、ブラウザのキャッシュに関連する知識を要約し、読者の役に立ちたいと考えています。

ブラウザ キャッシュの分類

ブラウザ キャッシュには、キャッシュ ネゴシエーションと徹底キャッシュの 2 つの主なタイプがあり、ネゴシエーション キャッシュや強力なキャッシュとも呼ばれます。

ブラウザが最初のリクエスト後に再度リクエストを行うと、

1. ブラウザはまずリソースのキャッシュされたヘッダー情報を取得し、有効期限とキャッシュ制御に基づいて強力なキャッシュにヒットするかどうかを判断します。キャッシュに直接アクセスし、キャッシュされたヘッダー情報を含むリソースをキャッシュから取得します。
2. 強力なキャッシュがヒットしない場合、リクエストはサーバーに送信されます。最初のリクエストによって返されたキャッシュ関連情報 (Last-Modified/IF-Modified-Since、Etag/IF-None-Match) を保持すると、サーバーはリクエスト内の関連するヘッダー情報に従って結果を比較します。ネゴシエーション キャッシュにヒットするかどうかを確認します。ヒットした場合、サーバーは、キャッシュ内の対応するヘッダー情報を更新しますが、リソースのコンテンツを直接取得できることをブラウザーに伝えません。それ以外の場合は、最新のリソース コンテンツが返されます

強力なキャッシュ

強力なキャッシュは、リソースのキャッシュ時間を示すために使用される Expires または Cache-Control の 2 つのフィールドによって制御される http のリターン ヘッダーを使用します。

Expires このフィールドは http1.0 の仕様であり、その値は Expires:Mon,18 Oct 2066 23:59:59 GMT などの GMT 形式の絶対時刻文字列です。この時間は、このリソースの有効期限を表します。この時間より前にキャッシュがヒットします。この方法には明らかな欠点があり、有効期限は絶対時間であるため、サーバーとクライアント間の時間のずれが大きい場合、キャッシュの混乱が発生します。

Cache-Control

Cache-Control は http1.1 に出現するヘッダー情報であり、主にこのフィールドの max-age 値を使用して判断されます。 Cache-Control:max などの相対時間です。 -age= 3600 は、リソースが 3600 秒間有効であることを意味します。このフィールドに加えて、cache-control には次のより一般的に使用される設定値もあります:
no-cache: ローカル キャッシュを使用しません。キャッシュ ネゴシエーションを使用して、返された応答が変更されているかどうかを最初にサーバーに確認する必要があります。前の応答に ETag がある場合、リソースが変更されていない場合は、サーバーで検証されます。再ダウンロードを回避できます。

no-store: ブラウザーによるデータのキャッシュを直接禁止します。ユーザーがリソースをリクエストするたびにリクエストがサーバーに送信され、毎回完全なリソースがダウンロードされます。

public: エンド ユーザーや CDN などの中間プロキシ サーバーを含むすべてのユーザーがキャッシュできます。

プライベート: エンド ユーザーのブラウザによってのみキャッシュでき、CDN などのリレー キャッシュ サーバーによってキャッシュすることは許可されません。

サーバー構成でキャッシュ制御と有効期限を同時に有効にすることができます。同時に有効にした場合、キャッシュ制御の方が優先されます。

ネゴシエーションキャッシュ

ネゴシエーションキャッシュとは、サーバーがキャッシュリソースが利用可能かどうかを判断することを意味します。そのため、クライアントとサーバーは、リクエストされたリソースをキャッシュしてアクセスできるかどうかをサーバーが判断できるように、ある種の識別子を介して通信する必要があります。これには主に次の 2 セットのヘッダー フィールドが含まれます。これら 2 セットのパートナーはペアで表示されます。つまり、最初のリクエストの応答ヘッダーには特定のフィールド (Last-Modified または Etag) が含まれ、後続のリクエストには対応するフィールドが含まれます。リクエスト フィールド (If -Modified-Since または If-None-Match)、応答ヘッダーに Last-Modified フィールドまたは Etag フィールドがない場合、リクエスト ヘッダーには対応するフィールドがありません。

Last-Modify/If-Modify-Since

ブラウザが初めてリソースをリクエストすると、サーバーから返されるヘッダーに Last-Modify が追加されます。 Last-modify は、リソースを識別するタイムスタンプです。リソースの最終変更時刻 (例: Last-Modify: Thu,31 Dec 2037 23:59:59 GMT)。

ブラウザがリソースを再度リクエストすると、リクエスト ヘッダーには、キャッシュする前に返される Last-Modify である If-Modify-Since が含まれます。サーバーは If-Modify-Since を受信すると、リソースの最終変更時刻に基づいてキャッシュがヒットしたかどうかを判断します。

キャッシュがヒットした場合、304 が返され、リソースのコンテンツは返されず、Last-Modify も返されません。

ETag/If-None-Match

Last-Modify/If-Modify-Since とは異なり、Etag/If-None-Match はチェック コードを返します。 ETag は各リソースが一意であることを保証でき、リソースが変更されると ETag も変更されます。サーバーは、ブラウザーから送信された If-None-Match 値に基づいてキャッシュがヒットしたかどうかを判断します。

Last-Modified とは異なり、サーバーが 304 Not Modified 応答を返す場合、ETag は再生成されているため、ETag が以前のものから変更されていない場合でも、ETag は応答ヘッダーで返されます。

Etag が必要な理由

ローカル キャッシュ コピーが十分に新しいかどうかをブラウザーに知らせるには Last-Modified を使用するだけで十分だと思うかもしれませんが、なぜ Etag が必要なのでしょうか? HTTP1.1 での Etag の登場は、主に Last-Modified では解決するのが難しいいくつかの問題を解決するためです。

一部のファイルは定期的に変更される可能性がありますが、その内容は変更されません (現時点では、変更時刻のみが変更されます)。クライアントがファイルが変更されたと考えて再取得することは望ましくありません。

一部のファイルは、数秒未満で変更される (たとえば、1 秒間に N 回変更される)、If-Modified など、非常に頻繁に変更されます。 - チェックできる粒度は s レベルであるため、この種の変更を判断することはできません (または、UNIX の記録 MTIME は秒単位までしか正確ではありません)。一部のサーバーでは、ファイルの最終変更時刻を正確に取得できません。

Last-Modified と ETag は一緒に使用できます。サーバーは最初に ETag を検証し、それらが一致している場合は、Last-Modified の比較を続け、最終的に 304 を返すかどうかを決定します。

強力なキャッシュとネゴシエートされたキャッシュの違いは、次の表で表すことができます: |リソースフォームを取得|ステータスコード|サーバーにリクエストを送信

------|---------- --- |------|----------------

強力なキャッシュ|キャッシュから取得|200 (キャッシュから)|いいえ、キャッシュから直接取得します
交渉キャッシュ|キャッシュから取得|304 (未変更)|いいえ、キャッシュが利用可能かどうかをサーバーに伝えます
キャッシュに対するユーザーの行動の影響

ユーザー操作の期限切れ/キャッシュ制御の最終変更日/Etag

Enter キーを押してくださいアドレスバー有効有効ページリンクジャンプ有効有効新しいウィンドウ有効有効前後に有効有効F5 更新無効 有効Ctrl+F5 強制更新無効無効 記事の冒頭で述べたように、ユーザーのブラウザは、コードはオンラインで更新されるため、お客様にシステムの更新を依頼することはできません。その後、キャッシュ クリーニング操作を実行します。

		実際の問題の分析

どうやって解決しますか？

リソースリクエスト URL にパラメーターを追加します (例: js/mian.js?ver=0.7.1)。このパラメータはバージョン番号であり、このパラメータが変更されると、強力なキャッシュが無効化され、再ロードされます。このように、静的リソースはデプロイ後に再ロードする必要があります。これにより、問題はより完全に解決されます。 さらなる考察

これが最も完璧な方法でしょうか?残念ながら、そうではありません。

Baidu Zhang Yunlong は、これを行うことの欠点について説明しました。興味がある場合は、以下を参照してください:

静的リソースのバージョンの更新とキャッシュ

ありがとうございます。