オフラインアプリのレシピ

良い一日、友達！



ServiceWorkerAPIとCacheAPIのさまざまな使用例を取り上げたJakeArchibaldの優れた記事「OfflineCookbook」の翻訳を紹介します。



コードが多く、単語が少ないため、これらのテクノロジーの基本に精通していることを前提としています。



慣れていない場合は、MDNから始めて、戻ってきてください。これは、特にビジュアルのためのサービスワーカーに関する別の良い記事です。



それ以上の序文なし。

いつリソースを節約しますか？

ワーカーを使用すると、キャッシュとは独立してリクエストを処理できるため、個別に検討します。



最初の質問は、いつリソースをキャッシュする必要があるかです。

依存関係としてインストールされた場合

ワーカーの実行中に発生するイベントの1つは、インストールイベントです。このイベントは、他のイベントを処理するための準備に使用できます。新しいワーカーがインストールされても、古いワーカーは引き続きページを提供するため、インストールイベントを処理してもページが破損することはありません。スタイル、画像、スクリプト、テンプレートのキャッシュに



適しています...一般的に、ページで使用される静的ファイルに適しています。



ネイティブアプリケーションの初期ダウンロードに含まれているファイルのようにアプリケーションが機能しないファイルについて話します。

self.addEventListener('install', event => {
    event.waitUntil(
        caches.open('mysite-static-v3')
            .then(cache => cache.addAll([
                '/css/whatever-v3.css',
                '/css/imgs/sprites-v6.png',
                '/css/fonts/whatever-v8.woff',
                '/js/all-min-v4.js'
                //  ..
            ]))
    )
})

event.waitUntilは、インストールの期間と結果を決定する約束を受け入れます。約束が拒否された場合、ワーカーはインストールされません。caches.openとcache.addAllは約束を返します。リソースの1つが使用できない場合、

cache.addAllの呼び出しは拒否されます。

依存関係としてではなくインストールされた場合

これは前の例と似ていますが、この場合、インストールが完了するのを待たないため、インストールはキャンセルされません。ゲームの後のレベルのリソースなど、現在必要とされていない大規模なリソースに



適しています。

self.addEventListener('install', event => {
    event.waitUntil(
        caches.open('mygame-core-v1')
            .then(cache => {
                cache.addAll(
                    //  11-20
                )
                return cache.addAll(
                    //     1-10
                )
            })
    )
})

レベル11〜20の場合はcache.addAllpromiseをevent.waitUntilに渡さないため、拒否された場合でもゲームはオフラインで実行されます。もちろん、最初のレベルのキャッシュで発生する可能性のある問題に注意し、たとえば、失敗した場合はキャッシュを再試行する必要があります。



ワーカーは、イベントの処理後、レベル11〜20がキャッシュされる前に停止できます。これは、これらのレベルが保存されないことを意味します。将来的には、この問題を解決するためにワーカーにバックグラウンド読み込みインターフェイスを追加したり、映画などの大きなファイルをダウンロードしたりする予定です。



約 Per 。：このインターフェイスは2018年の終わりに実装され、Background Fetchと呼ばれていましたが、これまでのところ、ChromeとOperaでのみ機能します（CanIUseによると68％）。

アクティベーション時

古いキャッシュの削除と移行に適しています。



新しいワーカーをインストールして古いワーカーを停止すると、新しいワーカーがアクティブ化され、アクティブ化イベントを受け取ります。これは、リソースを置き換えて古いキャッシュを削除する絶好の機会です。

self.addEventListener('activate', event => {
    event.waitUntil(
        caches.keys()
            .then(cacheNames => Promise.all(
                cacheNames.filter(cacheName => {
                    //  true, ,     ,
                    //  ,      
                }).map(cacheName => caches.delete(cacheName))
            ))
    )
})

アクティベーション中は、フェッチなどの他のイベントがキューに入れられるため、アクティベーションが長くなると、理論的にはページがブロックされる可能性があります。したがって、このステージは、古いワーカーでは実行できないことに対してのみ使用してください。

カスタムイベントが発生したとき

サイト全体をオフラインにできない場合に適しています。この場合、何をキャッシュするかをユーザーが決定できるようにします。たとえば、Youtubeビデオ、Wikipediaページ、Flickrの画像ギャラリーなどです。



ユーザーに[後で読む]または[保存]ボタンを表示します。ボタンがクリックされたら、リソースを取得してキャッシュに書き込みます。

document.querySelector('.cache-article').addEventListener('click', event => {
    event.preventDefault()

    const id = event.target.dataset.id
    caches.open(`mysite-article ${id}`)
        .then(cache => fetch(`/get-article-urls?id=${id}`)
            .then(response => {
                // get-article-urls     JSON
                //  URL   
                return response.json()
            }).then(urls => cache.addAll(urls)))
})

キャッシングインターフェイスは、ワーカー自体と同じようにページで使用できるため、リソースを節約するためにワーカーを呼び出す必要はありません。

応答を受信して​​いる間

ユーザーのメールボックスや記事のコンテンツなど、頻繁に更新されるリソースに適しています。アバターなどのマイナーコンテンツにも適していますが、この場合は注意が必要です。



要求されたリソースがキャッシュにない場合は、ネットワークから取得してクライアントに送信し、キャッシュに書き込みます。



アバターパスなどの複数のURLを要求する場合は、オリジンストア（オリジン-プロトコル、ホスト、ポート）をオーバーフローさせないようにしてください。ユーザーがディスク領域を解放する必要がある場合は、最初にすべきではありません。不要なリソースの削除に注意してください。

self.addEventListener('fetch', event => {
    event.respondWith(
        caches.open('mysite-dynamic')
            .then(cache => cache.match(event.request)
                .then(response => response || fetch(event.request)
                    .then(response => {
                        cache.put(event.request, response.clone())
                        return response
                    })))
    )
})

メモリを効率的に使用するために、応答本文を1回だけ読み取ります。上記の例では、cloneメソッドを使用して応答のコピーを作成しています。これは、クライアントに応答を送信し、それをキャッシュに書き込むために行われます。

新規性のチェック中

最新バージョンを必要としないリソースの更新に適しています。これはアバターにも当てはまります。



リソースがキャッシュにある場合はそれを使用しますが、次のリクエストで更新を取得します。

self.addEventListener('fetch', event => {
    event.respondWith(
        caches.open('mysite-dynamic')
            .then(cache => cache.match(event.request)
                .then(response => {
                    const fetchPromise = fetch(event.request)
                        .then(networkResponse => {
                            cache.put(event.request, networkResponse.clone())
                            return networkResponse
                        })
                        return response || fetchPromise
                    }))
    )
})

プッシュ通知を受け取ったとき

Push APIは、ワーカーを抽象化したものです。これにより、ワーカーはオペレーティングシステムからのメッセージに応答して実行できます。さらに、これはユーザーに関係なく発生します（ブラウザータブが閉じている場合）。ページは通常、特定のアクションを実行するための許可を求める要求をユーザーに送信します。チャットメッセージ、ニュースフィード、メールなど、通知に依存するコンテンツに



適しています。リスト内のタスクやカレンダー内のマークなどのコンテンツを同期するためにも使用されます。



結果は、クリックすると対応するページを開くという通知です。ただし、通知を送信する前にリソースを節約することが非常に重要です。ユーザーは通知を受信するとオンラインになりますが、クリックするとオフラインになる可能性があるため、その時点でコンテンツをオフラインで利用できることが重要です。Twitterモバイルアプリはこれを少し間違っています。



ネットワーク接続がない場合、Twitterは通知関連のコンテンツを提供しません。ただし、通知をクリックすると削除されます。それをしないでください！



次のコードは、通知を送信する前にキャッシュを更新します。

self.addEventListener('push', event => {
    if (event.data.text() === 'new-email') {
        event.waitUntil(
            caches.open('mysite-dynamic')
                .then(cache => fetch('/inbox.json')
                    .then(response => {
                        cache.put('/inbox.json', response.clone())
                        return response.json()
                    })).then(emails => {
                        registration.showNotification('New email', {
                            body: `From ${emails[0].from.name}`,
                            tag: 'new-email'
                        })
                    })
        )
    }
})

self.addEventListener('notificationclick', event => {
    if (event.notification.tag === 'new-email') {
        // ,   ,    /inbox/  ,
        // ,   
        new WindowClient('/inbox/')
    }
})

バックグラウンド同期あり

バックグラウンド同期は、ワーカーに対するもう1つの抽象化です。これにより、1回限りまたは定期的なバックグラウンドデータ同期を要求できます。また、ユーザーからも独立しています。ただし、許可の要求も彼に送信されます。マイナーリソースの更新に



適しています。通知を定期的に送信する頻度が高すぎるため、ソーシャルネットワークの新しいイベントやニュースフィードの新しい記事など、ユーザーに迷惑をかけます。

self.addEventListener('sync', event => {
    if (event.id === 'update-leaderboard') {
        event.waitUntil(
            caches.open('mygame-dynamic')
                .then(cache => cache.add('/leaderboard.json'))
        )
    }
})

キャッシュの保存

ソースは一定量の空き領域を提供します。このスペースは、ローカルとセッション、インデックス付きデータベース、ファイルシステム、そしてもちろんキャッシュなど、すべてのストレージ間で共有されます。



ストレージサイズは固定されておらず、デバイスとストレージの状態によって異なります。次のように確認できます。

navigator.storageQuota.queryInfo('temporary').then(info => {
    console.log(info.quota)
    // : <  >
    console.log(info.usage)
    //  <    >
})

このストレージまたはそのストレージのサイズが制限に達すると、このストレージは、現時点では変更できない特定のルールに従ってクリアされます。



この問題を解決するために、許可要求を送信するためのインターフェース（requestPersistent）が提案されました。

navigator.storage.requestPersistent().then(granted => {
    if (granted) {
        // ,       
    }
})

もちろん、ユーザーはこれに対する許可を与える必要があります。ユーザーはこのプロセスに参加している必要があります。ユーザーのデバイスのメモリがいっぱいで、マイナーデータを削除しても問題が解決しない場合、ユーザーはどのデータを保持し、どのデータを削除するかを決定する必要があります。



これが機能するためには、オペレーティングシステムがブラウザストアを個別のアイテムとして扱う必要があります。

リクエストへの回答

キャッシュするリソースの数は関係ありません。ワーカーは、いつ、何を使用するかを指示するまで、リソースを使用しません。リクエストを処理するためのいくつかのテンプレートを次に示します。

現金のみ

ページの現在のバージョンの静的リソースに適しています。リクエストに応じてリソースを送信できるようにするには、ワーカーのセットアップフェーズでこれらのリソースをキャッシュする必要があります。

self.addEventListener('fetch', event => {
    //     ,
    //      
    event.respondWith(caches.match(event.request))
})

ネットワークのみ

分析データや非GETリクエストなど、キャッシュできないリソースに適しています。

self.addEventListener('fetch', event => {
    event.respondWith(fetch(event.request))
    //     event.respondWith
    //      
})

最初にキャッシュ、次に障害が発生するとネットワーク

オフラインアプリケーションでのほとんどのリクエストの処理に適しています。

self.addEventListener('fetch', event => {
    event.respondWith(
        caches.match(event.request)
            .then(response => response || fetch(event.request))
    )
})

保存されたリソースはキャッシュから返され、保存されていないリソースはネットワークから返されます。

時間があった人は誰でも食べました

低メモリデバイスのパフォーマンスを向上させるために、小さなリソースに適しています。



古いハードドライブ、アンチウイルス、および高速インターネット接続の組み合わせにより、キャッシュからデータをフェッチするよりも、ネットワークからデータをフェッチする方が速くなります。ただし、データがユーザーのデバイスに保存されている間にネットワークからデータを取得することは、リソースの浪費です。

// Promise.race   ,   
//       .
//   
const promiseAny = promises => new Promise((resolve, reject) => {
    //  promises   
    promises = promises.map(p => Promise.resolve(p))
    //   ,    
    promises.forEach(p => p.then(resolve))
    //     ,   
    promises.reduce((a, b) => a.catch(() => b))
        .catch(() => reject(Error('  ')))
})

self.addEventListener('fetch', event => {
    event.respondWith(
        promiseAny([
            caches.match(event.request),
            fetch(event.request)
        ])
    )
})

約 レーン：これで、この目的でPromise.allSettledを使用できますが、ブラウザーのサポートは80％です。ユーザーの-20％は多分多すぎます。

最初にネットワーク、次に障害が発生した場合はキャッシュ

記事、アバター、ソーシャルネットワーク上のニュースフィード、プレーヤーの評価など、頻繁に更新され、サイトの現在のバージョンに影響を与えないリソースに適しています。



これは、新しいコンテンツをオンラインユーザーに提供し、古いコンテンツをオフラインユーザーに提供していることを意味します。ネットワークからのリソースの要求が成功した場合は、キャッシュを更新する必要があります。



このアプローチには1つの欠点があります。ユーザーに接続の問題があるか遅い場合は、キャッシュからコンテンツを即座にフェッチするのではなく、リクエストが完了するか失敗するのを待つ必要があります。この待機は非常に長くなる可能性があり、ひどいユーザーエクスペリエンスになります。

self.addEventListener('fetch', event => {
    event.respondWith(
        fetch(event.request).catch(() => caches.match(event.request))
    )
})

最初にキャッシュ、次にネットワーク

頻繁に更新されるリソースに適しています。



これには、ページが2つの要求を送信する必要があります。1つはキャッシュ用で、もう1つはネットワーク用です。アイデアは、キャッシュからデータを返し、ネットワークからデータを受信したときにそれを更新することです。



新しいデータ（プレーヤーの評価など）を受け取ったときに現在のデータを置き換えることができる場合もありますが、これは大きなコンテンツでは問題があります。これにより、ユーザーが現在読んでいるものや操作しているものが消える可能性があります。



Twitterは、スクロールを維持しながら、既存のコンテンツの上に新しいコンテンツを追加します。ユーザーには、画面の上部に新しいツイートの通知が表示されます。これは、コンテンツの線形順序のおかげで可能です。このテンプレートをコピーして、キャッシュからコンテンツをできるだけ早く表示し、Webから取得した新しいコンテンツを追加しました。



ページのコード：

const networkDataReceived = false

startSpinner()

//   
const networkUpdate = fetch('/data.json')
    .then(response => response.json())
        .then(data => {
            networkDataReceived = true
            updatePage(data)
        })

//   
caches.match('/data.json')
    .then(response => {
        if (!response) throw Error(' ')
        return response.json()
    }).then(data => {
        //      
        if (!networkDataReceived) {
            updatePage(data)
        }
    }).catch(() => {
        //      ,  -   
        return networkUpdate
    }).catch(showErrorMessage).then(stopSpinner)

ワーカーコード：



ネットワークにアクセスしてキャッシュを更新します。

self.addEventListener('fetch', event => {
    event.respondWith(
        caches.open('mysite-dynamic')
            .then(cache => fetch(event.request)
                .then(response => {
                    cache.put(event.request, response.clone())
                    return response
                }))
    )
})

安全網

キャッシュとネットワークからリソースを取得しようとして失敗した場合は、フォールバックが必要です。プレースホルダー（画像をダミーに置き換える）、失敗したPOSTリクエスト、「オフラインでは使用できません」ページに



適しています。

self.addEventListener('fetch', event => {
    event.respondWith(
        //     
        //   ,   
        caches.match(event.request)
            .then(response => response || fetch(event.request))
            .catch(() => {
                //    ,  
                return caches.match('/offline.html')
                //       
                //    URL   
            })
    )
})

ページがメールを送信した場合、ワーカーは送信する前にインデックス付きデータベースに保存し、送信が失敗したことをページに通知できますが、メールは保存されました。

ワーカー側でマークアップを作成する

サーバー側でレンダリングされ、キャッシュできないページに適しています。



ページのサーバー側レンダリングは非常に高速なプロセスですが、レンダリングごとに異なる可能性があるため、動的コンテンツをキャッシュに保存しても意味がありません。ページがワーカーによって制御されている場合は、リソースを要求して、その場でページをレンダリングできます。

import './templating-engine.js'

self.addEventListener('fetch', event => {
    const requestURL = new URL(event.request.url)

    event.respondWith(
        Promise.all([
            caches.match('/article-template.html')
                .then(response => response.text()),
            caches.match(`${requestURL.path}.json`)
                .then(response => response.json())
        ]).then(responses => {
            const template = responses[0]
            const data = responses[1]

            return new Response(renderTemplate(template, data), {
                headers: {
                    'Content-Type': 'text/html'
                }
            })
        })
    )
})

一緒

1つのテンプレートに制限する必要はありません。ほとんどの場合、要求に応じてそれらを組み合わせる必要があります。たとえば、訓練されたスリルは以下を使用します。

• 永続的なUI要素のワーカーセットアップキャッシング
• Flickrの画像とデータに対するサーバーの応答のキャッシング
• キャッシュからデータを取得し、ほとんどのリクエストでネットワークから失敗した場合
• フリック検索結果のためにキャッシュから、次にWebからリソースを取得する

リクエストを見て、それをどうするかを決めるだけです。

self.addEventListener('fetch', event => {
    //  URL
    const requestURL = new URL(event.request.url)

    //       
    if (requestURL.hostname === 'api.example.com') {
        event.respondWith(/*    */)
        return
    }

    //    
    if (requestURL.origin === location.origin) {
        //   
        if (/^\/article\//.test(requestURL.pathname)) {
            event.respondWith(/*    */)
            return
        }
        if (/\.webp$/.test(requestURL.pathname)) {
            event.respondWith(/*    */)
            return
        }
        if (request.method == 'POST') {
            event.respondWith(/*     */)
            return
        }
        if (/cheese/.test(requestURL.pathname)) {
            event.respondWith(
                // . .:    -   ?
                new Response('Flagrant cheese error', {
                //    
                status: 512
                })
            )
            return
        }
    }

    //  
    event.respondWith(
        caches.match(event.request)
            .then(response => response || fetch(event.request))
    )
})

この記事がお役に立てば幸いです。清聴ありがとうございました。