Контекст: у меня есть производственное приложение (здесь, если хотите посмотреть), которое в настоящее время использует статическую ревизию ресурсов с использованием пакет gulp-rev-all, который похож на gulp-rev, за исключением того, что он также обрабатывает зависимости при генерации хэшей контента. Он создает новый набор файлов со статическими именами (например, goals.js становится goals.6a5aa614.js) и которые ссылаются друг на друга, используя эти статические имена. Затем я обслуживаю эти файлы с помощью Fastly CDN на производстве, поэтому мой сервер NodeJS не используется активно для статических ресурсов. Это отлично работает.

Сейчас я заставляю сайт работать офлайн с сервис-воркерами. Поскольку в прошлом году я проделал большую работу над логикой синхронизации, динамическую часть сайта было довольно легко переделать. Но я немного не понимаю, что делать со своими статическими активами.

Я подумал, что буду использовать рабочую панель, и, похоже, это работает нормально. Но workbox precache использует запросы для очистки кеша, а не для изменения имен файлов, и кажется глупым делать и то, и другое. Но если я перестану использовать версионные имена, как мне перебрать кеш в браузерах, которые не поддерживают сервис-воркер?

(У меня есть еще один связанный с этим вопрос: имеет ли смысл продолжать использовать Fastly, учитывая, что ответы Fastly будут непрозрачны для SW и, следовательно, не обязательно хороший вариант для предварительного кэширования? Хотя без Fastly приложение стало бы намного медленнее для тех, кто не использует сервис-воркеров, что звучит противоположно подходу PWA. Стоит ли мне добавить кеш nginx или что-то в этом роде? (Я плохо понимаю, что это такое, но я слышал об этом несколько раз))

Мне кажется, что для этого должно быть элегантное решение, но мое понимание gulp достаточно ограничено, и мне трудно понять, что возможно, а мое понимание ServiceWorkers и кеширования достаточно ограничено, чтобы мне трудно точно знать, чего я хочу.

Поэтому у меня проблемы с ответом на этот вопрос:

Как настроить ревизию статических ресурсов gulp для работы с ServiceWorkers?

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

4
MalcolmOcean 31 Дек 2018 в 04:38

2 ответа

Лучший ответ

Service worker лучше всего работает на основе хорошей стратегии регулярного кэширования. Вы должны продолжать редактировать свои статические имена файлов, а затем кэшировать их в сервис-воркере. Избегайте библиотек, которые изменяют URL-адрес с помощью строки запроса, вам не нужна эта функция, поскольку вы уже редактируете URL-адрес.

Если ваши ресурсы обслуживаются из другого источника (я думаю, это то, что вы имеете в виду, когда говорите о Fastly), тогда разрешите их запрашивать через CORS (через Access-Control-Allow-Origin: *), это означает, что они не будут непрозрачными. ,

4
JaffaTheCake 7 Янв 2019 в 07:42

Вы должны сохранить активы с исправленными файлами. Полный пример использования gulp и предварительного кэширования см. здесь.

В основном вы хотите использовать сначала кэш, а затем сетевой шаблон. Вы можете сопоставить запросы с /goals.*.js/ =>, а затем, в зависимости от вашего приложения, вы можете решить использовать кешированный goal.js, даже если [хэш] не совпадает, а затем загрузить новые цели . [hash] .js в фоновом режиме.

Или, если хэш не совпадает, вы можете сначала обратиться к сети, а затем вернуться к нечеткому кешу соответствия goal.js.

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

CDN => <= Nginx => Node.js Origin.

Если вы используете AWS. Тогда типичная установка с Cloudfront CDN будет включать установку вашего обратного прокси-сервера Nginx node.js EC2 в качестве источника. Затем вы должны настроить поведение для маршрута «/» и маршрута «/ assets».

Поведение «/», скорее всего, будет иметь короткий TTL, тогда как поведение «/ assets /» (маршрут в Cloudfront) будет иметь вашу долгосрочную (max-age = 3153600) стратегию кэширования.

В этом сценарии почти все статические ресурсы будут обслуживаться из CDN (Cloudfront). Ему нужно будет только вернуться к своему источнику, когда вы развернете новый код с новым набором ресурсов с исправленными файлами.

Затем вы используете сервис-воркер, чтобы сделать все повторные посещения чрезвычайно быстрыми, потенциально даже используя устаревший актив (соответствующее имя, другой хеш) при первом повторном посещении, сначала перейдя в кеш, а затем в сеть. Таким образом, у всех повторных пользователей с сервис-воркером будет максимально быстрая начальная загрузка страницы.

Те, у кого нет этого, по-прежнему получат все преимущества отредактированных файлов, долгосрочных кэшированных в браузере ресурсов с обслуживанием на границе CDN.

2
adamrights 11 Янв 2019 в 05:23