重い腰を上げてServiceWorkerに触れました（Service Worker の紹介）。
こんなにも簡単にブラウザキャッシュできるのか！と感動し、「速い速いと言われるdev.toでも使っているんでしょう？」と見てみたら更なる感動があったので内容を書き残します。
何をやっていた？
結論から
- dev.toにアクセスした時点で、記事ページのhtmlがキャッシュされる（上から6枚くらい）
- オフライン用のhtmlがキャッシュされていて、リクエストが失敗する（= キャッシュされていない）画面ではこれが返される
- スクロールする毎に記事ページのhtmlを取りに行き、次々にキャッシュする
なので、dev.toにアクセスした後にオフラインになったとしても
- ファーストビューに出ている記事くらいは見ることが可能で
- それ以降の記事を踏まれたとしても「ネット回線切れているよー」というhtmlが表示されるため、殺風景な画面を見ることがない
ということになっていました。
serviceworker.jsの内容
minifyされていますが、chromeさんのdevToolsでフォーマットしてみても
たったの63行！！
なので、是非実際に見てみてください。
ここではざっくり内容を書きます。
イベント
install、activate、fetchのみ設定されています。
install
- 各画面共通のリソースをキャッシュ
activate
- キャッシュの更新
fetch
- 取得したレスポンスデータをキャッシュ
- リクエストにマッチするキャッシュがある場合にキャッシュを返す
- キャッシュがなく、リクエストも失敗した場合にオフライン用htmlを返す
ServiceWorker導入のハードル
レスポンスデータをキャッシュして返す、という点に絞ってみた場合ですが
- サイトがSSL化されている
- 実装に少しだけ時間がかかる
これだけで、これさえクリアすれば
- ページの高速化
- オフライン時でも何らかのレスポンスを返す
ことができるようになります。
ServiceWorker非対応の環境ではこれまで通りサーバーにリクエストが飛ぶだけなので、入れない理由がないと思いました。
結論
すぐやります。
パクります。