Чтобы переводить контент на ваш предпочитаемый язык, Google использует технологии на основе искусственного интеллекта. Переводы от ИИ могут содержать ошибки.

Сервис-воркеры и Cache Storage API

Jeff Posnick

Вы застряли в борьбе за надежность сети. HTTP-кеш браузера – это первая линия обороны, но, как вы уже знаете, он эффективен только при загрузке URL с версиями, которые вы посещали ранее. Одного кеша HTTP недостаточно.

К счастью, теперь у нас есть два новых инструмента, которые помогут вам справиться с этой проблемой: сервис-воркеры и Cache Storage API. Поскольку они часто используются вместе, стоит изучить их одновременно.

Скрипты Service Worker

Сервис-воркер встроен в браузер и управляется небольшим фрагментом кода JavaScript, который вы должны создать. Вы развертываете его вместе с другими файлами, из которых состоит ваше веб-приложение.

У сервисного работника есть некоторые особые полномочия. Помимо прочего, он терпеливо ждет, пока ваше веб-приложение сделает исходящий запрос, а затем начинает действовать, перехватывая его. Что сервисный работник делает с этим перехваченным запросом, зависит от вас.

Для некоторых запросов лучшим решением может быть просто разрешить запросу продолжить работу в сети, как если бы сервисного работника вообще не было.

Однако для других запросов вы можете использовать более гибкое решение, чем HTTP-кеш браузера, и возвращать быстрый ответ, не беспокоясь о сети. Для этого нужно использовать другую часть головоломки: Cache Storage API.

Cache Storage API

Browser Support

Source

Cache Storage API открывает совершенно новые возможности, предоставляя разработчикам полный контроль над содержимым кеша. В отличие от HTTP-заголовков и встроенных в браузер эвристических алгоритмов, Cache Storage API позволяет управлять кешированием с помощью кода. Cache Storage API особенно полезен при вызове из JavaScript сервисного работника.

Подождите… Теперь нужно думать ещё об одном кеше?

Вероятно, у вас возникли вопросы, например: "Нужно ли мне по-прежнему настраивать HTTP-заголовки?" и "Что я могу делать с новым кешем, чего нельзя было делать с HTTP-кешем?" Не волнуйтесь, это естественная реакция.

Даже если вы используете Cache Storage API, мы рекомендуем настроить заголовки Cache-Control на веб-сервере. Обычно для URL без версий достаточно задать значение Cache-Control: no-cache, а для URL с версиями (например, хешами) – Cache-Control: max-age=31536000.

При заполнении кеша Cache Storage API браузер по умолчанию проверяет наличие записей в кеше HTTP и использует их, если они найдены. Если вы добавляете URL с версиями в кеш Cache Storage API, браузер не отправляет дополнительный сетевой запрос. С другой стороны, если вы неправильно настроите заголовки Cache-Control, например укажете длительный срок хранения в кеше для URL без версии, то можете ухудшить ситуацию, добавив устаревший контент в Cache Storage API. Сортировка поведения HTTP-кеша является обязательным условием для эффективного использования Cache Storage API.

Новый API открывает множество возможностей. Вот несколько примеров, когда HTTP-кеша недостаточно:

Используйте подход "обновление в фоновом режиме" для кешированного контента, известный как stale-while-revalidate.
Установите ограничение на максимальное количество объектов для кеширования и реализуйте настраиваемые правила истечения срока действия, чтобы удалять элементы по достижении этого ограничения.
Сравните ранее кэшированные и свежие сетевые ответы, чтобы увидеть, изменилось ли что-нибудь, и позвольте пользователю обновить контент (например, с помощью кнопки), когда данные действительно были обновлены.

Подробнее о Cache API…

Основы API

При работе с API необходимо учитывать следующее:

Объекты Request используются в качестве уникальных ключей при чтении и записи в эти кеши. Для удобства вместо объекта Request в качестве ключа можно передать строку URL, например 'https://example.com/index.html', и API автоматически обработает ее.
В качестве значений в этих кешах используются объекты Response.
Заголовок Cache-Control в определенном Response фактически игнорируется при кешировании данных. Встроенных проверок на актуальность данных нет, поэтому объекты будут храниться в кеше до тех пор, пока вы не удалите их вручную. (Существуют библиотеки, которые упрощают обслуживание кеша. О них мы поговорим позже.
В отличие от старых синхронных API, таких как LocalStorage, все операции Cache Storage API асинхронны.

Краткое отступление: промисы и async/await

Сервисные скрипты и Cache Storage API используют концепции асинхронного программирования. В частности, они в значительной степени полагаются на обещания представлять будущий результат асинхронных операций. Прежде чем начать, ознакомьтесь с промисами и связанным с ними синтаксисом async/await.

Не развертывайте этот код… пока

Хотя они обеспечивают важную основу и могут использоваться как есть, и сервис-воркеры, и Cache Storage API фактически являются строительными блоками более низкого уровня с рядом крайних случаев и «подводных камней». Существуют инструменты более высокого уровня, которые могут помочь сгладить сложные части этих API и предоставить все необходимое для создания готового к работе сервис-воркера. В следующем руководстве рассматривается один из таких инструментов – Workbox.