Плюсы и минусы использования согласованной или различной логики срока действия на уровнях кэша сервисного работника и кэша HTTP.
В то время как сервис-воркеры и PWA становятся стандартами современных веб-приложений, кэширование ресурсов стало более сложным, чем когда-либо. В этой статье рассматривается общая картина кэширования браузера, в том числе:
- Варианты использования и различия между кэшированием Service Worker и HTTP-кешированием.
- Плюсы и минусы различных стратегий истечения срока действия кэша Service Worker по сравнению с обычными стратегиями кэширования HTTP.
Обзор процесса кэширования
На высоком уровне браузер следует приведенному ниже порядку кэширования, когда запрашивает ресурс:
- Кэш сервисного работника . Сервисный работник проверяет, находится ли ресурс в его кеше, и решает, возвращать ли сам ресурс, на основе запрограммированных стратегий кэширования. Обратите внимание, что это не происходит автоматически. Вам необходимо создать обработчик событий выборки в своем сервис-воркере и перехватывать сетевые запросы, чтобы запросы обслуживались из кэша сервис-воркера, а не из сети.
- HTTP-кэш (также известный как кеш браузера) : если ресурс найден в HTTP-кеше и срок его действия еще не истек, браузер автоматически использует ресурс из HTTP-кэша.
- На стороне сервера: если в кеше сервисного работника или кеше 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
Помимо детального управления логикой кэширования, кэширование 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-кэширование работают в различных сценариях:
Согласованная логика истечения срока действия для всех слоев кэша
Чтобы продемонстрировать плюсы и минусы, мы рассмотрим три сценария: долгосрочный, среднесрочный и краткосрочный.
| Сценарии | Долгосрочное кэширование | Среднесрочное кэширование | Кратковременное кэширование |
|---|---|---|---|
| Стратегия кэширования сервисных работников | Кэш, возврат к сети | Устаревшие при повторной проверке | Сеть возвращается в кеш |
| TTL кэша сервисного работника | 30 дней | 1 день | 10 минут |
| Максимальный срок HTTP-кэша | 30 дней | 1 день | 10 минут |
Сценарий: долгосрочное кэширование (кэш, возврат к сети)
- Когда кэшированный ресурс действителен (<= 30 дней): сервисный работник немедленно возвращает кэшированный ресурс, не обращаясь к сети.
- Когда срок действия кэшированного ресурса истек (> 30 дней): сервисный работник обращается к сети, чтобы получить ресурс. Браузер не имеет копии ресурса в своем HTTP-кэше, поэтому ресурс передается на серверную сторону.
Против: в этом сценарии HTTP-кэширование дает меньшую ценность, поскольку браузер всегда будет передавать запрос на серверную сторону, когда срок действия кэша в сервис-воркере истечет.
Сценарий: среднесрочное кэширование (устарело при повторной проверке)
- Когда кэшированный ресурс действителен (<= 1 день): сервисный работник немедленно возвращает кэшированный ресурс и обращается к сети, чтобы получить его. Браузер имеет копию ресурса в своем HTTP-кэше, поэтому он возвращает эту копию сервис-воркеру.
- Когда срок действия кэшированного ресурса истек (> 1 дня): сервисный работник немедленно возвращает кэшированный ресурс и обращается к сети, чтобы получить его. Браузер не имеет копии ресурса в своем HTTP-кэше, поэтому для получения ресурса он обращается к серверу.
Против: сервисному работнику требуется дополнительная очистка кеша для переопределения кеша HTTP, чтобы максимально эффективно использовать шаг «повторной проверки».
Сценарий: кратковременное кэширование (сеть возвращается к кэшу).
- Когда кэшированный ресурс действителен (<= 10 минут): сервисный работник обращается к сети, чтобы получить ресурс. Браузер хранит копию ресурса в своем HTTP-кэше, поэтому он возвращает ее сервис-воркеру, не переходя на сторону сервера.
- Когда срок действия кэшированного ресурса истек (> 10 минут): сервисный работник немедленно возвращает кэшированный ресурс и обращается к сети, чтобы получить его. Браузер не имеет копии ресурса в своем HTTP-кэше, поэтому для получения ресурса он обращается к серверу.
Против: Подобно сценарию среднесрочного кэширования, сервисному работнику требуется дополнительная логика очистки кеша, чтобы переопределить кеш HTTP и получить последний ресурс со стороны сервера.
Сервисный работник во всех сценариях
Во всех сценариях кэш сервисного работника все равно может возвращать кэшированные ресурсы, когда сеть нестабильна. С другой стороны, HTTP-кеш ненадежен, когда сеть нестабильна или не работает.
Различная логика истечения срока действия кэша на уровне кэша сервисного работника и HTTP.
Чтобы продемонстрировать плюсы и минусы, мы снова рассмотрим долгосрочные, среднесрочные и краткосрочные сценарии.
| Сценарии | Долгосрочное кэширование | Среднесрочное кэширование | Кратковременное кэширование |
|---|---|---|---|
| Стратегия кэширования Service Worker | Кэш, возврат в сеть | Устаревшие при повторной проверке | Сеть возвращается к кешу |
| TTL кэша сервисного работника | 90 дней | 30 дней | 1 день |
| Максимальный срок HTTP-кэша | 30 дней | 1 день | 10 минут |
Сценарий: долгосрочное кэширование (кэш, возврат к сети)
- Если кэшированный ресурс действителен в кэше сервисного работника (<= 90 дней): Сервисный работник немедленно возвращает кэшированный ресурс.
- Когда срок действия кэшированного ресурса в кэше сервисного работника истекает (> 90 дней): Сервисный работник обращается к сети, чтобы получить ресурс. Браузер не имеет копии ресурса в своем HTTP-кэше, поэтому он передается на серверную сторону.
За и против:
- Плюсы: пользователи получают мгновенный ответ, поскольку сервис-воркер немедленно возвращает кэшированные ресурсы.
- Плюсы: Service Worker имеет более детальный контроль над тем, когда использовать свой кэш, а когда запрашивать новые версии ресурсов.
- Против: Требуется четко определенная стратегия кэширования сервис-воркеров.
Сценарий: среднесрочное кэширование (устарело при повторной проверке)
- Если кэшированный ресурс действителен в кэше сервисного работника (<= 30 дней): Сервисный работник немедленно возвращает кэшированный ресурс.
- Когда срок действия кэшированного ресурса в кэше сервисного работника истекает (> 30 дней): Сервисный работник обращается к сети за ресурсом. Браузер не имеет копии ресурса в своем HTTP-кэше, поэтому он передается на серверную сторону.
За и против:
- Плюсы: пользователи получают мгновенный ответ, поскольку сервис-воркер немедленно возвращает кэшированные ресурсы.
- Плюсы: сервис-воркер может гарантировать, что следующий запрос для данного URL-адреса будет использовать свежий ответ из сети благодаря повторной проверке, которая происходит «в фоновом режиме».
- Против: Требуется четко определенная стратегия кэширования сервис-воркеров.
Сценарий: кратковременное кэширование (сеть возвращается к кэшу).
- Когда кэшированный ресурс действителен в кеше сервисного работника (<= 1 день): Сервисный работник обращается к сети за ресурсом. Браузер возвращает ресурс из HTTP-кеша, если он там есть. Если сеть не работает, сервис-воркер возвращает ресурс из кэша сервис-воркера.
- Когда срок действия кэшированного ресурса в кэше сервисного работника истекает (> 1 дня): Сервисный работник обращается к сети, чтобы получить ресурс. Браузер извлекает ресурсы по сети, поскольку срок действия кэшированной версии в его HTTP-кеше истек.
За и против:
- Плюсы: если сеть нестабильна или не работает, сервис-воркер немедленно возвращает кэшированные ресурсы.
- Против: сервисному работнику требуется дополнительная очистка кеша, чтобы переопределить HTTP-кэш и выполнить запросы «Сеть прежде всего».
Заключение
Учитывая сложность комбинации сценариев кэширования, невозможно разработать одно правило, охватывающее все случаи. Однако, основываясь на результатах предыдущих разделов, есть несколько советов, на которые следует обратить внимание при разработке стратегий кэширования:
- Логика кэширования Service Worker не обязательно должна быть согласована с логикой истечения срока действия кэширования HTTP. Если возможно, используйте логику более длительного срока действия в сервисном работнике, чтобы предоставить сервисному работнику больше контроля.
- HTTP-кэширование по-прежнему играет важную роль, но оно ненадежно, когда сеть нестабильна или не работает.
- Пересмотрите свои стратегии кэширования для каждого ресурса, чтобы убедиться, что ваша стратегия кэширования Service Worker обеспечивает свою ценность и не конфликтует с кэшем HTTP.