Кэширование во время выполнения означает постепенное добавление ответов в кеш «по ходу». Хотя кэширование во время выполнения не повышает надежность текущего запроса, оно может помочь сделать будущие запросы для того же URL-адреса более надежными.
HTTP-кэш браузера является примером кэширования во время выполнения; он заполняется только после запроса данного URL-адреса. Но сервис-воркеры позволяют вам реализовать кэширование во время выполнения, выходящее за рамки того, что может предложить только HTTP-кеш.
Стратегия
В отличие от предварительного кэширования (которое всегда пытается обслуживать набор заранее определенных файлов из кэша), кэширование во время выполнения может сочетать доступ к сети и к кэшу несколькими способами. Каждая комбинация обычно называется стратегией кэширования. Ключевые стратегии кэширования включают в себя:
- Сеть прежде всего
- Кэш-сначала
- Устаревшие при повторной проверке
Сеть прежде всего
При таком подходе ваш сервисный работник сначала пытается получить ответ из сети. Если сетевой запрос удался, отлично! Ответ возвращается в ваше веб-приложение, а копия ответа сохраняется с помощью API хранилища кэша — либо создается новая запись, либо обновляется предыдущая запись для того же URL-адреса.
Если сетевой запрос полностью завершается неудачей или для возврата ответа требуется слишком много времени , вместо этого возвращается самый последний ответ из кэша.
Кэш-сначала
Стратегия «сначала кэш» фактически противоположна стратегии «сначала сеть». При таком подходе, когда ваш сервис-воркер перехватывает запрос, он сначала использует API хранилища кэша, чтобы узнать, доступен ли кэшированный ответ. Если да, этот ответ возвращается в веб-приложение.
Однако если произойдет промах в кэше, то сервис-воркер обратится к сети и попытается получить там ответ. Если сетевой запрос успешен, он возвращается в ваше веб-приложение, а его копия сохраняется в кеше. Эта кэшированная копия будет использоваться для обхода сети при следующем запросе тех же URL-адресов.
Устаревшие при повторной проверке
Устаревшие при повторной проверке — это что-то вроде гибрида. При его использовании ваш сервисный работник немедленно проверит наличие кэшированного ответа и, если он будет найден, передаст его обратно в ваше веб-приложение.
Тем временем, независимо от того, было ли совпадение с кэшем, ваш сервис-воркер также отправляет сетевой запрос, чтобы получить «свежий» ответ. Этот ответ используется для обновления любого ранее кэшированного ответа. Если первоначальная проверка кэша прошла неудачно, копия ответа сети также передается обратно в ваше веб-приложение.
Почему вам следует использовать Workbox?
Эти стратегии кэширования представляют собой рецепты, которые вам обычно придется переписывать в своем собственном сервис-воркере снова и снова. Вместо того, чтобы прибегать к этому, Workbox предлагает их в виде пакета как часть своей библиотеки стратегий , готовой к тому, что вы сможете обратиться к своему сервисному работнику.
Workbox также обеспечивает поддержку управления версиями, позволяя автоматически истечь срок действия кэшированных записей или уведомлять ваше веб-приложение при возникновении обновлений ранее кэшированной записи.
Какие из ваших активов следует кэшировать и с помощью каких стратегий?
Кэширование во время выполнения можно рассматривать как дополнение к предварительному кэшированию. Если все ваши ресурсы уже предварительно кэшированы, все готово — нет ничего, что нужно кэшировать во время выполнения. Скорее всего, для любого относительно сложного веб-приложения вы не будете предварительно кэшировать все .
Большие медиафайлы, ресурсы, которые обслуживаются со стороннего хоста, такого как CDN, или ответы API — это лишь несколько примеров типов ресурсов, которые невозможно эффективно предварительно кэшировать. Используйте панель «Сеть» в DevTools, чтобы определить запросы, попадающие в эту категорию, и для каждого из них подумайте, какой компромисс между свежестью и надежностью является подходящим.
Используйте устаревшие при повторной проверке, чтобы отдать приоритет надежности над свежестью.
Поскольку стратегия «устаревший во время повторной проверки» возвращает кэшированный ответ почти сразу же — после того, как кеш был заполнен посредством первого запроса — вы в конечном итоге увидите стабильно высокую производительность при использовании этой стратегии. Это связано с необходимостью получения обратно данных ответа, которые могут быть устаревшими по сравнению с тем, что было бы получено из сети. Использование этой стратегии лучше всего работает для таких ресурсов, как изображения профиля пользователя или первоначальные ответы API, используемые для заполнения представления, когда вы знаете, что немедленное отображение чего-либо является ключевым моментом, даже если это более старое значение.
Используйте приоритет сети, чтобы отдать приоритет свежести над надежностью.
В каком-то смысле использование стратегии, ориентированной на сеть, означает признание поражения в борьбе с сетью: ей отдается приоритет, но это влечет за собой неуверенность в надежности. Для некоторых типов активов предпочтительнее увидеть свежий ответ, чем вернуть устаревшую информацию. Например, вы можете предпочесть свежесть при запросе к API текста статьи, которая часто обновляется.
Используя стратегию «сначала сеть» внутри сервис-воркера, вместо того, чтобы просто идти против сети напрямую, вы получаете возможность вернуться к чему-то , даже если это потенциально устаревший ответ. Вы не будете надежно быстрыми, но, по крайней мере, будете надежными в автономном режиме.
Используйте кэширование для версионных URL-адресов
В стратегии кэширования, как только запись кэшируется, она никогда не обновляется. По этой причине убедитесь, что вы используете его только с активами, которые, как вы знаете, вряд ли изменятся. В частности, это лучше всего работает для URL-адресов, содержащих информацию о версии — тех же URL-адресов, которые также должны обслуживаться с заголовком ответа Cache-Control: max-age=31536000 .