最新のモバイル Web アプリが通常行うように、キャッシュ マニフェストの明示的なキャッシュ セクションで HTML によって参照される静的リソース (CSS および JavaScript ファイル) をリストしました。しかし、キャッシュは帯域幅を最小限に抑えるために使用されるため、ローカル キャッシュがまだ存在しない場合に、Web アプリに初めてアクセスするときに、これらの静的リソースが 2 回ダウンロードされることを chrome で発見するのは驚くべきことです。2 回ダウンロードされる理由は、キャッシュ マニフェストと HTML で参照されているためだと思います。
リソースが両方の場所で参照されている場合、ブラウザがリソースを共有しないのはなぜですか? HTML5 標準に準拠していますか、それとも chrome のバグですか?
キャッシュ マニフェストを使用すると、ほぼすべてのブラウザー (Chrome、IE、Firefox) で一貫してこの動作が見られます。私が知る限り、リソースはキャッシュ マニフェストと html/css の両方で参照されるため、実際には 2 回ダウンロードされます。最初の読み込みはページ自体を読み込むためのもので、2 回目の読み込みは appcache を読み込むためのものです。
これで、appcache をロードするために 2 番目のリクエストを実行する必要がある場合でも、リソースは通常のブラウザ キャッシュから提供する必要があります。これは、元のリクエストがリソースをブラウザ キャッシュにロードした可能性があるためです。ただし、すべてのブラウザは、通常のブラウジング アクティビティとは異なる方法で appcache の読み込みを処理し、キャッシュをバイパスしているようです。
HTML5 の仕様に関する限り、仕様ではブラウザーが既存のダウンロードを使用するメカニズムを実装できることを示唆していますが、これはオプションです。
同期フラグを設定し、手動リダイレクト フラグを設定して、URL マニフェスト URL の起点からリソースをフェッチします。これがアップグレードの試みである場合は、キャッシュ グループ内の最新のアプリケーション キャッシュを HTTP キャッシュとして使用し、そのキャッシュに関して HTTP キャッシュ セマンティクス (有効期限、ETag など) を尊重します。ユーザー エージェントは、同様に受け入れられる他のキャッシュを配置することもできます。
問題のリソースが他の理由で既にダウンロードされている場合は、取得アルゴリズムで定義されているように、既存のダウンロード プロセスをこのステップの目的で使用できる場合があります。
既にダウンロードされている可能性のあるリソースの例としては、初めて表示される Web ページ上の大きな画像があります。画像は、キャッシュ マニフェストにリストされるだけでなく、ページの img 要素を満たすためにダウンロードされます。フェッチのルールによれば、その画像は 1 回ダウンロードするだけでよく、キャッシュとレンダリングされた Web ページの両方に使用できます。