Обязательно ли предварительное кэширование с помощью Workbox для PWA?

Я добавил несколько workbox.routing.registerRoute using staleWhileRevalidate в свое приложение, и на данный момент оно прошло большинство тестов PWA. В настоящее время я вообще не использую предварительное кэширование. У меня вопрос, обязательно ли это? Что мне не хватает без предварительного кэширования? workbox.routing.registerRoute уже кеширует все, что мне нужно. Спасибо!


person Henry    schedule 06.03.2018    source источник


Ответы (1)


Нет ничего обязательного. :-)

Использование stale-while-revalidate для всех ваших ресурсов, а также для вашего HTML, безусловно, является законным подходом. Это означает, что вам не нужно делать ничего особенного, например, как часть процесса сборки, что может быть удобно в некоторых сценариях.

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

Если вы используете предварительное кэширование в Workbox, эта повторная проверка эффективна, поскольку браузеру нужно сделать только один запрос для вашего сгенерированного файла service-worker.js, и этот ответ служит источником достоверной информации о том, действительно ли что-то из предварительно кэшированного файла изменилось. Предполагая, что ваши предварительно кэшированные ресурсы не меняются это часто, большую часть времени ваш service-worker.js будет идентичен последнему разу, когда он был получен, и больше не будет использоваться пропускная способность или циклы ЦП обновление.

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

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

И еще одно преимущество предварительного кэширования заключается в том, что он обновляет ваш кеш массово. Это помогает избежать сценариев, когда, например, один файл JavaScript был обновлен в силу запроса на предыдущей странице, но затем, когда вы переходите на следующую страницу, новый JavaScript несовместим с DOM, предоставленным устаревшим HTML. Предварительное кэширование всего снижает вероятность возникновения этих несоответствий в версиях. (Особенно, если вы не включаете skipWaiting .)

person Jeff Posnick    schedule 08.03.2018
comment
еще одна причина, по которой вы можете предпочесть предварительное кэширование устаревшему при повторной проверке, заключается в том, что вы можете заполнить свой полный кеш заранее, не дожидаясь первого обращения к ним. Это потребует загрузки данных X, поэтому я предполагаю, что предварительное кэширование всего не рекомендуется, если вы хотите минимизировать объем данных, загружаемых при первом посещении? - person riper; 26.03.2019
comment
Ага. Это компромисс. - person Jeff Posnick; 26.03.2019