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

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

Jonathan Chen

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

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

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

На высоком уровне браузер следует приведенному ниже порядку кэширования, когда запрашивает ресурс:

1. Кэш сервисного работника . Сервисный работник проверяет, находится ли ресурс в его кеше, и решает, возвращать ли сам ресурс, на основе запрограммированных стратегий кэширования. Обратите внимание, что это не происходит автоматически. Вам необходимо создать обработчик событий выборки в своем сервис-воркере и перехватывать сетевые запросы, чтобы запросы обслуживались из кэша сервис-воркера, а не из сети.
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);

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

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

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

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

• Больше памяти и места для хранения вашего источника: браузер распределяет ресурсы HTTP-кэша для каждого источника . Другими словами, если у вас несколько субдоменов, все они используют один и тот же HTTP-кеш. Нет никакой гарантии, что содержимое вашего источника/домена останется в HTTP-кеше в течение длительного времени. Например, пользователь может очистить кеш, очистив его вручную в пользовательском интерфейсе настроек браузера или выполнив жесткую перезагрузку страницы. При использовании кеша сервисного работника вероятность того, что ваш кешированный контент останется в кеше, гораздо выше. Дополнительную информацию см. в разделе Постоянное хранилище .
• Более высокая гибкость при нестабильных сетях или автономном режиме: с помощью HTTP-кэша у вас есть только двоичный выбор: либо ресурс кэшируется, либо нет. С помощью кэширования сервис-воркеров вы можете гораздо проще устранить небольшие «сбои» (с помощью стратегии «устаревшие при повторной проверке»), предложить полную работу в автономном режиме (с помощью стратегии «Только кэширование») или даже что-то среднее, например, настраиваемые пользовательские интерфейсы с части страницы берутся из кэша сервисного работника, а некоторые части исключаются (с помощью стратегии «Установить обработчик перехвата»), где это необходимо.

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

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

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

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

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

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

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

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

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

Приведенный ниже сбой демонстрирует, как кэширование Service Worker и HTTP-кэширование работают в различных сценариях:

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

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

Сценарий: долгосрочное кэширование (кэш, возврат к сети)

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

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

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

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

Против: сервисному работнику требуется дополнительная очистка кеша для переопределения кеша HTTP, чтобы максимально эффективно использовать шаг «повторной проверки».

Сценарий: кратковременное кэширование (сеть возвращается к кэшу)

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

Против: Как и в случае со среднесрочным кэшированием, сервисному работнику требуется дополнительная логика очистки кеша, чтобы переопределить кеш HTTP и получить последний ресурс со стороны сервера.

Сервисный работник во всех сценариях

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

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

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

Сценарий: долгосрочное кэширование (кэш, возврат к сети)

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

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

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

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

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

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

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

Сценарий: кратковременное кэширование (сеть возвращается к кэшу)

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

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

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

Заключение

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

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

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

• Надежность сети
• Предотвратите ненужные сетевые запросы с помощью HTTP-кеша
• Лаборатория кода HTTP-кэша
• Измерение реального влияния на производительность сервисных работников
• Cache-Control против Expires
• Раскрытие тайны кэширования: проверка, очистка и отключение кэшей