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

Как только интерфейсные ресурсы войдут в высокочастотный ритм выпуска, проблемы с производительностью вскоре перестанут быть такими простыми, как «включение Бротли». Первый экран замедляется, обратный трафик увеличивается, а ЦП граничного узла дрожит. На первый взгляд кажется, что сжатие недостаточно агрессивное. Если посмотреть глубже, то зачастую кэширование и сжатие оптимизируются отдельно и в конечном итоге подрывают друг друга в ссылке публикации.

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

Пока хеш ресурса не станет стабильным, преимущества сжатия просто несостоятельны.

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

В настоящее время, какой бы высокой ни была степень сжатия, она не может спасти частоту попаданий от коллапса. Старые файлы все еще лежат на пограничных узлах, а ключи новых файлов изменены; локальный кеш браузера полностью недействителен, и CDN приходится повторно извлекать исходный код, повторно сжимать и повторно распространять. Небольшие изменения в бизнесе превращаются в повторяющуюся работу для всей линии передачи.

Действительно полезным действием обычно является не продолжение настройки уровня сжатия, а сначала контроль стабильности выпущенного продукта:

— Публичные зависимости разделены на отдельные слои, чтобы уменьшить бизнес-изменения и объединить базовые пакеты для изменения хеша.

• Избегайте смешивания часто встречающихся изменений, таких как временные метки и номера сборок, непосредственно с содержанием продукта. — Пусть код рядом с одним и тем же маршрутом разбивается на стабильные фрагменты, а не перетасовывается каждый раз при компиляции.

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

Высокочастотная пресс-конференция переписывает проблему сжатия в проблему словарной версии

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

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

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

Иерархический подход, подобный следующему, обычно более стабилен, чем «единое сильное сжатие для всего сайта»:

const policy = {
  immutableAssets: 'public, max-age=31536000, immutable',
  releaseManifest: 'public, max-age=60, stale-while-revalidate=30',
  sharedDictionary: 'versioned-by-release-train'
}

Ключом является не сама конфигурация этих трех строк, а ограничения, которые она выражает: ресурсы с длинным жизненным циклом, список с коротким жизненным циклом и сжатая версия словаря должны развиваться вместе в соответствии с одним и тем же ритмом выпуска.

Часто необходимость возврата к исходному коду связана не с тем, что файл слишком велик, а с тем, что метод отказа слишком груб.

Еще одно очень распространенное заблуждение — связывать увеличение пропускной способности непосредственно с весом страницы. Страницы, конечно, становятся тяжелее, но обычно лучше использовать более опасные усилители в Интернете.

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

В этом типе сценария самое ценное — это контролируемый радиус отказа:

• Делать недействительными только манифест, HTML и изменяемые ресурсы, которые действительно изменились. — Старайтесь не очищать статические файлы хешем, а передавать их новым ссылкам для естественного переключения.
• Разделите выпуск на порядок: «сначала загрузите новые ресурсы, затем удалите ссылки, затем утилизируйте старые ресурсы» вместо очистки их всех сразу.

Что действительно важно для стоимости передачи, так это не только размер файла, но и то, как система решает, какой контент необходимо загрузить повторно.

Применимые границы определяются вместе с масштабом ресурсов и частотой выпуска.

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

Кэширование и сжатие вместе быстро становятся инфраструктурой доставки, как только будут реализованы следующие характеристики:

• Выпускается несколько раз в день с оттенками серого, откатом или региональными запусками.
• Интерфейсный продукт имеет большой размер, имеет множество общедоступных зависимостей и сложные взаимоотношения между частями.
• В канале передачи одновременно участвуют CDN, объектное хранилище, сжатие краев и кэширование браузера.
• Трафик настолько высок, что частота попаданий в кэш и пиковое значение возврата к источнику будут напрямую отражать стоимость и стабильность.

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