このような問題を処理する通常の方法は、HTTPキャッシュヘッダーとスマートなURLの構築ですあなたのページで参照されるリソース
一般的な考え方は次のとおりです。ページ(画像、スクリプト、CSSファイルなど)で読み込まれるすべてのリソースには、一意のバージョン管理されたURLが必要です。たとえば、/images/button.png
をロードする代わりに/images/button_v123.png
をロードし、そのファイルを変更するとURLは/images/button_v124.png
に変わります。通常、これは静的ファイルのURL上でのURL書き換えによって処理されます。たとえば、Webサーバーはが実際にWebサーバーのファイルシステムから/images/button.png
ファイルをロードする必要があることを認識します。バージョン番号を作成するには、ビルド番号を追加するか、ファイルの内容のCRCを使用するか、その他多くの方法で行うことができます。
次に、親ページにURLが作成されている場合は、バージョンが付けられたURLを参照する必要があります。これには明らかに、すべてのURLを構築するために使用される動的コードが必要です。これは、ページの生成に使用するコードを調整するか、すべてのtext/html
リクエストに影響するサーバー全体のプラグインによって行います。
次に、すべてのリソースリクエスト(画像、スクリプト、CSSファイルなど)のヘッダーを将来の日付(たとえば10年後)に設定します。これは効果的にそれらを効果的にキャッシュします。これは、各ページによってロードされたすべてのリクエストが常にキャッシュからフェッチされることを意味します。キャッシュの無効化は発生しません。基本的なリソースが変更された場合、親ページが新しいURLを使用してそれを検索するため、問題ありません。
最後に、「親」ページのキャッシュ方法を把握する必要があります。あなたはこれをどうやって判断するのですか? ETag
/If-None-Match
HTTPヘッダーを使用して毎回新しいバージョンのページを確認することができます。これにより、サーバーが変更されていないと報告された場合、キャッシュからページが読み込まれる速度が非常に速くなります。または、Expires
(および/またはMax-Age
)を使用して、サーバーをチェックする前に一定期間キャッシュから親ページをリロードすることができます。
さらに洗練された方法で操作したい場合は、いつでもキオスクにカスタムプロキシサーバーを置くことができます。その場合、キャッシュがどのように行われるかを集中管理できます。
こんにちは、 "バージョンクエリのパラメータ"をリソースに追加する方法についてどう思いますか?アプリケーションのバージョンを返す小さなキャッシュされていないリソースがアプリケーションにあります。各URLにバージョンを追加します(例:/ images/button?version = v124)。このアプローチの利点は、アプリケーションのサーバー側での保守性です。 –
あなたのサーバがその方法でOKであれば(ここで「ok」は画像にエラーが返されたことを意味します)、クエリ文字列はおそらく問題ありません。何年も前、AOLや他のローエンドISPには、異なるクエリ文字列でイメージをキャッシュすることのない攻撃的なプロキシサーバーがあると聞いていましたが、これをやめたほうがいいでしょう。 –