BinaryDevelop
  1. ホーム
  2. Web制作
  3. html5

HTML5によるアプリケーションキャッシュの実装

2022-01-27 08:38:17

なぜ Application Cache 技術を使うのか？

HTML5以前は、インターネットにアクセスする必要があり、サーバーへの多重リクエストでサイトの速度が低下したのは間違いありません。PCユーザーの場合、ネットワークは比較的安定しており、読み込み速度もそれほど悪くありません。しかし、モバイルの場合はどうでしょうか。モバイル側は、無線信号に依存し、信号塔に依存し、場所は固定されていない、近くの建物の影響を受ける、などです。ネットワークの不安定につながるのシリーズは、我々はユーザーを変更することはできませんし、ネットワークの遅いユーザーをあきらめることはできません。
また、ハイブリッドアプリ空間では、内蔵のwebviewは、しばしばhtmlページをロードするために使用され、これはまだネットワークが遅すぎる場合、上記の問題を引き起こす可能性があります。

オフラインストレージ技術

実際には、HTML5の技術から生まれたApplication CacheやLocalStorageが主に開発で使われています。

(1) アプリケーションキャッシュ：通常、静的なリソース（静的ページ）をキャッシュするために使用される。
(2)LocalStorage。通常、AJAXリクエストのキャッシュに使用され、重要でないAJAXデータを保存する。

なぜApplication Cache技術が使われるのか、一段落して説明します。
ページの一部の要素が一定である場合、Application Cache技術を使ってオフラインでキャッシュすることで、これらのキャッシュされた要素にアクセスするたびにサーバーにリクエストする必要がなくなり、一部のものが頻繁に変わる場合、その都度サーバーにリクエストさせればいいのです！。

HTML5 Application Cacheの機能

HTML5では、アプリケーションキャッシュが導入され、インターネット接続がない場合でも、Webアプリケーションをキャッシュしてアクセスできるようになりました。
アプリケーションキャッシングは、アプリケーションに3つの利点をもたらします。
(1) オフラインブラウジング：ユーザーがネットワークに関与していない時に利用をアクセスすることができる
(2) 速度向上：キャッシュされたリソースの読み込みが速くなる
(3) サーバーへのリクエストの削減：ブラウザはサーバーから更新または変更されたリソースのみをダウンロードします。
サポートします。アプリケーションキャッシュは、Internet Explorerを除くすべてのブラウザでサポートされています。

Application Cacheを始めるにあたって

関係する役割：サーバーとhtmlファイル

サーバーサイドで行うべきこと

manifest.appcacheファイルのメンテナンスを管理し、マニフェストリストにアクセスできないファイルがないか確認し、被害を受けないよう適時更新します。

マニフェストファイル（W3Cは拡張子.appcacheを推奨しています。）
マニフェストファイルは単純なテキストファイルで、ブラウザに何がキャッシュされるか（そして何がキャッシュされないか）を通知します。

マニフェストファイルは、3つのセクションに分けることができます。

  • CACHE MANIFEST - この見出しの下にリストされたファイルは、最初のダウンロードの後にキャッシュされます。
  • NETWORK - この見出しの下にリストされているファイルは、サーバーへの接続を必要とし、キャッシュされません。
  • FALLBACK - この見出しの下にリストされているファイルは、ページにアクセスできない場合（例：404ページ）のフォールバックページを指定するものです。

ひとつひとつ整理していきましょう

I. CACHE MANIFEST (必須) 

CACHE MANIFEST
/reset.css
/logo.gif
/hx.js

マニフェストファイルには、CSS ファイル、GIF 画像、および JavaScript ファイルの 3 つのリソースが記載されています。マニフェスト ファイルが読み込まれると、ブラウザはこれら 3 つのファイルをサイトのルート ディレクトリからダウンロードします。ユーザーがインターネットから切断された場合でも、これらのリソースは利用可能です。
注：ファイルの場所は、サーバー上のファイルの実際のディレクトリに基づいており、パスが正しいことを確認してください。
要約すると、CACHE MANIFESTに記載されているリソースは、ローカルにキャッシュする必要があるファイル（キャッシュされるファイル）です。

II. ネットワーク 

NETWORK:
nav.html

NETWORKサブセクションでは、ファイル "nav.html" が決してキャッシュされず、オフラインで利用できないように指定されています。 

NETWORK:
*

アスタリスク（*）は、他のすべてのリソース/ファイルがインターネット接続を必要とすることを示すために使用することもできます。
注意：キャッシュを無効にするために、ホームインデックスをNETWORKに入れないと、プラグインなどが動作しなくなります。
要約すると、NETWORDは毎回要求する必要がある動的なリソースファイル（キャッシュされないファイル）のリソースをリストアップします。

III.フォールバック 

FALLBACK:
/index/ /404.html

FALLBACKサブセクションでは、インターネット接続が確立できない場合、/index/ディレクトリのすべてのファイルを"404.html"に置き換えることを指定しています。
注：最初のURIはリソース、2番目のURIは置換です。
まとめると FALLBACK は、ファイルがネットワークに接続できない場合やアクセスに失敗した場合に、後者の代替手段を使用して表示するリソースをリストアップします。(フレンドリーな代替ページ)

完全なマニフェストファイル 

CACHE MANIFEST
# Files that need to be cached2014.6.5
/reset.css
/logo.gif
/hx.js

NETWORK:
#Files that do not need caching2014.6.5
nav.html

FALLBACK:
#Files to be replaced2014.6.5
/index/ /404.html

注：#はコメント行の略です。一見シンプルなコメント行がとても便利なのですが、なぜでしょうか？画像を編集したり、JavaScriptの関数を変更したりすると、その変更は再キャッシュされない。コメント行に日付やバージョン番号、タイムキラー、md5コードなどを入れて更新することは、ブラウザにファイルを再キャッシュさせる一つの方法である。

htmlに必要なこと

manifest.appcache ファイルを取り込むだけです。 

<!DOCTYPE HTML>
<html manifest="manifest.appcache">

アプリケーションキャッシュの寿命破壊ルール

(1) Application Cacheのローカルキャッシュは、ユーザーがブラウザのキャッシュをクリアしたときに破棄されます。
(2) マニフェストファイルが変更されたとき、アプリケーションのキャッシュが更新されるため。画像を編集したり、JavaScript の関数を変更した場合、これらの変更は再キャッシュされず、Application Cache のローカルキャッシュは破壊されます。
(3) プログラムによるアプリケーションキャッシュの更新

manifest.appcacheファイルの深層部

最初の注意点は、NETWORKに入れるのもダメですが、indexホームページのキャッシュを絶対に無効にしないこと、これは仕様でありルールなので、守ってください。

HTTP関連のキャッシュヘッダーフィールド、およびhttpsのキャッシュページ制限は、マニフェストによって無視されるため、ユーザーエージェントがページを更新するまで期限切れになりません。つまり、HTTPSであってもオフラインで動作させることが可能なのです。

アプリケーションキャッシュのサイズ制限は、主要ブラウザで異なり、ほぼ5MBです。

リソースがキャッシュされている場合、そのブラウザからその絶対パスに対して直接リクエストを行うと、キャッシュ内のリソースにもアクセスすることになります。

マニフェストを含むページがキャッシュされるため、マニフェストキャッシュリストに表示しなくても、実質的にはマニフェストを含むページがキャッシュされることになります。

サイトが更新されるたびに、サーバー側で manifest.appcache ファイルをチェックし、更新することで、被害を回避しています。

サイト内の他のページは、manifest属性が設定されていなくても、要求されたリソースがキャッシュ内にあれば、キャッシュからアクセスされます。

マニフェストファイル、または内部にリストされたファイルのいずれかが正しくダウンロードされないと、更新プロセス全体が失敗し、ブラウザは古いキャッシュをそのまま使用し続けます。

実は、Application Cacheがリンクするページを明示的にリストアップする必要はありません。デフォルトでは、html 要素の manifest 属性を含むすべてのページがキャッシュされ、これらの自動的にキャッシュされるページはメイン エントリと呼ばれ、マニフェストにリストされるファイルは詳細エントリと呼ばれます。特定のファイルにオンラインでアクセスする必要がある場合、" whitelist"を作成することができます。NETWORK以下のエントリと同様に、これらのファイルはしばしばネットワーク エントリと呼ばれ、ネットワーク接続されるたびにサーバーから毎回要求されます。

1行目のCACHE MANIFESTは固定形式で必ず記述し、NETWORKとFALLBACKも任意で存在させなければならない。

FALLBACKのリソースは、マニフェストファイルと同じソースである必要があります。

マニフェストを参照する html は、マニフェスト ファイルと同じソースで、同じドメインの下にある必要があります。

マニフェストファイルが変更されると、リソース リクエスト自体が更新のトリガーとなります。

コメントは、上で詳しく説明したように、単に実行しないように振る舞うだけでなく、バージョン番号やタイムスタンプ、md5コードなどにすることができます。

マニフェスト ファイルのキャッシュ セクションではワイルドカードを使用できないため、手動で指定する必要があります（このための自動化ツールはありません）。

開発中、ajax経由でWCFデータを操作すると、最初の1回または数回は正常にデータがロードされ、その後ロードに失敗することがよくあります。

Webオフラインキャッシング機構が有効なため、ajaxがデータを読み込むたびに、ajaxのgetモードを使ってローカルのキャッシュファイルから読み込まれ、getモードのキャッシュのため、サーバーからデータを再要求しないため、データの読み込みに失敗するのです。

ajax投稿モードに変更した後、データはキャッシュされないので、サイトが更新されるたびに、サービスからデータが要求されます。

エラーの報告です。Application Cache Error イベントです。マニフェストの取得に失敗しました(404)

回避策
マニフェストファイルは、正しい MIME タイプで構成する必要があります ("text/cache-manifest")。
manifest は contentType = text/cache-manifest であり、推奨拡張子は .appcache です。
で、ウェブサーバー上で設定する必要がありますが、サーバーによって異なります。

ページオフライン、ajax更新。

まず、マニフェストファイルを修正してページを更新することができますが、記事コンテンツページはオフラインなので、ローカルに保存され、もしあなたが支部なら、記事コンテンツページは保存され、同じURLで訪問すると、記事内のデータが更新されているかどうかにかかわらず、オフラインページは更新されません(マニフェストファイルを更新しない限り)。だから、すべての動的なデータは、あなたが取得するためにAjaxの方法を使用する必要があり、ちょうどクライアントのように、オフラインページは、データなしで空のシェルでなければなりませんし、Ajaxを介して空のシェルを埋めるためにデータをプルするために。その後、ajaxリクエストのアドレスは、マニフェストのネットワークに書き込まれる必要があることに注意してください。

オフラインのページ更新（ロングテール問題）

サイト更新時にユーザーのローカルオフラインページを更新するにはどうすればよいですか？
多くの記事にあるように、まずファイルをオンラインにして、ページに導入されているcache.manifestファイルを修正するだけで、例えばコメントを修正した後、再度ページにアクセスすると、まず更新があった場合にマニフェストを確認しに行き、更新があれば、再度ページを更新すると、ページが更新されることになります。
ロングテールの問題（非常に重要）。
あなたのマニフェストファイルが更新された場合、前述のように、あなたがページにアクセスすると、一度更新する必要があり、更新されたページでロードするため、問題がある、あなたのバックエンドデータ、つまり、JS Ajaxインタフェースのデータの変更に、あなたはJSに対応しても変更されます。次に、ライン上のマニフェストを変更すると、ページを開いた最初の時間は、ページが順番にされます。もう一度ページをリフレッシュすると、正常に表示されます。つまり、このファーストアクセスバグは、見たくないものなのです。
また、ユーザーがいつ2回目にあなたのページに戻ってくるか分からないので、マニフェストで一度オフラインになったページは、クライアントサイドのようになり、ロングテールの問題が発生します。幸いなことに、マニフェストには、ファイルの更新を判断し、読み込むためのいくつかの js インターフェースがあります。

cache.statusプロパティは、現在のオフラインアプリケーションのステータスを返します。

  • UNCACHED ( 値 0): オフラインアプリケーションは有効ではありません。
  • IDLE ( 値 1 ) です。オフラインアプリが有効であるが、ローカルにキャッシュされたリソースが最新であり、非推奨としてマークされていない。
  • CHECKING ( 値 2): アップデートキャッシュの現在のステータスは "checking"です。
  • DOWNLOADING ( 値 3): 現在、キャッシュの状態を "downloading resources" に更新しています。
  • UPDATEREADY ( 値 4): 現在の更新キャッシュのステータスは "Updated"です。
  • OBSOLETE ( 値 5): オフラインのアプリケーションは開いているが、キャッシュされたリソースは非推奨とマークされている。

ファイルがキャッシュサイズ5Mを超えるとどうなりますか？
例えば、私のチャンネルAが独自のアプリケーションキャッシュを維持し、チャンネルBがそれを維持する場合、今回チャンネルAはその使用量がピークに達した場合、チャンネルBのキャッシュをすべて失敗させることになるのです。
ですから、Application Cacheはビジネスリソースではなく、パブリックリソースを保存することをお勧めします!

更新メカニズムによって、マニフェストが更新された最初の時間は、ページロードを開始または終了しているため、キャッシュの更新はまだ完了していない、ブラウザはまだ期限切れのリソースを使用します。ブラウザは、アプリケーションキャッシュが更新されると、その時間は、新しいリソースを使用しない、2回目が使用されますです。この時、更新イベントは、window.reloadイベントを実行します。 

window.applicationCache.addEventListener("updateready", function(){
    window.location.reload()
});

上記の例からわかるように、キャッシュは表示で定義されたファイルだけでなく、例えば、上記の例のapplicationcache/はデフォルトでindex.htmlをマッピングデータとして保存し、demo.appcacheファイルを含んでおり、何度もファイルの更新行が更新されないことに遭遇するでしょう、今回は何気にマニフェストの設定ファイルで少し変更すれば更新できるようになっているのです。
以下のコードを変更します。 

<html manifest="A.appcache">
=>
<html manifest="B.appcache">

このとき、A.appcacheの更新を行わないと、index.htmlがキャッシュされ、元のマニフェストが検出されたままなので、キャッシュの更新が行われません
各ページが一様にマニフェストを管理する、つまりaページがcommon.jsで構成され、bページもcommon.jsで構成され、aページが更新された後は
bページのマニフェストが変更されない場合、bページは古いバージョンのファイルを読み込んだままなので、意味はありますが、公開ページで処理を行う必要があり、無駄が生じます。

HTML5 Application Cacheに関する記事は以上です。HTML5 Application Cacheの詳細については、過去の記事を検索していただくか、引き続き以下の記事をご覧ください。

関連

最新

おすすめ

について
/
プライバシー・ポリシー
/
お問い合わせ
© 2022 BinaryDevelop. すべての権利は、それぞれの所有者に帰属します