アプリケーションキャッシュの使用

このアプリケーションキャッシュ機能を使用しないでください!これはウェブプラットフォームから削除する手続中のものです

非推奨

この機能は非推奨になりました。まだ対応しているブラウザーがあるかもしれませんが、すでに関連するウェブ標準から削除されているか、削除の手続き中であるか、互換性のためだけに残されている可能性があります。使用を避け、できれば既存のコードは更新してください。このページの下部にある互換性一覧表を見て判断してください。この機能は突然動作しなくなる可能性があることに注意してください。

安全なコンテキスト用

この機能は一部またはすべての対応しているブラウザーにおいて、安全なコンテキスト (HTTPS) でのみ利用できます。

はじめに

HTML5 は、ウェブアプリケーションをオフラインで実行できるようにするためのアプリケーションキャッシュの仕組みを提供しています。この Application Cache (AppCache) インターフェイスは、ブラウザーがオフラインで利用できるようにキャッシュするべきリソースを列挙します。キャッシュされたアプリケーションは、ユーザーが更新ボタンを押しても、オフラインで読み込まれて正常に動作します。

アプリケーションキャッシュは以下のような利益をもたらします。

オフラインブラウジング
オフライン状態であってもユーザーがサイトを閲覧できます。
速度
キャッシュされたリソースはローカルに置かれることになり、その結果、より速く読み込まれます。
サーバー不の削減
ブラウザーはサーバーから変更されたリソースのみをダウンロードします。

アプリケーションキャッシュの動作

アプリケーションキャッシュの有効化

アプリケーションでアプリケーションキャッシュを有効にするには、 manifest 属性をアプリケーションページ内の <html> 要素に設定してください。

<html manifest="/example.appcache"></html>

manifest 属性の値は キャッシュマニフェスト ファイルの URL を参照します。これはアプリケーションのためにブラウザーがキャッシュするべき URL を列挙したテキストファイルです。

キャッシュしてほしいサイトのすべてのページに manifest 属性を含めてください。ブラウザーは manifest 属性のないページは、マニフェストファイルで列挙されていない限りキャッシュしません。マニフェストファイルにキャッシュしてほしいページをすべて列挙する必要はありません。なぜなら、ブラウザーは、ユーザーが訪問したページに manifest 属性があると、暗黙的にアプリケーションキャッシュに追加するからです。

ブラウザーによっては (例: Firefox) は、ユーザーがアプリケーションキャッシュを利用するアプリケーションを読み込む初回時に通知バーを表示します。通知バーは以下のようなメッセージを表示します。

このサイト (example.com) はオフライン作業用データの保存を求めています。 [許可] [このサイトでは保存しない] [今回は保存しない]

「オフライン(利用可能) アプリケーション」という表現は、ときに、ユーザーがオフライン機能を利用することを許可したアプリケーションを具体的に指すこともあります。

文書の読み込み

アプリケーションキャッシュの利用は文書を読み込む通常のプロセスを変更します:

  • アプリケーションキャッシュが存在する場合、ブラウザーは文書を読み込んで、それに関連付けられたリソースをネットワークにアクセスせずにキャッシュから直接取得します。これは文書の読み込み時間をスピードアップさせます。
  • ブラウザーはキャッシュマニフェストがサーバー上で更新されているかどうかをチェックします。
  • キャッシュマニフェストが更新されていた場合、ブラウザーはマニフェストの新しいバージョンとそのマニフェスト内に列挙されたリソースをダウンロードします。これはバックグランドで行われ、パフォーマンスに大きな影響を与えません。

文書を読み込み、アプリケーションキャッシュを更新するプロセスの詳細は以下のようになります。

  1. ブラウザーは manifest 属性を含む文書を訪れたとき、アプリケーションキャッシュが存在しなければ、文書を読み込んでから、マニフェストファイルに列挙されたすべてのエントリーを取得して、アプリケーションキャッシュの最初のバージョンを作成します。
  2. その文書へのその後の訪問では、ブラウザーは文書とマニフェストファイルで指定されたその他のリソースを (サーバーからではなく) アプリケーションキャッシュから読み込みます。さらに、ブラウザーは window.applicationCache オブジェクトに checking イベントを送り、適切な HTTP キャッシュ規則に従い、マニフェストファイルを取得します。
  3. マニフェストファイルの現在のキャッシュされたコピーが最新であった場合、ブラウザーは applicationCache オブジェクトに noupdate イベントを送り、更新プロセスは完了します。サーバー上のキャッシュされたリソースを変更する場合、マニフェストファイル自身も変更する必要があることに注意してください。そうすることで、ブラウザーはすべてのリソースを再び取得する必要があることを知ります。
  4. マニフェストファイルが変更されていた場合、マニフェストに列挙されたファイルのすべて、および、 applicationCache.add() が呼ばれたことによってキャッシュに追加されたファイルが、適切な HTTP キャッシュ規則に従い、一時キャッシュに取得されます。この一時キャッシュに取得された各ファイル毎に、ブラウザーは applicationCache オブジェクトに progress イベントを送ります。エラーが起こった場合、ブラウザーは error イベントを送り、更新は中止されます。
  5. すべてのファイルが正常に取得されれば、それらは本当のオフラインキャッシュに動的に移動され、applicationCache オブジェクトに cached イベントを送ります。文書は既にキャッシュからブラウザーに読み込まれているので、更新された文書は文書が(手動かプログラムで)再読込されるまで描画されません。

ストレージの場所とオフラインキャッシュをクリアする

Chrome では、設定の "閲覧履歴データの消去..." を選択することか、chrome://appcache-internals/ を開くことで、オフラインキャッシュをクリアできます。Safari では、設定に、似たような "キャッシュを空にする" がありますが、ブラウザーの再起動も必要になるかもしれません。

Firefox では、オフラインキャッシュデータは Firefox プロファイルに分割して保存されています。以下が通常のディスクキャッシュです:

  • Windows Vista/7: C:\Users\<username>\AppData\Local\Mozilla\Firefox\Profiles\<salt>.<profile name>\OfflineCache
  • Mac/Linux: /Users/<username>/Library/Caches/Firefox/Profiles/<salt>.<profile name>/OfflineCache

Firefox では、現在のステータスを about:cache ページ ("Offline cache device" の見出しがある箇所) で調査できます。オフラインキャッシュは ツール -> オプション -> 詳細 -> ネットワーク -> オフラインデータ の "削除..." ボタンを利用して各サイト毎に別々にクリアできます。

Firefox 11 以前から Firefox 11 まで、ツール -> 最近の履歴を消去、あるいは、ツール -> オプション -> 詳細 -> ネットワーク -> オフラインデータ -> 今すぐ消去 のどちらでもオフラインキャッシュを消せませんでしたが、このバグは修正されました。

Linux では、設定は Edit > Preferences > Advanced > Network > Offline Web Content and User Data にあります。

DOM Storage データをクリアするも参照してください。

アプリケーションキャッシュはもう利用されない状態にもなり得ます。アプリケーションマニフェストファイルがサーバーーから削除されたとき、ブラウザーはそのマニフェストを利用しているアプリケーションキャッシュをすべて削除し、applicationCache オブジェクトに "obsoleted" イベントを送信します。これはアプリケーションキャッシュの状態を OBSOLETE に設定します。

キャッシュマニフェストファイル

キャッシュマニフェストファイルを参照する

ウェブアプリケーションでの manifest 属性は、キャッシュマニフェストファイルからの相対パスか絶対 URL のどちらかを指定できます。 (絶対 URL はアプリケーションと同一生成元経由でなければなりません)。キャッシュマニフェストファイルはどんなファイル拡張子でもかまいませんが、text/cache-manifest MIME タイプで提供されなければなりません。

注: Apache サーバーでは、マニフェストファイル (.appcache) ファイルを設定するために、ルートディレクトリ又はアプリケーションと同じディレクトリの .htaccess ファイルに AddType text/cache-manifest .appcache を追加します。

キャッシュマニフェストファイルのエントリー

キャッシュマニフェストファイルはブラウザーがオフラインアクセスのためにキャッシュすべきリソースを列挙した単純なテキストファイルです。リソースは URI によって区別されます。キャッシュマニフェストに列挙されたエントリーはマニフェストと同じスキーマ、ホスト、およびポートでなければなりません。

例 1: 単純なキャッシュマニフェストファイル

以下は、www.example.com にある想像上のウェブサイトのための単純なキャッシュマニフェストファイルである example.appcache です。

CACHE MANIFEST
# v1 - 2011-08-13
# これはコメントです。
http://www.example.com/index.html
http://www.example.com/header.png
http://www.example.com/blah/blah

キャッシュマニフェストファイルは3つのセクション (後述する CACHE, NETWORK, FALLBACK) を含んでいます。上記の例では、セクションヘッダーがありません。そのため、すべてのデータ行は明示的 (CACHE) セクションであるとみなされます。これは、ブラウザーは列挙されたリソースのすべてをアプリケーションキャッシュにキャッシュすべきということを意味します。リソースは絶対、もしくは、相対 URL (例:index.html) のどちらかを用いて指定できます。

上記例での "v1" コメントがあるのには正当な理由があります。ブラウザーがアプリケーションキャッシュを更新するのは、マニフェストファイルがバイト単位で更新されたときだからです。キャッシュされたリソースを変更したとき (例えば、 header.png 画像を新しい画像に差し替えた場合)、ブラウザーにキャッシュの更新が必要であることを知らせるためにマニフェストファイルの内容も変更する必要があります。どんな変更でもマニフェストファイルに対して行うことができますが、バージョン番号を修正することが、おすすめできるベストプラクティスです。

重要: マニフェストファイル自身をキャッシュマニフェストファイルに指定しないようにしてください。さもなければ、ブラウザーは新しいマニフェストが利用可能であることを知ることがほぼ不可能になるでしょう。

キャッシュマニフェストファイルのセクション: CACHE, NETWORK, FALLBACK

マニフェストには3つの性質が異なるセクション、 CACHENETWORKFALLBACK があります。

CACHE:
これはキャッシュマニフェストファイルにおけるエントリーの既定のセクションです。CACHE: セクションヘッダー下 (もしくは CACHE MANIFEST の行の直後) に列挙されたファイルは、それらが初回時にダウンロードされた後に明示的にキャッシュされます。
NETWORK:
キャッシュマニフェストファイルにおける NETWORK セクションヘッダー下に列挙されたファイルは、サーバーーに接続する必要があるホワイトリスト化されたリソースです。ユーザーがオフライン状態であっても、これらのリソースへのリクエストはすべてキャッシュを無視します。ワイルドカードが利用できます。
FALLBACK:
FALLBACK: セクションは、リソースにアクセス不可能な場合にブラウザーが利用すべき代替ページを指定します。このセクションにおける各エントリーには 2 つの URI を列挙します。具体的には、最初はリソースであり、2 番目は代替リソースです。両方の URL は相対で、マニフェストファイルと同一生成元経由でなければなりません。ワイルドカードが利用できます。

CACHE, NETWORK, FALLBACK の各セクションは、キャッシュマニフェストファイル内でどんな順番でも列挙でき、各セクションは単一のマニフェストにおいて、複数回定義することができます。

例 2: より完全なキャッシュマニフェストファイル

以下は、 www.example.com にある想像上のウェブサイト向けのより完全なキャッシュマニフェストファイルです:

CACHE MANIFEST
# v1 2011-08-14
# これは別のコメントです
index.html
cache.html
style.css
image1.png

# 利用可能ならネットワーク経由で利用する
NETWORK:
network.html

# 代替コンテンツ
FALLBACK:
. fallback.html

この例は NETWORKFALLBACK セクションを用いて、 network.html ページは常にネットワーク経由で取得し、 fallback.html ページは代替リソース (例えば、サーバーへの接続ができない場合) として提供されるべきであることを指定しています。

キャッシュマニフェストファイルの構造

キャッシュマニフェストファイルは text/cache-manifest という MIME タイプで提供される必要があります。この MIME タイプを使って提供されるすべてのリソースは、このセクションで定義されている、アプリケーションキャッシュマニフェストのための構文に従う必要があります。

キャッシュマニフェストは UTF-8 形式のテキストファイルで、任意で BOM 文字を含むこともできます。改行文字は、ラインフィード (U+000A)、キャリッジリターン (U+000D)、あるいはその両方で表すことができます。

キャッシュマニフェストの1行目は、ゼロあるいはそれ以上のスペースまたはタブ文字に続けて「CACHE MANIFEST」という文字列で構成される必要があります。2 つの単語の間にはひとつのスペース (U+0020) が含まれます。1行目に書かれたそれ以外の文字列は無視されます。

キャッシュマニフェストの残りの部分は、ゼロあるいはそれ以上の、以下の行によって構成されます:

空白行
ゼロあるいはそれ以上のスペースまたはタブ文字から成る空白行を用いることができます。
コメント
コメントは、ひとつの # 文字に続くゼロあるいはそれ以上のスペースまたはタブ文字と、それに続くゼロあるいはそれ以上のコメント文字列によって構成されます。コメントは (最初の CACHE MANIFEST 行の後の) 単独の行のみで用いることができ、他の行に付加することはできません。これは、フラグメント識別子を指定できないことを意味します。
セクションヘッダー
セクションヘッダーは、キャッシュマニフェストのどのセクションが操作されるかを示すものです。3種類のセクションヘッダーを用いることができます:
セクションヘッダー 説明
CACHE: キャッシュマニフェストの明示的セクションに切り替えます。これは既定のセクションです。
NETWORK: キャッシュマニフェストのオンラインホワイトリストセクションに切り替えます。
FALLBACK: キャッシュマニフェストの代替セクションに切り替えます。
セクションヘッダ行には空白を含めることも可能ですが、セクション名には必ずコロンを含める必要があります。
セクションデータ
データ行の形式はセクションとごとに異なります。明示的 (CACHE:) セクションでは、各行は、キャッシュのリソースを参照する妥当な URI または IRI です(このセクションではワイルドカード文字は一切利用できません)。各行の URI または IRI の前後には空白を含めることも可能です。 Fallback セクションでは、各行は、リソースと、それに続いて、サーバーとの接続ができないときに提供される代替リソースを参照する妥当な URI または IRI です。ネットワークセクションでは、各行は、ネットワークから取得できるリソースを参照する 妥当な URI または IRI です(このセクションではワイルドカード文字である * が利用できます)。
注意: 相対 URI は、マニフェストを参照する文書の URI ではなく、キャッシュマニフェストの URI からの相対となります。

キャッシュマニフェストは、それぞれのセクションを任意で行き来することができます (つまり、各セクションヘッダを複数回用いることができます)。また、セクションを空白にしておくことも許容されています。

アプリケーションキャッシュ内のリソース

アプリケーションキャッシュには、少なくとも 1 つの URI で識別されるリソースが常に含まれています。すべてのリソースは以下のカテゴリのいずれかに当てはまります。

マスターエントリ
これらは、ユーザーが訪問した閲覧コンテキストに、 manifest 属性を使用してこのキャッシュにあることを示す文書が含まれていたためにキャッシュに追加されたリソースです。
明示的なエントリ
これらはアプリケーションのキャッシュマニフェストファイルに明示的に掲載されているリソースです。
ネットワークエントリ
これらはアプリケーションのキャッシュマニフェストファイルにネットワークエントリとして掲載されているリソースです。
フォールバックエントリ
これらはアプリケーションのキャッシュマニフェストファイルにフォールバックエントリとして掲載されているリソースです。
注: リソースは複数のカテゴリでタグ付けすることができるので、複数のエントリに分類することができます。例えば、エントリは明示的なエントリと予備のエントリの両方を持つことができます。

リソースのカテゴリについては、以下で詳しく説明します。

マスターエントリ

マスターエントリとは、 manifest 属性を <html> 要素に含む HTML ファイルのことです。例えば、http://www.example.com/entry.html という HTML ファイルがあるとします。

<html manifest="example.appcache">
  <h1>アプリケーションキャッシュの例</h1>
</html>

entry.htmlexample.appcache キャッシュマニフェストファイルに掲載されていない場合、 entry.html ページにアクセスすると、 entry.html がマスターエントリとしてアプリケーションキャッシュに追加されます。

明示的なエントリ

明示的なエントリは、キャッシュマニフェストファイルの CACHE セクションに明示的にリストされたリソースです。

ネットワークエントリ

キャッシュマニフェストファイルの NETWORK セクションは、ウェブアプリケーションがオンラインアクセスを必要とするリソースを指定します。アプリケーションキャッシュ内のネットワークエントリは本質的に「オンラインホワイトリスト」であり、 NETWORK セクションで指定された URI はキャッシュの代わりにサーバーから読み込まれます。これにより、ブラウザーのセキュリティモデルは、承認されたリソースへのアクセスを制限することで、潜在的なセキュリティ侵害からユーザーを保護することができます。

例として、ネットワークエントリを使用して、キャッシュの代わりにサーバーからスクリプトなどのコードをロードして実行することができます。

CACHE MANIFEST
NETWORK:
/api

上記のキャッシュマニフェストセクションは、 http://www.example.com/api/ サブツリーに含まれるリソースをロードするリクエストが、キャッシュにアクセスしようとせずに常にネットワークに移動することを保証します。

: マスターエントリ (html 要素に設定された manifest 属性を持つファイル) をマニフェストファイルから単に省略しても、マスターエントリはアプリケーションキャッシュに追加され、その後アプリケーションキャッシュから提供されるため、同じ結果にはなりません。

フォールバックエントリ

フォールバックエントリは、リソースの読み込みに失敗したときに使用されます。例えば、キャッシュマニフェストファイル http://www.example.com/example.appcache に以下の内容が含まれているとします。

CACHE MANIFEST
FALLBACK:
example/bar/ example.html

http://www.example.com/example/bar/ またはそのサブディレクトリとそのコンテンツへのリクエストにより、ブラウザーはリクエストされたリソースの読み込みを試みるためのネットワークリクエストを発行します。この試みがネットワーク障害や何らかのサーバーエラーのために失敗した場合、ブラウザーは代わりに example.html というファイルをロードします。

キャッシュ状態

各アプリケーションキャッシュは、キャッシュの現在の状態を示す状態を持っています。同じマニフェスト URI を共有するキャッシュは同じキャッシュの状態を共有します。

UNCACHED
アプリケーションキャッシュオブジェクトが完全に初期化されていないことを示す特別な値です。
IDLE
アプリケーションキャッシュは現在更新中ではありません。
CHECKING
マニフェストを取得し、更新をチェックしています。
DOWNLOADING
リソースのマニフェストが変更されたため、キャッシュに追加するためにリソースをダウンロードしています。
UPDATEREADY
新しいバージョンのアプリケーションキャッシュが利用可能です。対応する updateready イベントがあり、新しい更新プログラムがダウンロードされたが swapCache() メソッドを使用してまだ有効化されていない場合に cached イベントの代わりに発生します。
OBSOLETE
アプリケーションキャッシュグループは廃止されました。

キャッシュマニフェストの更新の確認

JavaScript を使用して、アプリケーションが更新されたキャッシュマニフェストファイルを持っているかどうかをプログラムでテストすることができます。スクリプトが更新をテストするためにイベントリスナーをアタッチする前にキャッシュマニフェストファイルが更新されている可能性があるので、スクリプトは常に window.applicationCache.status をテストする必要があります。

function onUpdateReady() {
  console.log('found new version!');
}
window.applicationCache.addEventListener('updateready', onUpdateReady);
if(window.applicationCache.status === window.applicationCache.UPDATEREADY) {
  onUpdateReady();
}

新しいマニフェスト ファイルのテストを手動で開始するには、 window.applicationCache.update() を使用してください。

Gotchas

  • 従来の GET 引数 (other-cached-page.html?parameterName=value) を使用してキャッシュされたファイルにアクセスしないでください。これは、ブラウザーがキャッシュをバイパスしてネットワークから取得しようとすることになります。 JavaScript で解析されたパラメータを持つキャッシュされたリソースにリンクするには、リンクのハッシュ部分に other-cached-page.html#whatever?parameterName=value のような引数を使用します。
  • アプリケーションがキャッシュされている場合、ウェブページで使用されるリソース (ファイル) を更新するだけでは、キャッシュされたファイルを更新することはできません。ブラウザーが更新されたファイルを取得して使用する前に、キャッシュマニフェストファイル自体を更新する必要があります。これは window.applicationCache.swapCache() を使用してプログラムで行うことができますが、すでに読み込まれているリソースは影響を受けません。リソースが新しいバージョンのアプリケーションキャッシュから読み込まれるようにするには、ページをリフレッシュするのが理想的です。
  • ウェブサーバー上で *.appcache ファイルの expires ヘッダを設定して、すぐに期限切れになるようにすることをお勧めします。これにより、マニフェストファイルをキャッシュするリスクを回避することができます。例えば、 Apache ではこのような設定を次のように指定することができます。
    ExpiresByType text/cache-manifest "access plus 0 seconds"

ブラウザーの互換性

BCD tables only load in the browser

関連情報