Я добавил несколько workbox.routing.registerRoute
using staleWhileRevalidate
в свое приложение, и на данный момент оно прошло большинство тестов PWA. В настоящее время я вообще не использую предварительное кэширование. У меня вопрос, обязательно ли это? Что мне не хватает без предварительного кэширования? workbox.routing.registerRoute
уже кеширует все, что мне нужно. Спасибо!
Обязательно ли предварительное кэширование с помощью Workbox для PWA?
Ответы (1)
Нет ничего обязательного. :-)
Использование stale-while-revalidate для всех ваших ресурсов, а также для вашего HTML, безусловно, является законным подходом. Это означает, что вам не нужно делать ничего особенного, например, как часть процесса сборки, что может быть удобно в некоторых сценариях.
Всякий раз, когда вы используете стратегию, которая считывает из кеша, будь то предварительное кэширование или устаревание во время повторной проверки, будет какой-то шаг повторной проверки, чтобы гарантировать, что вы не будете бесконечно обслуживать устаревшие ответы.
Если вы используете предварительное кэширование в Workbox, эта повторная проверка эффективна, поскольку браузеру нужно сделать только один запрос для вашего сгенерированного файла service-worker.js
, и этот ответ служит источником достоверной информации о том, действительно ли что-то из предварительно кэшированного файла изменилось. Предполагая, что ваши предварительно кэшированные ресурсы не меняются это часто, большую часть времени ваш service-worker.js
будет идентичен последнему разу, когда он был получен, и больше не будет использоваться пропускная способность или циклы ЦП обновление.
Если вы используете кэширование во время выполнения с устаревшей политикой при повторной проверке для всего, то этот шаг «пока-повторная проверка» будет выполняться для каждого ответа. Вы получите "устаревший" ответ на страницу почти сразу, так что ваша общая производительность по-прежнему должна быть хорошей, но вы получаете дополнительные запросы, сделанные вашим работником службы "в фоновом режиме" для повторного получения каждого URL-адреса, и обновить кеш. В этом подходе используется увеличение пропускной способности и циклов ЦП.
Помимо использования дополнительных ресурсов, еще одна причина, по которой вы можете предпочесть предварительное кэширование устаревшему при повторной проверке, заключается в том, что вы можете заранее заполнить свой полный кеш, не дожидаясь первого обращения к ним. Если есть определенные ресурсы, которые используются только в части вашего веб-приложения, и вы хотите, чтобы эти ресурсы были кэшированы заранее, это будет сложнее сделать, если вы выполняете только кэширование во время выполнения.
И еще одно преимущество предварительного кэширования заключается в том, что он обновляет ваш кеш массово. Это помогает избежать сценариев, когда, например, один файл JavaScript был обновлен в силу запроса на предыдущей странице, но затем, когда вы переходите на следующую страницу, новый JavaScript несовместим с DOM, предоставленным устаревшим HTML. Предварительное кэширование всего снижает вероятность возникновения этих несоответствий в версиях. (Особенно, если вы не включаете skipWaiting
.)