Service WorkerはSafari対応の見通しより先に通常pageの更新を守る

公開日：2018年2月25日執筆：佐藤

Service Workerを使えば、通信が不安定なときにもpageを表示しやすくしたり、読み込みを軽くしたりできる。ただし、対応browserが増えることと、会社のpageへすぐ入れることは別である。営業時間、料金、問い合わせ先のように古い案内が困る情報は、Service Workerが動かない画面でも読め、更新後に新しい内容へ替わる状態を先に作る。

WebKitは2月7日、Service Worker APIの実装状況を公表した。Safari Technology Preview 48、macOS High Sierra 10.13.4、iOS 11.3 beta seed 2で利用でき、Safari、SFSafariViewControllerを使うapp、home screenへ保存したWeb applicationでの対応が示されている。実装と対応範囲は変化しているため、Safariで使えるという一点だけで、読者全員が同じ仕組みを使えると決めない。

読み込みを速くする仕組みと最新情報を見せる仕組みを分ける

Service Workerは、pageの裏側で処理を行い、offline対応やnetwork、cacheの最適化に使える。ここで混同しやすいのは、表示が速いことと、表示された内容が新しいことだ。前に保存した画像やCSSを使えば、見た目は早く出る。しかし、営業時間や休業日の文章まで古いままなら、読者へ誤った案内をしてしまう。

たとえば、店舗の案内pageで、headerの画像、共通のCSS、logoを保存することは考えやすい。これらは更新の頻度が低く、古いものが一時的に見えても、問い合わせの内容を変えることは少ない。一方、臨時休業、予約の空き、価格、申込期限を本文へ書くpageは、保存した画面をそのまま見せる範囲に入れない方がよい。必要な情報を取りに行けないときは、古い内容を確定情報のように出すより、確認できないと知らせる方が安全な場合がある。

何を保存するかは、fileの種類だけで決めない。同じHTMLでも、会社案内のように変わりにくいpageと、告知のように日付で役割が変わるpageがある。まずpageを、変わりにくい共通部分、更新しても読者の行動が変わらない情報、更新が読者の判断を変える情報に分ける。最後のものは、最新の内容を取れることを優先する。

Safariの対応を導入条件にしない

対応するbrowserが一つ増えると、そのbrowser向けの便利な画面を作りたくなる。しかし、Service Workerを使うpageは、対応していないbrowserや、JavaScriptを止めた環境でも、必要な説明と連絡先へ進めなければならない。機能を使える人だけを前提にすると、読者が読めない理由をこちらで見つけにくい。

そこで、最初に通常のHTTP requestだけで読めるpageを作る。menu、本文、電話番号、問い合わせform、送信後の案内を、Service Workerが登録されていないbrowserで確かめる。その後で、対応するbrowserにだけ保存や表示の補助を加える。こうしておけば、Service Workerの登録に失敗しても、site全体が使えなくならない。

特に問い合わせformは、画面を見せられることと、送信を受け付けられることを分ける。入力画面を保存しておく補助はできても、送信内容の正本をbrowserの保存だけに置いてはいけない。送信先で受け取り、担当者が確認し、読者へ次の案内を返す経路は、通常の通信として確かめる。Service Workerがあるから送信の失敗まで自動で防げる、と考えない。

更新が届くかを公開前に通して見る

Service Workerを入れた後に起きやすいのは、制作者の画面では新しいpageが見えるのに、読者の画面では以前の案内が残ることだ。更新を公開するときは、HTMLを直したかだけで終わらせず、保存済みのfileを使う状態で何が見えるかを確かめる。

確認用に、影響の小さいpageを一つ選ぶ。見出しや画像を変更し、通常に開いた画面で新しい内容が見えるかを見る。次に、すでに一度開いたbrowserで同じpageを開き直す。最後に、通信を切った状態を試すなら、何を見せ、何を見せないかが案内どおりかを見る。この順序なら、更新した内容、保存した内容、通信できないときの表示を分けて判断できる。

変更を入れる人と、公開画面を確認する人も決めておく。小さなsiteでは一人が両方行ってよいが、確認した日時とpageを残す。制作を外へ頼む場合は、Service Workerのfileをどこで更新するのか、通常表示へ戻す方法は何かを引き渡してもらう。見た目の制作物だけを受け取ると、後から営業時間を直したときに、どの画面が古いのか分からなくなる。

先に保存しないpageを決める

導入時は、cacheを増やすより、保存しないpageを先に決める方が運用しやすい。問い合わせ、申込み、予約、価格表、期限付きのお知らせは候補にする。これらは、読者が内容を見て行動を決めるため、古い表示の影響が大きい。

たとえば、予約のpageで日程を更新したなら、読者は画面を見て連絡するか決める。古い日程が残れば、電話やmailで余計な確認が増え、受ける側にも負担がかかる。pageを速く見せるために保存した結果、連絡のやり取りが増えるなら、本来の目的から外れる。保存の対象を絞るのは、技術を使わないためではなく、情報を正しく伝えるためである。

Service Workerは、対応browserの数だけで価値を決める仕組みではない。普通に開けるpageを土台にし、何を保存し、何を毎回確かめるかを分ける。Safariでの対応が進む今こそ、速さの機能を足す前に、更新情報と問い合わせの入口を守る順序を決めておく。