Кэширование Service Worker и HTTP-кэширование

Преимущества и недостатки использования согласованной или различной логики истечения срока действия в кэше сервис-воркера и HTTP-кэше.

Jonathan Chen

Хотя сервис-воркеры и прогрессивные веб-приложения (PWA) становятся стандартом современных веб-приложений, кэширование ресурсов стало сложнее, чем когда-либо. В этой статье рассматривается общая картина кэширования в браузерах, включая:

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

Обзор процесса кэширования

В общих чертах, при запросе ресурса браузер следует приведенному ниже порядку кэширования:

1. Кэширование сервис-воркера : Сервис-воркер проверяет, находится ли ресурс в его кэше, и решает, возвращать ли ресурс самостоятельно, основываясь на запрограммированных стратегиях кэширования. Обратите внимание, что это не происходит автоматически. Вам необходимо создать обработчик события fetch в вашем сервис-воркере и перехватывать сетевые запросы, чтобы запросы обрабатывались из кэша сервис-воркера, а не из сети.
2. HTTP-кэш (также известный как кэш браузера) : Если ресурс найден в HTTP-кэше и еще не устарел, браузер автоматически использует этот ресурс из HTTP-кэша.
3. На стороне сервера: если в кэше сервис-воркера или HTTP-кэше ничего не найдено, браузер обращается к сети для запроса ресурса. Если ресурс не кэширован в CDN, запрос должен быть отправлен обратно на исходный сервер.

Уровни кэширования

кэширование сервис-воркеров

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

Управление кэшем сервис-воркера

Сервис-воркер перехватывает HTTP-запросы с помощью обработчиков событий (обычно это событие fetch ). Этот фрагмент кода демонстрирует логику стратегии кэширования Cache-First .

Настоятельно рекомендуется использовать Workbox , чтобы избежать изобретения велосипеда. Например, вы можете зарегистрировать URL-адреса ресурсов с помощью одной строки кода регулярного выражения .

import {registerRoute} from 'workbox-routing';

registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);

Стратегии и варианты использования кэширования в сервис-воркерах

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

Дополнительные преимущества кэширования для сервисных работников

Помимо точного управления логикой кэширования, кэширование с помощью сервис-воркеров также обеспечивает:

• Больше памяти и места для хранения данных для вашего источника: браузер выделяет ресурсы HTTP-кэша для каждого источника отдельно. Другими словами, если у вас несколько поддоменов, все они используют один и тот же HTTP-кэш. Нет гарантии, что содержимое вашего источника/домена останется в HTTP-кэше надолго. Например, пользователь может очистить кэш вручную через настройки браузера или выполнить принудительную перезагрузку страницы. С кэшем Service Worker вероятность того, что кэшированное содержимое останется в кэше, значительно выше. Подробнее см. в разделе «Постоянное хранилище» .
• Более высокая гибкость при нестабильной сети или работе в автономном режиме: при использовании HTTP-кэша у вас есть только бинарный выбор: либо ресурс кэшируется, либо нет. При использовании кэширования с помощью сервис-воркеров вы можете гораздо проще сглаживать мелкие «сбои» (с помощью стратегии «stale-while-revalidate»), предлагать полностью автономный режим работы (с помощью стратегии «Cache only») или даже что-то среднее, например, настраиваемые пользовательские интерфейсы, в которых части страницы берутся из кэша сервис-воркеров, а некоторые исключаются (с помощью стратегии «Set catch handler»), где это необходимо.

HTTP-кэширование

При первой загрузке веб-страницы и связанных с ней ресурсов браузер сохраняет эти ресурсы в своем HTTP-кэше. HTTP-кэш обычно включается браузерами автоматически, если только он не был явно отключен конечным пользователем.

Использование HTTP-кэширования означает, что сервер сам определяет, когда и на какой срок следует кэшировать ресурс.

Управляйте истечением срока действия HTTP-кэша с помощью заголовков HTTP-ответа.

Когда сервер отвечает на запрос браузера о предоставлении ресурса, он использует заголовки HTTP-ответа, чтобы сообщить браузеру, как долго следует кэшировать этот ресурс. См. раздел «Заголовки ответа: настройка веб-сервера» , чтобы узнать больше.

Стратегии и примеры использования HTTP-кэширования

Кэширование HTTP намного проще, чем кэширование сервис-воркеров, поскольку оно работает только с логикой истечения срока действия ресурсов по времени (TTL). Подробнее о стратегиях кэширования HTTP см. в статьях «Какие значения заголовков ответа следует использовать?» и «Предотвращение ненужных сетевых запросов с помощью кэша HTTP (краткое изложение)» .

Разработка логики истечения срока действия кэша

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

Единая логика истечения срока действия для всех уровней кэширования.

Чтобы продемонстрировать преимущества и недостатки, мы рассмотрим 3 сценария: долгосрочный, среднесрочный и краткосрочный.

Сценарий: Долгосрочное кэширование (кэширование с последующим переключением на сеть)

• Если кэшированный ресурс действителен (<= 30 дней): сервис-воркер немедленно возвращает кэшированный ресурс, не обращаясь к сети.
• Когда срок действия кэшированного ресурса истекает (> 30 дней): сервис-воркер обращается к сети для получения ресурса. Браузер не хранит копию ресурса в своем HTTP-кэше, поэтому он обращается за ресурсом на сервер.

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

Сценарий: Среднесрочное кэширование (кэширование с сохранением данных при повторной проверке)

• Когда кэшированный ресурс действителен (<= 1 день): сервис-воркер немедленно возвращает кэшированный ресурс и обращается к сети для его получения. Браузер имеет копию ресурса в своем HTTP-кэше, поэтому он возвращает эту копию сервис-воркеру.
• Когда срок действия кэшированного ресурса истекает (> 1 дня): сервис-воркер немедленно возвращает кэшированный ресурс и обращается к сети для его получения. Браузер не хранит копию ресурса в своем HTTP-кэше, поэтому он обращается к серверу для его получения.

Минус: Для максимальной эффективности шага "повторной проверки" сервис-воркеру требуется дополнительная очистка кэша для переопределения HTTP-кэша.

Сценарий: Кратковременное кэширование (сеть переключается на кэширование)

• Когда кэшированный ресурс действителен (<= 10 мин): сервис-воркер обращается к сети для получения ресурса. Браузер хранит копию ресурса в своем HTTP-кэше, поэтому он возвращает ее сервис-воркеру, не обращаясь к серверу.
• Когда срок действия кэшированного ресурса истекает (> 10 минут): сервис-воркер немедленно возвращает кэшированный ресурс и обращается к сети для его получения. Браузер не хранит копию ресурса в своем HTTP-кэше, поэтому он обращается к серверу для его получения.

Минус: Аналогично сценарию среднесрочного кэширования, сервис-воркеру требуется дополнительная логика для обхода кэша, чтобы переопределить HTTP-кэш и получить актуальный ресурс с серверной стороны.

Работник сферы услуг во всех ситуациях

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

Различная логика истечения срока действия кэша на уровнях кэширования сервис-воркера и HTTP.

Чтобы продемонстрировать преимущества и недостатки, мы снова рассмотрим долгосрочный, среднесрочный и краткосрочный сценарии.

Сценарий: Долгосрочное кэширование (кэширование с последующим переключением на сеть)

• Если кэшированный ресурс действителен в кэше сервис-воркера (<= 90 дней): сервис-воркер немедленно возвращает кэшированный ресурс.
• Когда срок действия кэшированного ресурса в кэше сервис-воркера истекает (> 90 дней): сервис-воркер обращается к сети для получения ресурса. Браузер не имеет копии ресурса в своем HTTP-кэше, поэтому он обращается к серверу.

Плюсы и минусы:

• Плюсы: Пользователи получают мгновенный отклик, поскольку сервис-воркер немедленно возвращает кэшированные ресурсы.
• Плюсы: Сервис-воркер имеет более точный контроль над тем, когда использовать свой кэш и когда запрашивать новые версии ресурсов.
• Минус: Необходима четко определенная стратегия кэширования для сервис-воркеров.

Сценарий: Кэширование в середине срока действия (Stale-while-revalidate)

• Если кэшированный ресурс действителен в кэше сервис-воркера (<= 30 дней): сервис-воркер немедленно возвращает кэшированный ресурс.
• Когда срок действия кэшированного ресурса в кэше сервис-воркера истекает (> 30 дней): сервис-воркер обращается к сети за этим ресурсом. Браузер не имеет копии ресурса в своем HTTP-кэше, поэтому он обращается к серверу.

Плюсы и минусы:

• Плюсы: Пользователи получают мгновенный отклик, поскольку сервис-воркер немедленно возвращает кэшированные ресурсы.
• Плюсы: Сервис-воркер может гарантировать, что следующий запрос к заданному URL-адресу будет использовать актуальный ответ из сети благодаря повторной проверке, которая происходит «в фоновом режиме».
• Минус: Необходима четко определенная стратегия кэширования для сервис-воркеров.

Сценарий: Кратковременное кэширование (сеть переключается на кэширование)

• Когда кэшированный ресурс действителен в кэше сервис-воркера (<= 1 день): сервис-воркер обращается к сети за этим ресурсом. Браузер возвращает ресурс из HTTP-кэша, если он там есть. Если сеть недоступна, сервис-воркер возвращает ресурс из кэша сервис-воркера.
• Когда срок действия кэшированного ресурса в кэше сервис-воркера истекает (> 1 дня): сервис-воркер обращается к сети для получения ресурса. Браузер получает ресурсы по сети по мере истечения срока действия кэшированной версии в его HTTP-кэше.

Плюсы и минусы:

• Плюсы: При нестабильной или недоступной сети сервис-воркер немедленно возвращает кэшированные ресурсы.
• Минус: Сервис-воркеру требуется дополнительная очистка кэша для переопределения HTTP-кэша и выполнения запросов с приоритетом сети.

Заключение

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

• Логика кэширования в сервис-воркере не обязательно должна соответствовать логике истечения срока действия HTTP-кэша. По возможности используйте более длительный срок действия в сервис-воркере, чтобы предоставить ему больше контроля.
• Кэширование HTTP по-прежнему играет важную роль, но оно ненадежно, когда сеть нестабильна или недоступна.
• Пересмотрите свои стратегии кэширования для каждого ресурса, чтобы убедиться, что ваша стратегия кэширования в сервис-воркере действительно эффективна и не конфликтует с HTTP-кэшем.

Узнать больше

• надежность сети
• Предотвратите ненужные сетевые запросы с помощью HTTP-кэша.
• Кодовая инструкция по использованию HTTP-кэширования
• Оценка влияния работников сферы услуг на реальную производительность труда
• Управление кэшем против истечения срока действия
• Кэширование: проверка, очистка и отключение кэша.