Что означает стратегия устаревания кеша?

Question

Я пытаюсь реализовать различные стратегии кэширования с помощью ServiceWorker. Для следующих стратегий способ реализации полностью ясен:

1. Кэш сначала
2. Только кэш
3. Сеть сначала
4. Сеть только

Например, при попытке реализовать стратегию «сначала кэшировать» в хуке выборки работника службы я сначала запрашиваю у CacheStorage (или любой другой) запрошенный URL, а затем, если существует, respondWith это и если не respondWith результат сетевого запроса.

Но для стратегии устаревания-пере-валидации в соответствии с этим определением рабочего ящика у меня есть следующие вопросы:

1. Сначала о самом механизме. Означает ли stale-while-revalidate, что использовать кеш до тех пор, пока сеть не ответит, а затем использовать сетевые данные или просто использовать сетевой ответ для обновления данных кеша в следующий раз?
2. Теперь, если сеть кэшируется для в следующий раз, тогда какой сценарий ios содержит реальный вариант использования этого?
3. И если сетевой ответ должен быть немедленно заменен в приложении, то как это может быть сделано для работника службы? Поскольку ловушка будет разрешена с кэшированными данными, а затем сетевые данные не могут быть разрешены (с respondWith).

Answer 1

1. Да, это означает именно это. Идея проста: ответить немедленно из кэша, а затем обновить sh кэш в фоновом режиме для в следующий раз .

2. Все сценарии ios, где не всегда важно получать самую последнюю версию страницы / приложения =) Я использую устаревшую стратегию для двух разных веб-приложений: одно для транспортных услуг c и одно для отображения информации меню ресторана. Многие сайты / приложения прекрасно с этим справляются, но, конечно, не все.

Одна очень важная вещь, которую следует отметить здесь на # 2: Вы можете, например,. используйте устаревшую проверку только для активов c. Таким образом, ваши html, js, css, изображения и т.д. c. будет кэшироваться и быстро предоставляться пользователю, но данные, извлекаемые динамически из API, могут все еще быть свободными sh. Для некоторых приложений это работает, для некоторых других не очень хорошо. Зависит полностью от приложения. Конечно, вы должны помнить, что не следует изменять семантику вашего API, если пользователь запускает предыдущую версию приложения и т. Д. c.

Невозможно в любом автомате c. Однако вы могли бы создать канал сообщений между Service Worker и «обычным JS кодом на странице» с помощью API window.postMessage. Вы можете прослушать определенные сообщения на странице, а затем от работника сервиса отправить сообщение, если произошло важное изменение и кэш был обновлен. Затем вы можете либо показать пользователю подсказку о том, что страницу действительно нужно перезагрузить прямо сейчас, либо даже принудительно перезагрузить ее с JS. Вы должны будете поместить этот лог c определения того, когда произошло важное обновление в Service Worker, конечно.