Общие словари: ускорение загрузки сайтов для новой эпохи веба

За последнее десятилетие вес веб-страниц ежегодно увеличивался на 6-9%, чему способствовало развитие веба в сторону большей зависимости от фреймворков, интерактивности и медиаконтента. Эта тенденция никуда не исчезает. Меняется то, как часто эти страницы пересобираются и сколько клиентов их запрашивает. Оба показателя стремительно растут из-за агентов.

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

Сегодня мы рады дать вам предварительный взгляд на нашу поддержку общих словарей сжатия, показать результаты раннего тестирования и объявить, когда вы сами сможете попробовать бета-версию (подсказка: 30 апреля 2026!).

Агентные краулеры, браузеры и другие инструменты постоянно обращаются к конечным точкам, загружая полные страницы, часто чтобы извлечь лишь фрагмент информации. В марте 2026 года на долю агентных акторов пришлось чуть менее 10% от общего числа запросов в сети Cloudflare, что примерно на 60% больше, чем годом ранее.

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

Когда агенты вносят исправление в одну строку, сборщик перепаковывает код, имена файлов меняются, и каждый пользователь в мире может перезагрузить всё приложение целиком. Не потому что код существенно изменился, а потому что браузер/клиент не может понять, что именно поменялось. Он видит новый URL и начинает с нуля. Традиционное сжатие помогает уменьшить размер каждой загрузки, но не может справиться с избыточностью. Оно не знает, что у клиента уже закешировано 95% файла. Поэтому каждый деплой, для каждого пользователя, для каждого бота снова и снова отправляет избыточные байты. Десять небольших изменений в день — и вы фактически отказались от кеширования. Это растрачивает пропускную способность и ресурсы ЦПУ в условиях, когда аппаратное обеспечение быстро становится узким местом.

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

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

Этот принцип сжатия на основе уже известных данных — залог превосходства современных алгоритмов сжатия над предшественниками. Brotli поставляется со встроенным словарём общих веб-паттернов, таких как HTML-атрибуты и распространённые фразы; Zstandard создан специально для пользовательских словарей: вы можете предоставить ему репрезентативные образцы контента, и он сгенерирует оптимизированный словарь для вашего типа контента. У Gzip нет ни того, ни другого; он должен строить словари, находя паттерны в реальном времени во время сжатия. Эти «традиционные алгоритмы сжатия» уже доступны в Cloudflare.

Общие словари делают этот принцип ещё эффективнее: ранее закешированная версия ресурса становится словарём. Помните проблему с деплоем, когда команда выпускает исправление в одну строку, и каждый пользователь перезагружает весь бандл? С общими словарями у браузера уже есть старая версия в кеше. Сервер сжимает новую версию относительно неё, отправляя только разницу. Этот бандл на 500 КБ с изменением в одну строку превращается в несколько килобайт передаваемых данных. При 100 тыс. ежедневных пользователей и 10 деплоях в день это разница между 500 ГБ передачи данных и несколькими сотнями мегабайт.

Дельта-сжатие — это то, что превращает версию, уже имеющуюся у браузера, в словарь. Протокол работает так: когда сервер впервые отдаёт ресурс, он добавляет заголовок ответа Use-As-Dictionary, указывая браузеру, по сути, сохранить файл, потому что он пригодится позже. При следующем запросе этого ресурса браузер отправляет обратно заголовок Available-Dictionary, сообщая серверу: «Вот что у меня есть». Затем сервер сжимает новую версию относительно старой и отправляет только разницу. Отдельный файл словаря не требуется.

Именно здесь проявляется реальная польза для приложений. Версионированные JS-бандлы, CSS-файлы, обновления фреймворков и всё, что изменяется инкрементально между релизами. Браузер уже закешировал app.bundle.v1.js, разработчик вносит обновление и деплоит app.bundle.v2.js. Дельта-сжатие отправляет только разницу между этими версиями. Каждая последующая версия также представляет собой лишь разницу. Версия три сжимается относительно версии два. Версия 47 сжимается относительно версии 46. Экономия не сбрасывается, она сохраняется на протяжении всей истории релизов.

В сообществе также активно ведутся дискуссии о пользовательских и динамических словарях для нестатического контента. Это задача на будущее, но её последствия значительны. Мы оставим это для другой статьи.

Если общие словари настолько мощные, почему их ещё не используют все?

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

Google внедрил Shared Dictionary Compression for HTTP (SDCH) в Chrome в 2008 году. Он хорошо работал, и некоторые ранние пользователи сообщали о двузначном улучшении времени загрузки страниц. Но у SDCH проблемы накапливались быстрее, чем кто-либо успевал их исправить.

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

Но безопасность была не единственной проблемой и даже не главной причиной, по которой технология не прижилась. SDCH выявила несколько архитектурных проблем, таких как нарушение Политики единого происхождения (что, по иронии, частично объясняет её высокую производительность). Её модель кросс-доменных словарей не могла быть согласована с CORS, и в ней не хватало спецификаций для взаимодействия с такими вещами, как Cache API. Со временем стало ясно, что время для внедрения ещё не пришло, поэтому в 2017 году Chrome (единственный браузер с поддержкой на тот момент) отказался от неё.

Потребовалось десятилетие, чтобы веб-сообщество снова подхватило эстафету, но оно того стоило.

Современный стандарт, RFC 9842: Transport for Compression Dictionaries, закрывает ключевые пробелы в проектировании, которые делали SDCH нежизнеспособной. Например, он предписывает, что объявленный словарь можно использовать только для ответов с того же источника, предотвращая многие условия, которые делали возможными атаки через побочные каналы сжатия.

Chrome и Edge уже внедрили поддержку, а Firefox работает над этим. Стандарт движется к широкому внедрению, но полная кроссплатформенная поддержка пока догоняет.

RFC смягчает проблемы безопасности, но реализация транспорта словарей всегда была сложной. Источнику, возможно, придётся генерировать словари, отдавать их с правильными заголовками, проверять каждый запрос на соответствие Available-Dictionary, выполнять дельта-сжатие ответа на лету и корректно отступать, когда у клиента нет словаря. Кеширование также усложняется. Ответы варьируются в зависимости от кодировки и хеша словаря, поэтому каждая версия словаря создаёт отдельный вариант кеша. В середине деплоя у вас есть клиенты со старым словарём, клиенты с новым и клиенты без словаря. Ваш кеш хранит отдельные копии для каждого из них. Эффективность кеша падает, объём хранения растёт, а сами словари должны оставаться актуальными в соответствии с обычными правилами HTTP-кеширования.

Эта сложность — проблема координации. И именно то, что должно обрабатываться на границе сети. CDN уже находится перед каждым запросом, уже управляет сжатием и уже обрабатывает варианты кэширования (следите за новостями — скоро будет анонс в блоге).

Сжатие с использованием общих словарей затрагивает каждый уровень стека между браузером и исходным сервером. Мы видим большой интерес со стороны клиентов: некоторые уже создали собственные реализации, например, Патрик Минан, автор RFC, со своим проектом dictionary-worker, который реализует полный жизненный цикл словаря внутри Cloudflare Worker с использованием WASM-скомпилированного Zstandard (в качестве примера). Мы хотим сделать эту технологию доступной для всех и максимально простой для внедрения. Поэтому мы развертываем её на всей платформе в три этапа, начиная с базовой инфраструктуры.

Этап 1: Поддержка транзитной передачи (passthrough) в настоящее время находится в активной разработке. Cloudflare передает заголовки и кодировки, необходимые для общих словарей, такие как Use-As-Dictionary, Available-Dictionary, а также кодировки содержимого dcb и dcz, без их удаления, изменения или повторного сжатия. Ключи кэша расширены, чтобы учитывать вариации по Available-Dictionary и Accept-Encoding, чтобы ответы, сжатые с помощью словаря, кэшировались правильно. Этот этап предназначен для клиентов, которые управляют своими собственными словарями на исходном сервере.

Мы планируем запустить открытую бета-версию Этапа 1 к 30 апреля 2026 года. Чтобы использовать её, вам потребуется находиться в зоне Cloudflare с включенной функцией, иметь исходный сервер, который отдает ответы, сжатые с помощью словаря, с правильными заголовками (Use-As-Dictionary, Content-Encoding: dcb или dcz), а ваши посетители должны использовать браузер, который указывает dcb/dcz в Accept-Encoding и отправляет Available-Dictionary. На сегодняшний день это означает Chrome 130+ и Edge 130+, поддержка Firefox находится в разработке.

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

Мы уже начали внутреннее тестирование транзитной передачи. В контролируемом тесте мы развернули два js-бандла последовательно. Они были почти идентичны, за исключением нескольких локализованных изменений между версиями, представляющих последовательные развертывания одного и того же веб-приложения. Без сжатия размер ресурса составляет 272 КБ. Gzip уменьшил его до 92,1 КБ, что является солидным сокращением на 66%. При использовании сжатия с общим словарем через DCZ, где предыдущая версия использовалась в качестве словаря, тот же ресурс уменьшился до 2,6 КБ. Это сокращение на 97% по сравнению с уже сжатым ресурсом.

В том же лабораторном тесте мы измерили две временные вехи на стороне клиента: время до первого байта (TTFB) и полное время загрузки. Результаты TTFB интересны тем, чего они не показывают. При промахе кэша (когда DCZ необходимо сжимать относительно словаря на исходном сервере) TTFB всего примерно на 20 мс медленнее, чем у gzip. Накладные расходы на передачу почти незначительны.

Разница видна во времени загрузки. При промахе кэша DCZ завершил работу за 31 мс против 166 мс у gzip (улучшение на 81%). При попадании в кэш — 16 мс против 143 мс (улучшение на 89%). Ответ настолько меньше, что даже при небольшой задержке в начале вы финишируете намного быстрее.

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

Этап 2: Здесь Cloudflare начинает делать работу за вас. Вместо обработки заголовков словарей, сжатия и логики отката на исходном сервере, на этом этапе вы указываете Cloudflare через правило, какие ресурсы следует использовать в качестве словарей, а мы управляем всем остальным. Мы добавляем заголовки Use-As-Dictionary, сохраняем байты словаря, выполняем дельта-сжатие новых версий относительно старых и обслуживаем правильный вариант для каждого клиента. Ваш исходный сервер отдает обычные ответы. Вся сложность работы со словарями переходит с вашей инфраструктуры на нашу.

Чтобы продемонстрировать это, мы создали живое демо, показывающее, как это выглядит на практике. Попробуйте здесь: Can I Compress (with Dictionaries)?

Демо развертывает новый JavaScript-бандл размером ~94 КБ каждую минуту, имитируя типичный бандл production-одностраничного приложения. Большая часть кода статична между развертываниями; каждый раз изменяется только небольшой блок конфигурации, что также отражает реальные развертывания, где большая часть бандла — это неизменяемый код фреймворков и библиотек. Когда загружается первая версия, граничная сеть Cloudflare сохраняет её как словарь. Когда прибывает следующее развертывание, браузер отправляет хэш уже имеющейся у него версии, и граничная сеть выполняет дельта-сжатие нового бандла относительно него. Результат: 94 КБ сжимаются примерно до 159 байт. Это сокращение на 99,5% по сравнению с gzip, потому что по сети передается только фактическая разница.

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

Этап 3: Словарь генерируется автоматически от имени веб-сайта. Вместо того чтобы клиенты указывали, какие ресурсы использовать в качестве словарей, Cloudflare идентифицирует их автоматически. Наша сеть уже видит каждую версию каждого ресурса, который через неё проходит, включая миллионы сайтов, миллиарды запросов и каждое новое развертывание. Идея в том, что когда сеть наблюдает шаблон URL, в котором последовательные ответы имеют большую часть содержимого общей, но различаются по хэшу, это сильный сигнал о том, что ресурс версионируется и является кандидатом для дельта-сжатия. Она сохраняет предыдущую версию как словарь и сжимает последующие версии относительно него. Никакой конфигурации со стороны клиента. Никакого обслуживания.

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

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

В течение большей части истории веба сжатие было бессостоятельным (stateless). Каждый ответ сжимался так, как будто клиент никогда ничего не видел прежде. Общие словари меняют это: они дают сжатию память.

Сейчас это важнее, чем было бы пять лет назад. Агентские инструменты кодирования сокращают интервал между развертываниями, одновременно увеличивая долю трафика, который их потребляет. Хотя сегодня инструменты ИИ могут создавать огромные различия (diffs), агенты получают больше контекста и становятся более точными в своих изменениях кода. Это, в сочетании с более частыми выпусками и более автоматизированными клиентами, означает больше избыточных байтов при каждом запросе. Дельта-сжатие помогает с обеих сторон этого уравнения, сокращая количество байт на передачу и количество необходимых передач в целом.

Стандартизация Общих словарей заняла десятилетия. Cloudflare помогает создавать инфраструктуру, чтобы это работало для каждого клиента, который обращается к вашему сайту, человеческого или нет. Бета-версия Этапа 1 откроется 30 апреля, и мы с нетерпением ждем, когда вы её попробуете.

_____