要約

  • AppCacheは、回線が切れてもウェブアプリを開けるよう、ページが示すキャッシュ用マニフェストの資源をブラウザーに保存させた。サーバー上のスクリプトや画像を直すだけでは、その保存済みの組は更新されない。マニフェスト自体を変える必要があった。
  • 指定されたファイルが一つでも取得できなければ、更新全体が失敗し、古いアプリが残ることがあった。Chromeは2020年から段階的にAppCacheを終了した。オフライン利用のための小さな一覧が、リリースの決定点になっていた。

直したファイルが、利用者に届かない

サーバーのJavaScriptを修正した。開発者の作業は終わったように見える。ところが利用者のブラウザーでは、昨日の不具合がまだ動いている。AppCacheを使うページなら、Googleの開発者向け解説が原因を示していた。キャッシュ対象のスクリプトや画像を置き換えても、マニフェストが同じなら、それだけでは再取得されない。ブラウザーに新しい一式を用意させるには、一覧そのものを変更する。

コメント行の版番号を変えるだけでも、その合図になり得た。オフラインで動くアプリを守るための小さなテキストが、更新のスイッチも兼ねていた。修復済みのファイルはサーバーにいる。利用者のブラウザーがそれを受け取るかは、別の話だった。

つながらない場所でアプリを開くために

2008年5月のW3Cの解説は、メールや予定表などを通信圏外でも使いたいという動機から始まる。通常のHTTPキャッシュだけでは、アプリに必要な資源が全部残る保証はない。そこでHTMLのmanifest属性がtext/cache-manifestの文書を指し、保存するファイルを明示した。NETWORK:の欄には、なお通信が必要な要求を書けた。

この仕組みなら、ブラウザーは偶然残った断片ではなく、宣言された一式を持てる。その代わり更新も一式で扱われた。Googleの解説によれば、マニフェストか指定資源のダウンロードが一つ失敗すると、更新全体を取りやめ、古いアプリケーションキャッシュを使い続ける。新しい組が完成しても、すでに読み込まれたページは直ちに新しいファイルへ切り替わらず、再読み込みを要した。

半分だけ新しいアプリを配らないという判断には意味がある。同時に、main.jsだけ修正して一覧を忘れると古い動作が続く。一覧を変えても必須ファイルが欠ければ、やはり旧版が残る。「サーバーに修正がある」と「読者に修正が見えている」の間に、ブラウザーの更新処理が挟まった。

動かない一覧も、動きすぎる一覧も困る

マニフェストは変化しなければ更新の合図にならない。では毎回時刻を書き換えればよいのか。Googleの同じ解説は、それも避けるよう勧めた。ブラウザーは資源取得の前後でマニフェストを確かめる場合がある。その途中で一覧が変われば、異なる版のファイルが混ざった可能性があり、適用せず後でやり直す。

CACHE、NETWORK、FALLBACKの各欄は、保存するもの、ネットワークへ通すもの、失敗時に代わりを出すものを分けた。数行の文書がアプリの通信方針を決める。一つの必須資源が欠ければ、リンクが一つ壊れるだけでは済まず、新版の組全体が入れない。旧版を守る設計は、新版を届ける運用の厳しさでもあった。

ブラウザーは不完全な新しい組より、完全な古い組を選んだ。オフライン作業を壊さない利点があり、緊急修正が見えなくなる危険もある。部署したファイルを調べるだけでは、この違いは見つからない。読者のブラウザーで何が開くかを確かめる必要があった。

Chromeは出口の日程を決めた

Chromeの2020年の移行案内は、AppCacheの終了を段階的に示した。Chrome 85から標準では使えなくし、移行に時間が必要なサイトには一時的なオリジントライアルを設けた。オフライン機能の別の仕組みとしてService Workerを案内したが、移行にも境界があった。Chromeでは、Service Workerがページを制御し始めると、そのページでAppCacheは働かなくなる。新しい仕組みを半分だけ作り、残りを古いキャッシュに任せる手は使えない。

要求の扱い、保存する資源、開いたままのページへの新版の反映を、開発者は改めて設計しなければならなかった。Googleの移行用ツールも、AppCacheの一部の振る舞いは再現したが、window.applicationCacheのインターフェースやイベントは置き換えなかった。Chromeの退場日程は、各ブラウザーが同日に変わるという意味ではなく、Chrome向けアプリの具体的な移行時計だった。

AppCacheは、回線が消えてもページを残した。回線が戻り、サーバーに修正が届いても、一覧が変わらなければ古いページも残した。小さなマニフェストが、オフラインの安心と更新の遅れを同時に握っていた。