Сервисные работники и API хранилища кэша

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

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

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

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

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

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

API хранилища кэша

Поддержка браузера

  • 43
  • 16
  • 41
  • 11.1

Источник

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 .