Угловой сервисный работник и index.html кеширование

Question

Хотя есть похожие сообщения, я не могу найти четкий ответ , если index.html должен быть кэширован с использованием заголовка Cache-Control.

Исправьте меня, если я ошибаюсь, но правильнотеперь я возвращаю Cache-Control: no-store для index.html, чтобы избежать ошибок несоответствия хэша, которые вынуждают работника службы перейти в ухудшенный режим.

Я думаю, что если index.html с Cache-Control: max-age=3600 кэшируется на сервере CDN иприложение будет обновлено до истечения срока действия кэша, ngsw.json будет возвращать различные хэши файлов по сравнению с файлами сценариев, включенными в index.html, и произойдет что-то плохое. Правильно?

Также, чтобы прояснить ситуацию, я заметил, что некоторые люди добавляют index.html к ngsw-config.json, и это также не имеет смысла, потому что index.html загружается доработник службы.

Answer 1

Я думаю, что вам необходимо понять рабочий процесс приложения Angular и механизм кэширования времени выполнения Angular Service Worker. Поэтому я собираюсь написать о них здесь. Это поможет вам понять.

Angulars начинают работать со следующими шагами.

• Angular начинается с main.ts .
• Приложение Angular загружается, и в качестве аргумента передается app.module.ts .
• И компонент приложения Angular analysis, считывающий переданную настройку, и есть SELECTOR app-root .
• Теперь Angular позволяет обрабатывать app-root в index.html и знает правила для SELECTOR.
• SELECTOR должен вставлять компоненты приложения и иметь некоторый HTML-код - прикрепленный к нему шаблон - компонент html.

Angular ServiceWorker

Angular CLI также включен в корневой модуль приложения Angular Модуль Service Worker . CLI также добавил новый файл конфигурации под названием ngsw-config.json , который настраивает поведение во время выполнения Angular Service Worker , и сгенерированный файл имеет некоторые интеллектуальные значения по умолчанию. Здесь много чего происходит, поэтому давайте разберем его постепенно. Этот файл содержит поведение кэширования по умолчанию или Angular Service Worker , который предназначен для файлов статических активов приложения: index.html , CSS и Javascript bundles.

Angular Service Worker может кэшировать все виды содержимого в браузере Cache Storage. Это механизм кэширования ключей / значений на основе Javascript , который не связан со стандартным браузером Механизм кэширования-контроля , и оба механизма могут использоваться по отдельности.

Файлы в разделе приложения являются приложением: одна страница состоит из комбинации index.html плюс ее CSS и Js . Эти файлы необходимы для каждой отдельной страницы приложения, и не может быть загружен с отложенной загрузкой .

В случае этих файлов мы хотим кэшировать их как можно раньше и навсегда, и этоэто то, что делает конфигурация кэширования приложения . Файлы приложения будут предварительно загружены и установлены в фоновом режиме с помощью Service Worker , и именно это означает предварительная выборка режима установки. Сервисный работник не будет ждать, пока приложение запросит эти файлы, вместо этого он загрузит их заранее и кэширует их , чтобы он могподайте им в следующий раз, когда их попросят . Это хорошая стратегия для файлов, которые вместе составляют само приложение (пакеты index.html , CSS и Javascript ), потому что мы уже знаем, чтоони нам понадобятся постоянно.

---

index.html зависит от index.js , который зависит от chunk.js , которыйзависит от jquery.js. чанк загружается из браузера кеш .

Answer 2

Я не эксперт в этом, но я уверен, что следующие ссылки помогут вам с вашими сомнениями.

https://angular.io/guide/service-worker-getting-started#whats-being-cached

Что кешируется?

Обратите внимание, что все файлы, необходимые браузеру для визуализации этого приложения, кэшируются. Стандартная конфигурация ngsw-config.json настроена для кэширования определенных ресурсов, используемых CLI:

• index.html.

• favicon.ico.

• Создание артефактов (пакеты JS и CSS).

• Все, что находится под активами.

• Изображения и шрифты прямо под настроенным outputPath (по умолчанию ./dist//) или resourcesOutputPath. См. Ng build для получения дополнительной информации об этих параметрах.

А ссылка ниже содержит информацию о Работник службы и кэширование ресурсов приложения . из которых я хотел бы, чтобы вы прочитали о версиях приложений , проверках обновлений и целостности ресурса .

https://angular.io/guide/service-worker-devops#service-worker-and-caching-of-app-resources

Я также вставляю содержание этих трех разделов здесь, просто чтобы не делать этот ответ "ответом только по ссылке"

Версии приложения

В контексте работника службы Angular «версия» - это набор ресурсов, представляющих конкретную сборку приложения Angular. Каждый раз, когда развертывается новая сборка приложения, работник службы рассматривает эту сборку как новую версию приложения. Это верно, даже если обновляется только один файл. В любой момент времени работник сервиса может иметь несколько версий приложения в своем кэше, и он может обслуживать их одновременно. Для получения дополнительной информации см. Раздел «Вкладки приложения» ниже.

Чтобы сохранить целостность приложения, работник службы Angular группирует все файлы в одну версию. Файлы, сгруппированные в версию, обычно включают файлы HTML, JS и CSS. Группирование этих файлов имеет важное значение для целостности, поскольку файлы HTML, JS и CSS часто ссылаются друг на друга и зависят от конкретного содержимого. Например, файл index.html может содержать тег, ссылающийся на bundle.js, и он может пытаться вызвать функцию startApp () из этого скрипта. Каждый раз, когда обслуживается эта версия index.html, соответствующая bundle.js должна обслуживаться вместе с ней. Например, предположим, что функция startApp () переименована в runApp () в обоих файлах. В этом случае недопустимо использовать старый index.html, который вызывает startApp (), вместе с новым пакетом, который определяет runApp ().

Эта целостность файла особенно важна при отложенной загрузке модулей,Пакет JS может ссылаться на многие ленивые чанки, а имена ленивых чанков уникальны для конкретной сборки приложения. Если работающее приложение в версии X пытается загрузить отложенный фрагмент, но сервер уже обновился до версии X + 1, операция отложенной загрузки завершится неудачей.

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

С учетом поведения версий сервисного работника Angularсервер приложений может гарантировать, что приложение Angular всегда имеет согласованный набор файлов.

Проверка обновлений

Каждый раз, когда пользователь открывает или обновляет приложение, AngularСервисный работник проверяет наличие обновлений для приложения, просматривая обновления манифеста ngsw.json. Если обновление найдено, оно загружается и кэшируется автоматически и будет обслуживаться при следующей загрузке приложения.

Целостность ресурса

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

Для обеспечения целостности ресурса работник службы Angular проверяет хэши всех ресурсов, для которых у него есть хэш. Обычно для приложения, созданного с помощью Angular CLI, это все в каталоге dist, охватываемом конфигурацией src / ngsw-config.json пользователя.

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

Могут возникнуть несоответствия хеша длямножество причин:

• Кэширование слоев между исходным сервером и конечным пользователем может обслуживать устаревший контент.
• Неатомарное развертывание может привести к тому, что работник службы Angular увидит частично обновленный контент.
• Ошибки в процессе сборки могут привести к обновлению ресурсов без обновления ngsw.json. Также может произойти обратное, что приведет к обновлению ngsw.json без обновленных ресурсов.