window.applicationCacheにはupdateというメソッドがあります。この関数は、html 要素で指定されたmanifest.appcacheファイルをフェッチし、相違点をチェックすると仮定します。
これはすべて問題ありませんが、私の理解では、ページが読み込まれるたびに、ブラウザーはmanifest.appcacheファイルを要求し、とにかく同じ「相違点の確認」手順を実行します。
私の質問は次のとおりです（統計は作成されていることに注意してください）：
「アップデートの平均リリースサイクルが2週間で、平均ページ滞在時間が30秒なら、なぜアップデート機能があるの？」
私にはこれは意味がなく、何かが欠けていると思うので、SOの質問です。
一部の企業 (IMVU など) は、1 日に数回更新をプッシュすることが知られています。これは、一般に「継続的な展開」と呼ばれます。ページで費やされる平均時間は、アプリケーションのアーキテクチャに大きく依存します。
HTML5 Appcache は主に、「単一ページ アプリケーション」、つまりすべてのユーザー操作が 1 つのページビュー内で発生するアプリケーション (ブラウザーに関する限り) のコードをキャッシュするために使用されることを意図していると思います。Gmail はシングルページ アプリの良い例です。ただし、appcache は使用しませんが、可能です。
(実際には) 表示されているドキュメント全体が、サーバーからダウンロードされた他のコンテンツに置き換えられる可能性があるため、ユーザーはそれを単一のページ ビューとして体験しない場合があります。ユーザーは、HTML5 History API を使用して、アプリ内で「ブラウジング」しているときに、自分のロケーション バーが変化するのを見ることさえできます。
ユーザーは、単一ページのアプリ (gmail を考えてください) を何時間も続けて使用している可能性があり、コンピューターをシャットダウンしない (またはブラウザーを閉じない) 場合は何日も使用する可能性があります。
設計上、appcache-cache (通常のブラウザー キャッシュとは異なる動作) を持つページを読み込むように要求されたブラウザーは、常にディスクからキャッシュされたバージョンを読み込みますが、これは必ずしも最新のバージョンではありません。キャッシュからロードするということは、アプリケーションがネットワーク遅延なしで開始されることを意味します。アプリをロードした後でのみ、ブラウザーは更新されたキャッシュ マニフェストを確認します。デフォルトでは、このような更新はユーザーに通知されません。彼は、ブラウザでアプリをリロードした後にのみ更新を確認します。
ユーザーがアプリを数時間開いている場合、その間に確実に更新が行われている可能性があります。そのため、アプリケーションの次回の起動時にユーザーが最新バージョンを表示できる可能性を最大限に高めるには、アプリケーションで断続的に更新を確認する必要があります。appcache マニフェストが変更された場合、キャッシュが更新されます。次にユーザーがアプリを起動すると、ブラウザーは、ユーザーが以前にアプリで作業していたときに読み込まれた最新バージョンを読み込みます。ポーリング間隔は、新しいリリース間の予想される間隔に調整できます。
利用可能な更新をユーザーに警告することもできます。「アプリケーションの更新が利用可能です。今すぐロードしますか? (ok) (破棄)」という目立たないメッセージが表示される可能性があります。すべてのリソースは事前に取得されているため、リロードはほぼ瞬時に行われます (すべてディスクから)。さらに難しいのは、すべてのユーザーのデータ (および「セッション状態」) を確実に保持することです。