Вы вовлечены в борьбу за надежность сети. HTTP-кеш браузера — это ваша первая линия защиты, но, как вы узнали, он действительно эффективен только при загрузке версионных URL-адресов, которые вы ранее посещали. Одного HTTP-кеша недостаточно.
К счастью, доступны два новых инструмента, которые помогут переломить ситуацию в вашу пользу: сервис-воркеры и Cache Storage API . Поскольку они так часто используются вместе, стоит узнать о них обоих одновременно.
Работники сферы обслуживания
Сервис-воркер встроен в браузер и управляется небольшим количеством дополнительного кода JavaScript, за создание которого вы несете ответственность. Вы развертываете его вместе с другими файлами, составляющими ваше фактическое веб-приложение.
У сервисного работника есть особые полномочия. Помимо других обязанностей, он терпеливо ждет, пока ваше веб-приложение сделает исходящий запрос, а затем начинает действовать, перехватывая его. Что сервис-воркер сделает с этим перехваченным запросом, зависит от вас.
Для некоторых запросов лучшим способом действий может быть просто позволить запросу продолжить работу в сети, точно так же, как это произошло бы, если бы вообще не было сервисного работника.
Однако для других запросов вы можете воспользоваться чем-то более гибким, чем HTTP-кеш браузера, и возвращать надежно быстрый ответ, не беспокоясь о сети. Это влечет за собой использование другой части головоломки: API хранилища кэша.
API хранилища кэша
API хранилища кэша открывает совершенно новый спектр возможностей, предоставляя разработчикам полный контроль над содержимым кэша. Вместо того, чтобы полагаться на комбинацию HTTP-заголовков и встроенной эвристики браузера, API Cache Storage предоставляет подход к кэшированию, управляемый кодом. API Cache Storage особенно полезен при вызове из JavaScript вашего сервис-воркера.
Подождите… есть еще один тайник, о котором стоит подумать сейчас?
Вы, вероятно, задаете себе такие вопросы, как «Нужно ли мне еще настраивать заголовки HTTP?» и «Что я могу сделать с этим новым кешем, чего невозможно было сделать с кешем HTTP?» Не волнуйтесь, это естественные реакции.
По-прежнему рекомендуется настраивать заголовки Cache-Control на веб-сервере, даже если вы знаете, что используете API Cache Storage. Обычно вам удается установить Cache-Control: no-cache для неверсионных URL-адресов и/или Cache-Control: max-age=31536000 для URL-адресов, содержащих информацию о версиях, например хеши.
При заполнении кеша API хранилища кэша браузер по умолчанию проверяет наличие существующих записей в кеше HTTP и использует их, если они найдены. Если вы добавляете версионные URL-адреса в кеш API Cache Storage, браузер избегает дополнительного сетевого запроса. Обратной стороной этого является то, что если вы используете неправильно настроенные заголовки Cache-Control , например, указывая длительный срок службы кэша для неверсионного URL-адреса, вы можете в конечном итоге усугубить ситуацию , добавив этот устаревший контент в API Cache Storage. Упорядочение поведения HTTP-кэша является необходимым условием для эффективного использования Cache Storage API.
Что касается того, что теперь возможно с этим новым API, ответ таков: очень много. Некоторые распространенные варианты использования, которые были бы затруднительны или невозможны при использовании только HTTP-кэша, включают:
- Используйте подход «обновление в фоновом режиме» для кэшированного содержимого, известный как устаревшее при повторной проверке.
- Установите ограничение на максимальное количество ресурсов для кэширования и внедрите специальную политику истечения срока действия для удаления элементов после достижения этого предела.
- Сравните ранее кэшированные и свежие ответы сети, чтобы увидеть, изменилось ли что-нибудь, и дайте пользователю возможность обновлять контент (например, с помощью кнопки), когда данные действительно были обновлены.
Чтобы узнать больше, ознакомьтесь с Cache API: краткое руководство .
API гайки и болты
��ри разра��от��е API следует учитывать некоторые моменты:
- Объекты
Requestиспользуются в качестве уникальных ключей при чтении и записи в эти кэши. Для удобства вы можете передать строку URL-адреса, например'https://example.com/index.html'в качестве ключа вместо фактического объектаRequest, и API автоматически обработает это за вас. - Объекты
Responseиспользуются в качестве значений в этих кэшах. - Заголовок
Cache-Controlв данномResponseфактически игнорируется при кэшировании данных. Не существует автоматических встроенных проверок срока действия или актуальности, и как только вы сохраните элемент в кеше, он будет сохраняться до тех пор, пока ваш код явно не удалит его. (Существуют библиотеки, которые упрощают обслуживание кэша. Они будут рассмотрены позже в этой серии.) - В отличие от старых синхронных API, таких как
LocalStorage, все операции API Cache Storage являются асинхронными.
Быстрый обход: промисы и async/await
Сервис-воркеры и API Cache Storage используют концепции асинхронного программирования . В частности, они в значительной степени полагаются на обещания, чтобы представить будущий результат асинхронных операций. Прежде чем приступить к работе, вам следует ознакомиться с промисами и соответствующим синтаксисом async / await .
Не развертывайте этот код… пока
Хотя они обеспечивают важную основу и могут использоваться как есть, и сервис-воркеры, и API Cache Storage фактически являются строительными блоками нижнего уровня с рядом крайних случаев и «подводных камней». Существует несколько инструментов более высокого уровня, которые могут помочь сгладить сложные моменты этих API и предоставить все необходимое для создания готового к работе сервис-воркера. В следующем руководстве рассматривается один такой инструмент: Workbox .