二度目以降のアクセスはキャッシュを使いHTTPリクエストしないでレスポンスをさらに向上できることを試してみた。Pushを試してみる。Pushを実現している。アプリケーションの前にNginxなどのProxyサーバーがある場合は、HTTPヘッダーにLinkヘッダーを追加してレスポンスを返すようにしたら良い。されていることがわかる。Workerはブラウザがwebページのスクリプトとは別のプロセスでスクリプトをバックグラウンドできる機能。プッシュ通知やモバイルアプリでのバックグラウンドでのデータの同期などが実現できる。Caniuseでみると各ブラウザのサポート状況はこんな感じ。HTTPS環境は必要。Workerを使うためのDebug環境を整えておく。自己証明書を許可するchromeでローカルホスト証明書を許可するようにフラグを切り替えておく。開くことで確認できる。一覧と内容、解除を操作できる。Workerの内容や開始、停止やデバックなどを行える。Workerについてざっくりと学ぶ。Workerのライフサイクルは次のようになる。Workerをダウンロード。メソッドをつかってjavascriptを登録する。'/'})登録の際にscopeパラメータオプションを指定できる。workerが制御可能なコンテンツを指定できる。Workerで制御できる。ちなみに何度か登録に失敗した、その場合は次のことが考えられる。いうイベントが順番に実行される。Workerが更新できる状況になるまで待つことになる。false);}各状態のイベントリスナーを追加することで、callbackできる。waitUntil()メソッドに引数で渡すことができる。false);今回はinstall時にファイルをキャッシュについする。クロスオリジンでのリクエストを防ぐ。以外のメソッド実行を防ぐ。workerを更新したいときなどに有効な手段っぽい。Workerがactivateな状態で、scope配下のページを移動したり、ページを更新したりすると、fetchイベントを受け取る。APIを介してに登録したり、読み込んだりできる。これにより実際にHTTPリクエストすることなくページを返すことができる。);});実際にリクエストしてみる。2回目はキャッシュを返す。WorkerがCacheを返し、ページが描画されることがわかる。再度ファイルをダウンロード、インストールを行う。Worker稼働しているので、新しくダウンロードしたファイルはwaitingになる。Workerコントーロール可能な状態となりactivateに遷移する。よりトラフィックは改善される。両者は技術的にも相性が良いなぁという感じ。デバイスによってはオフライン時でもキャッシュを利用できることで、恩恵を受けるものもありそう。Workerをサポートしてない(両方ともサポートしてない)場合でも副作用はないため、受けられる恩恵は大きい。App(PWA)は今後当たり前にウェブ開発の流れにシフトしていくんだろうな。