ホームページ  >  記事  >  ウェブフロントエンド  >  HTML5 アプリケーション キャッシュの解析 Application Cache

HTML5 アプリケーション キャッシュの解析 Application Cache

怪我咯
怪我咯オリジナル
2017-04-05 15:26:001641ブラウズ

アプリケーションキャッシュとは

HTML5ではアプリケーションキャッシュ技術が導入されており、キャッシュマニフェストファイルを作成することで、Webアプリケーションをキャッシュしてネットワークなしで使用できるようになります。

アプリケーション キャッシュには 3 つの利点があります:

① オフライン ブラウジング

② ページの読み込み速度の向上

③ サーバーの負荷の軽減

そして、すべての主要なブラウザはアプリケーション キャッシュをサポートしており、サポートしていなくても間違いはありませんプログラムにはどのような影響がありますか?

オフライン ストレージ テクノロジ

HTML5 は、localstorage と Application Cache という 2 つの主要なオフライン ストレージ テクノロジを提案しています。どちらにも独自のアプリケーション シナリオがあります。 練習の後、私たちのタスク localstorage は重要ではない ajax データを保存する必要があります。これはおまけです。

アプリケーション キャッシュは静的リソースを保存するために使用されますが、これはさらにおまけです

小さなテキスト (4096 バイト) のみを保存するため、大きなデータは保存できません。これが Cookie と前述のキャッシュ テクノロジの違いの 1 つです。HTTP はステートレスであるため、サーバーは識別文字列を必要とします。リクエストは同じサーバーから送信され、このタスクは Cookie によって実行され、ユーザーの権限を確認するために毎回このテキストがサーバーとブラウザーの間で渡されます。

つまり、Application Cache の適用シナリオが異なるため、使用方法も一貫性がありません。

アプリケーション キャッシュの概要

アプリケーション キャッシュの使用には 2 つの側面の作業が必要です:

① サーバーはマニフェスト リストを維持する必要があります

② ブラウザ上で必要なのは簡単な設定のみです

<html  manifest="demo.appcache">

例を使って説明します:

CACHE MANIFEST

CACHE:
# 需要缓存的列表
style1.css
1.jpg
01.js

http://localhost/applicationcache/02.js


http://localhost/applicationcache/zepto.js

NETWORK:
# 不需要缓存的
4.jpg

FALLBACK:
# 访问缓存失败后,备用访问的资源,第一个是访问源,第二个是替换文件*.html /offline.html
2.jpg/3.jpg

まず、私はここでエラーを報告しました:

 Application Cache Error event: Manifest fetch failed (404)

このエラーの理由は次のとおりです: マニフェスト ファイルは正しい MIME タイプ、つまり "text/cache-manifest" で構成する必要があります。 Webサーバー上で設定する必要があり、サーバーが異なると

\APPLICATIONCACHE
    01.js
    02.js
    1.jpg
    2.jpg
    3.jpg
    4.jpg
    demo.appcache
    index.html
    style1.css
    style2.css
    web.config
    zepto.js
この方法では、この時点でネットワークが切断されていても、それらのファイルには引き続きアクセスできます

。ここで注目すべき点があります。たとえば、/index.html がここに含まれていない場合、実際には、これは、図に示すように、index.html


です。 , HTML5 ではいくつかの event

ポイントが定義されていますが、私たちは通常、何かを操作するために積極的に js を使用することはなく、ほとんどの場合、ブラウザーの処理に完全に依存しています。

サイズ制限

アプリケーション キャッシュのサイズ制限は 5M に統一されています。ここでテストしてみましょう:

示されているように、この時点では 2 つの CSS ファイルはまだ 5M を超えています

manifest 文件可分为三个部分:
CACHE MANIFEST - 在此标题下列出的文件将在首次下载后进行缓存
NETWORK - 在此标题下列出的文件需要与服务器的连接,且不会被缓存
FALLBACK - 在此标题下列出的文件规定当页面无法访问时的回退页面(比如 404 页面)

示されているように、style2 は次のことができます。キャッシュされた場合、どのような問題が発生しますか?

たとえば、チャネル A は独自のアプリケーション キャッシュを維持し、チャネル B も独自のアプリケーション キャッシュを維持します。このとき、チャネル A の使用量がピークに達すると、チャネル B のすべてのキャッシュが無効になるため、次のようになります。いくつかの問題

更新メカニズムに関しては、マニフェストが初めて更新されるとき、ページの読み込みがすでに開始されているか、完了していても、キャッシュの更新がまだ完了していないため、ブラウザーは期限切れのリソースを引き続き使用します。アプリケーション キャッシュが更新されると、今度はブラウザーがそれを使用せず、新しいリソースは 2 回目まで使用されません。このとき、updateイベント内でwindow.reloadイベントが実行されます。

Document was loaded from Application Cache with manifest http://localhost/applicationcache/demo.appcache
index.html:1 Application Cache Checking event
index.html:6 GET http://localhost/applicationcache/style2.css net::ERR_FAILED
index.html:1 Application Cache NoUpdate event
index.html:11 GET http://localhost/applicationcache/2.jpg net::ERR_FAILED
index.html:12 GET http://localhost/applicationcache/3.jpg net::ERR_FAILED

上記の例から、キャッシュは単なる表示定義ファイルではないことがわかります。たとえば、上記の例の applicationcache/ の場合、デフォルトでは、index.html がマップされたデータとして保存され、その中にこのとき、ファイルを更新するにはマニフェスト設定ファイルにいくつかの変更を加えるだけで済みます。

たとえば、次のコードを変更してみましょう:

建议Application Cache,存储公共资源,不要存储业务资源

この時点でdemo.appcacheが更新されていない場合、キャッシュは更新されません。その理由は、index.htmlがキャッシュされており、元のマニフェストリストが更新されていないためです。まだ検出されました 各ページは独自のマニフェスト リストを統一的に管理します。つまり、ページ a は common.js で構成され、ページ b も common.js で構成されます。これは、ページ a が更新された後、ページ b のマニフェストは変更されず、ページ b は依然として読み込まれます。古いバージョンのファイルの場合、これは理にかなっていますが、無駄でもあり、処理にはパブリック ページが必要です。

まとめ

使いやすさと使いやすさの点では、アプリケーション キャッシュを使用する価値がありますが、静的リソースをキャッシュするのが最善です。実際にオフライン アプリケーションを実装するには、より多くの労力がかかります。

以上がHTML5 アプリケーション キャッシュの解析 Application Cacheの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。