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

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

  1. Сначала кеш
  2. Только кеш
  3. Сеть в первую очередь
  4. Только сеть

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

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

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

fetch caching service-worker service-worker-events
person ConductedClever    schedule 17.02.2020    source источник

Ответы (1)


arrow_upward
4
arrow_downward

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

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

Здесь, в № 2, следует отметить одну очень важную вещь: вы могли бы, например. используйте stale-while-revalidate только для статических ресурсов. Таким образом, ваши html, js, css, изображения и т. Д. Будут кэшироваться и быстро передаваться пользователю, но данные, динамически извлекаемые из API, могут быть свежими. Для некоторых приложений это работает, для некоторых - нет. Полностью зависит от приложения. Конечно, вы должны помнить, что не следует изменять семантику вашего API, если пользователь использует предыдущую версию приложения и т. Д.

  1. Невозможно никаким автоматическим способом. Однако вы могли бы реализовать канал сообщений между Service Worker и «обычным кодом JS на странице» с помощью API window.postMessage. Вы можете прослушивать определенные сообщения на странице, а затем от Service Worker отправить сообщение, когда произошло важное изменение и кеш был обновлен. Затем вы можете либо показать пользователю подсказку о том, что страницу действительно нужно перезагрузить прямо сейчас, либо даже принудительно перезагрузить ее из JS. Конечно, вам нужно будет поместить эту логику определения того, когда произошло важное обновление, в Service Worker.
person pate    schedule 17.02.2020
comment
Спасибо @pate. Очень хороший ответ. И я также хочу отметить, что таким образом стратегия кеширования будет использоваться только для соображений производительности (скорости), а не для уменьшения сетевого трафика, потому что запрос на повторную проверку будет отправляться каждый раз, когда кеш существует или нет. - person ConductedClever; 18.02.2020
comment
Это сбивает с толку определение stale-while-revalidate в b / c workbox отличается от определения http-кеша браузера, но имя то же самое. Браузер повторно проверяет подлинность только тогда, когда ресурс устарел ... что имеет смысл. workbox повторно проверяет КАЖДЫЙ запрос ..? Кажется расточительным. - person Eric Guan; 05.05.2020