Прибытие сервисных работников привело к большому количеству улучшений в сети. Есть много вариантов использования для сервисных работников.
Однако имеет ли смысл использовать Cache API с точки зрения чисто кэширования?
Многие подходы делают предположения о том, как будут обрабатываться ресурсы.
Часто только URL-адрес используется для определения того, как ресурс должен обрабатываться с помощью таких стратегий, как «Сеть в первую очередь», «Только сеть», «Устаревшая проверка», «Кэширование сначала» и «Только кеширование». Это может быть утомительной работой, потому что вы должны определить определенный обработчик для многих URL. Это не масштабируется.
Вместо этого я думал об использовании обычного HTTP-кэша в сочетании с Cache API. Заголовки ответа содержат полезную информацию, которую можно использовать для кеширования и проверки, может ли кеш еще использоваться или будет доступна новая версия. Вместе с кэшированием передовой практики (например, https://jakearchibald.com/2016/caching-best-practices/), это может создать универсальный сервисный работник, который не будет обновляться при изменении ресурсов.
Основываясь на заголовках ответов, ресурс может обрабатываться пользовательским обработчиком. Если заголовки когда-либо будут обновлены, при необходимости можно будет обрабатывать ресурс с другим обработчиком.
Но потом я понял, что просто переопределяю кеш браузера с помощью Cache API. Это будет означать, что ресурсы будут кэшироваться в два раза (если принять это с некоторой долей соли), сохраняя их как в кеше браузера, так и рабочего сервиса. Кроме того, хотя API-интерфейс Cache обеспечивает больший контроль, большинство обработчиков можно (вроде) моделировать с помощью кэша http:
- Только сеть: Cache-Control: no-store
- Только кэш: Cache-Control: неизменяемый
- Cache first: Cache-Control: максимальный возраст с проверкой (Etag, Last Modified, ...)
- Stale-while-revalidate: Контроль кэша: stale-while-revalidate
Я не сразу вижу, как имитировать сеть, но с другой стороны это будет означать поддержку автономного использования (или плохого соединения). (Имейте в виду, это не тот вариант использования, который я ищу).
Хотя всегда полезно предоставить запасной вариант (с использованием сервисных работников и Cache API), стоит ли, чтобы ресурсы, возможно, кэшировались в два раза и копировали логику кэширования браузера? Я знаю, что Cache API можно использовать для предварительного кэширования ресурсов, но я думаю, что они также могут быть переданы при предварительном запросе.
Наконец, я знаю, что браузер отвечает за управление кэшем браузера, и разработчик имеет ограниченный контроль над ним (используя заголовки HTTP Cache).
Но браузер также может выбрать удаление всего кэша рабочего сервиса для очистки дискового пространства. Есть способы убедиться, что кеш сохраняется, но здесь дело не в этом.
Мои вопросы:
- Какими преимуществами обладает Cache API, который не может быть смоделирован с обычным кешем браузера?
- Что можно кэшировать с помощью Cache API, но не с помощью обычного кэша браузера?
- Есть ли другой способ создать работника сервиса, который не требует обновления