Service Workerはoffline対応より先にcacheの更新方法を決める

Service Workerでoffline対応を始めるなら、先にcacheを更新する方法を決めてください。古いCSSやJavaScriptを返せば、pageの見た目と操作が食い違います。offlineで開けることだけを確認しても、更新を届けられなければ運用できません。

Service Workerは、登録した範囲のrequestを受け取り、通常のnetwork応答とは別の応答を返せます。cacheから返すfileとnetworkから取り直すfileを分けられるため、便利な反面、どの版が利用者へ届くかを制作側が決める必要があります。

ここでいう更新は、Service Workerのscriptだけを更新することではありません。CSSを直した、JavaScriptを差し替えた、logoを変えた、本文の案内を修正したという変更が、cacheに残っている古い応答と食い違わないことを確かめる作業です。公開側では新しいHTMLを返しているのに、利用者のbrowserが古いCSSを受け取れば、見出しやbuttonの位置が崩れることがあります。更新内容とcacheの版を同じ記録で扱います。

cacheへ入れるfileと毎回取り直すdataを分ける

W3CのService Workers Working Draftは、Service Workerをeventに応答するWeb Workerとして定義し、requestに対する応答を差し替えられる仕組みと、cacheの保存操作を示しています。登録にはinstalling、waiting、activeという状態があり、更新の手順も仕組みの一部です。

同じcacheへすべてを入れる必要はありません。例えば会社案内のlogoや共通CSSは、表示に必要な版をまとめて管理しやすいfileです。一方で、在庫、予約枠、問い合わせの送信結果のように内容が変わるdataを、古い応答のまま見せると判断を誤らせます。

記事本文も、更新の頻度で扱いを決めます。長く変わらない案内なら、通信が切れたときに前回保存した内容を読ませる意味があります。しかし、営業時間の変更、受付停止、価格条件の訂正のように古い内容が行動を誤らせるページは、offlineで何を返すかを慎重に決めます。何も返せない場合に「通信を確認してからもう一度開く」と示す方が、古い案内を断定的に見せるよりよいこともあります。

更新を出すたびに確認する順序を残す

Service Workerはdocumentに結び付いて動き続けるscriptではありません。eventがないときに停止し、次のeventで動き直すことがあります。画面内の変数だけへ更新状態を置くと、次の起動で前提が消えます。

更新のたびに、次の順序で確認します。

1. cacheへ入れるURLと、networkから取得するURLを書き出す。
2. 更新用のcache名を変え、新しいfileを登録する。
3. 新しいworkerがactiveになる条件を確認する。
4. 古いcacheを削除する処理を、更新後に動かす。
5. 通常の通信、通信を切った状態、更新直後の三つで同じpageを開く。

この順序を制作会社へ任せる場合も、cache名、登録scriptのURL、戻し方はsite所有者が分かる場所へ残します。作業を頼んでも、更新できる場所まで渡す必要はありません。

cache名を変える理由は、前の版と新しい版を区別するためです。名前を変えずに中身だけを書き換えると、どのfileがいつの版なのかを調べにくくなります。反対に、名前だけ増やして古いcacheを残せば、利用者の端末に不要な版が残ります。新しい版を入れる場所、以前の版を削除する場所、問題が出たときにどの版へ戻すかを一組で決めます。

更新時の確認表には、変更したfile名、cache名、公開日時、確認した端末、通常通信で見た結果、通信を切ったときの結果を書きます。表示が変わらない場合も、その画面が古いcacheを読んでいるのか、変更箇所が表示されていないのかを分けて調べられます。更新直後に利用者から「直っていない」と連絡が来たとき、公開したfileだけを見ても判断できません。

また、更新を確認するときに、管理者が開いた画面だけで終えないことも必要です。すでにサイトを開いているbrowserと、初めて開くbrowserでは、受け取るcacheの状態が違うことがあります。少なくとも、更新前に開いた画面を更新する場合と、新しく開く場合を分け、どちらに新しい内容が届くかを確認します。正しい版を届ける条件が分からないまま対象ページを増やしません。

offline画面は本来の操作を代わりにしない

通信が切れたときに、本文や連絡先を表示することはできます。ただし、送信が完了したように見える画面をcacheから返すと、問い合わせや注文の扱いが分からなくなります。offline用の応答は、利用者が次に取れる行動を示す範囲へ留めます。

たとえば問い合わせformを開く画面だけがofflineで表示されても、送信先へ届かなければ問い合わせは完了していません。送信buttonを押した後に通信が切れた場合も、送れた、送れなかった、もう一度送るべきかを、画面の見た目だけでは決められません。予約、注文、会員情報のように事業側の記録が必要な操作は、cacheから成功画面を返す対象にしません。利用者へ再接続後の確認方法を案内し、事業側では受信記録を別に確認します。

offline画面を用意するなら、通常のトップページをそのまま真似る必要はありません。通信がないこと、今はできない操作、再接続後にどこを開くかを伝えます。古い価格、空き状況、完了したように見える案内を置かないことが、内容を少なくするより重要です。読める情報と、確定できない操作を分けます。

最初の一手は、更新頻度の高いpageを一つ選び、cacheから返してよいURLと取り直すURLを二列で書き出すことです。そこから更新と戻し方を決めて、初めてoffline対応を加えます。

その表には、URLだけでなく、古い内容を返してよい理由、更新したときに確認する画面、問題が出たときに止める担当者も書きます。Service Workerは一度入れれば終わる機能ではありません。内容を変えるたびに、どの版を返し、どの版を捨てるかを判断する運用になります。offline対応の便利さより、更新した内容を説明できる状態を先に作ります。