Должен ли я кэшировать файл ServiceWorker в PWA?
Я все еще пытаюсь избежать проблем с кэшированием в прогрессивных веб-приложениях. Решающим для любого кэширования PWA является возможность обновлять файл ServiceWorker (назовем его sw.js). Но подробности меня немного смущают:
Можно выполнять
navigator.serviceWorker.register('sw.js')при каждой загрузке страницы, потому чтоregister()обновляет кеш приложения или ничего не делает, если все обновлено — верно?Имеет ли смысл делать что-то вроде
navigator.serviceWorker.register('sw.js?' + Date.now()), чтобы избежать кэширования HTTP? Или я в безопасности, если сервер использует ETags?Проверяет ли браузер наличие в сети обновленного файла sw.js при каждой загрузке страницы? Иногда я не вижу его на вкладке сетевого инспектора.
Если sw.js находится в кеше приложения, извлекает ли браузер его оттуда, не проверяя сервер на наличие обновлений?
Иногда я вижу демонстрационные скрипты ServiceWorker, которые кэшируют себя так:
self.addEventListener('install', ev => { const myCaches = { app: {...}, sw: { files: [ '/sw.js' ], version: '1' } } for (let name in myCaches) { const cacheName = name + '-' + myCaches[name].version ev.waitUntil( caches.has(cacheName).then(uptodate => { if (uptodate) return true caches .open(cacheName) .then(cache => { cache.addAll(myCaches[name].files) }) }) ) // clear old caches } })
Имеет ли это смысл, это хорошая практика? Делает ли это обновление кеша более надежным?
Это интересно и кажется очень хорошей идеей. Я бы не стал на это полагаться, потому что это довольно новая функция, и я не смог найти ничего подобного ни в спецификации, ни в документации других браузеров.
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 2
Большинство примеров кода, которые я видел, не добавляют файл сервис-воркера в кеш. По моему опыту и моему пониманию, для работы автономного режима не обязательно.
Браузер установит сервис-воркер для вашего PWA, когда вы его зарегистрируете. Браузер использует отдельное средство для кэширования и управления сервисными работниками. Кэширование не входит в ваши обязанности.
Добавление временной метки к имени файла вашего сервис-воркера является антишаблоном. Согласно статье о жизненном цикле Service Worker, вы должны использовать избегайте изменения URL-адреса вашего скрипта сервисного работника.
Что вызывает большую озабоченность, так это то, что вы подняли вопрос об обновлении работника службы, как браузер узнает, когда это делать?
Ну, согласно разделу Обновление сервис-воркера из статьи Service Worker Lifecycle:
Most browsers, including Chrome 68 and later, default to ignoring caching headers when checking for updates of the registered service worker script. They still respect caching headers when fetching resources loaded inside a service worker via
importScripts(). You can override this default behavior by setting theupdateViaCacheoption when registering your service worker.Your service worker is considered updated if it's byte-different to the one the browser already has. (We're extending this to include imported scripts/modules too.) The updated service worker is launched alongside the existing one, and gets its own
installevent.If your new worker has a non-ok status code (for example, 404), fails to parse, throws an error during execution, or rejects during install, the new worker is thrown away, but the current one remains active.
Если вы тестировали PWA в автономном режиме, вы заметите, что браузер выдает ошибку в консоли, когда пытается получить ваш файл sw.js. Это не о чем беспокоиться. Как сказано в последнем пункте выше, «текущий остается активным».
Интересно, зациклены ли люди на этой записи 404 в консоли для JavaScript сервис-воркера, когда они тестируют в автономном режиме и добавляют файл сервис-воркера в кеш в приступе бритья яка? Вероятно, это оказывает медвежью услугу вашему сайту и его пользователям, тратя время и диск на кеширование ненужного файла в браузере.
Избегание 404 действительно может быть единственной (неубедительной) причиной для кэширования приложения sw.js. Не уверен насчет кэширования HTTP, поскольку не нашел документации о поведении других браузеров. Динамическое добавление параметра HTTP не должно вызывать тех же проблем, что и изменение имени файла.
Да, правила кэширования для сервис-воркера нечетко определены. На самом деле они постоянно меняются, и неудивительно, что они различаются в разных браузерах. Это новая технология, поэтому она все еще дорабатывается.
Я полагаю, что эти вещи развиваются со временем.
Я только что проверил свое экспериментальное приложение. Независимо от того, включаю ли я сервис-воркер в URL-адреса для кэширования, pwa всегда извлекает сервис-воркера всякий раз, когда он обновляется.
Фактически это механизм, используемый разработчиком для обновления приложения. Когда должно быть выполнено обновление, версия сервис-воркера на сервере может быть обновлена, а затем, когда приложение обнаруживает новую версию s-w, оно также повторно извлекает все кешированные URL-адреса. В зависимости от реализации повторная выборка может зависеть от измененной контрольной суммы или отпечатка каждого файла по сравнению с теми, которые он кэшировал.
Ваш ответ может быть улучшен с помощью дополнительной вспомогательной информации. Пожалуйста, редактировать добавьте дополнительную информацию, например цитаты или документацию, чтобы другие могли подтвердить правильность вашего ответа. Дополнительную информацию о том, как писать хорошие ответы, можно найти в справочном центре.
Я не уверен насчет ETag, но похоже, что браузеры будут двигаться в направлении игнорирования кэширования HTTP для сервис-воркеров Developers.google.com/web/updates/2018/06/fresher-sw