Сжатие Zstandard против Brotli: как оптимизировать пропускную способность веб-сервера при нагрузке от ИИ-краулеров

12 мин чтенияОбновлено 03.10.2026

Сжатие Zstandard (zstd) против Brotli: оптимизация пропускной способности при массированном парсинге ИИ-краулерами

С появлением поисковых систем нового поколения архитектура веб-серверов столкнулась с принципиально новым паттерном нагрузки. Если традиционные поисковые роботы обходят сайты размеренно, соблюдая установленные задержки и опираясь на кэширующие заголовки, то краулеры генеративного поиска (такие как PerplexityBot и SearchGPT / OAI-SearchBot) сканируют ресурсы массированными параллельными потоками. Их цель — мгновенное извлечение актуальных каталогов, цен, структурированных данных и текстового контекста для синтеза ответов пользователям в реальном времени.

Для владельцев крупных контентных проектов и каталогов с сотнями тысяч страниц такой парсинг оборачивается двумя критическими проблемами: взрывным ростом счетов за исходящий сетевой трафик (egress bandwidth) и резкими скачками утилизации CPU при динамическом сжатии контента «на лету». В этой статье команда агентства Cobalt Media детально сопоставляет алгоритмы Zstandard (zstd) и Brotli и предлагает архитектурные решения для устойчивой работы веб-серверов под давлением ИИ-ботов.

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

Архитектурные различия: как работают Zstandard и Brotli

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

Brotli: ориентация на структуру веб-данных

Разработанный инженерами Google алгоритм Brotli (RFC 7932) проектировался с прицелом на максимальную плотность упаковки веб-ресурсов. Его главные архитектурные особенности:

Статический словарь на 122 КБ: содержит часто встречающиеся фрагменты HTML, CSS, JavaScript, а также популярные фразы и конструкции веб-документов. Это позволяет Brotli превосходно сжимать небольшие фрагменты верстки даже без предварительного накопления контекста.
Асимметричный профиль вычислений: алгоритм обеспечивает высокую плотность сжатия, однако каждый дополнительный уровень компрессии требует экспоненциально больше процессорного времени.
Диапазон уровней компрессии: шкала от 1 до 11, где уровни с 1 по 4 предназначены для динамического сжатия, а уровни 9–11 — исключительно для статической предварительной подготовки файлов.

Zstandard (zstd): фокус на скорости и масштабируемости

Алгоритм Zstandard (RFC 8878), созданный Янником Колле в Meta, основан на совершенно других принципах энтропийного кодирования:

Энтропийное кодирование FSE (Finite State Entropy): использование табличной разновидности асимметричных систем счисления (tANS) позволяет zstd выполнять операции сжатия и распаковки на скоростях, близких к теоретическому пределу пропускной способности оперативной памяти.
Симметричная высокая скорость: zstd сжимает данные значительно быстрее аналогичных по степени сжатия алгоритмов и демонстрирует феноменальную скорость распаковки независимо от выбранного уровня компрессии.
Широкий спектр настроек: доступно более 20 уровней компрессии (включая отрицательные уровни для сверхбыстрого потокового сжатия в реальном времени) и поддержка обучения пользовательских словарей под узкоспециализированные форматы данных.

Согласование контента (Content Negotiation) в HTTP

Современные поисковые краулеры и сетевые библиотеки активно отправляют заголовок Accept-Encoding с указанием поддерживаемых схем: zstd, br, gzip. Веб-сервер обязан корректно разобрать этот заголовок и выбрать оптимальный кодек с учетом приоритетов производительности и доступных серверных ресурсов.

Сравнительный бенчмарк в сценариях массированного краулинга

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

Коэффициент сжатия текстовых ресурсов и каталогов

HTML-страницы и разметка каталогов: Brotli на уровнях 4–5 демонстрирует преимущество в степени сжатия на 2–4% по сравнению с zstd на уровне 3 за счет встроенного веб-словаря. Однако разница в абсолютном размере на типичной каталожной странице размером 150 КБ составляет всего 3–5 КБ.
Структурированные JSON-выгрузки и API: при передаче дампов товаров, таблиц свойств и фидов разница в степени сжатия между zstd и Brotli нивелируется и составляет менее 1%, при этом оба алгоритма превосходят классический gzip на 20–25%.
Повторяющиеся текстовые структуры: при сжатии объемных массивов данных (свыше 500 КБ) скользящее окно zstd эффективно находит длинные совпадения, обеспечивая идентичный с Brotli итоговый вес полезной нагрузки.

Пропускная способность компрессии (Throughput) и нагрузка на процессор

Скорость сжатия zstd (уровень 3): составляет порядка 300–420 МБ/с на одно процессорное ядро. Это позволяет веб-серверу сжимать динамические ответы на лету без образования очередей даже в момент параллельного обхода сотнями воркеров краулера.
Скорость сжатия Brotli (уровень 4): держится в диапазоне 45–60 МБ/с на ядро. При повышении уровня до 5–6 пропускная способность падает до 15–25 МБ/с, что при залповом трафике ботов неминуемо утилизирует 100% ресурсов CPU.
Энергоэффективность и накладные расходы: на одинаковом объеме переданного трафика zstd требует в 5–7 раз меньше процессорных тактов, чем Brotli с сопоставимым коэффициентом сжатия.

Скорость декомпрессии на стороне краулера

Распаковка zstd: стабильно превышает 1200–1600 МБ/с на ядро. Краулер тратит минимальное время на декодирование входящего потока, быстрее освобождает сетевой сокет и снижает задержку в конвейере индексации.
Распаковка Brotli: составляет около 350–450 МБ/с на ядро. Это существенно быстрее gzip, однако в 3–4 раза медленнее zstd, что становится заметным фактором для краулеров, агрегирующих терабайты контента в сутки.

Расход оперативной памяти под нагрузкой

Контроль памяти в zstd: размер рабочего окна строго лимитирован настройками сервера (обычно от 512 КБ до 2 МБ на поток), что обеспечивает линейное и предсказуемое потребление RAM независимо от объема входящих соединений.
Потребление памяти в Brotli: на средних и высоких уровнях сжатия требует значительного объема контекстной памяти на каждый открытый сокет (до 8–16 МБ на сессию), что при одновременной атаке краулеров в сотни потоков способно вызвать дефицит оперативной памяти и активацию OOM-killer.

Архитектурная стратегия: разделение статического и динамического сжатия

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

Предварительное статическое сжатие (Pre-compression)

Для всех статических ассетов, периодически генерируемых HTML-слепков каталога, архивов sitemap.xml и файловых фидов используется фоновое статическое сжатие при сборке или публикации:

Применение экстремальных уровней: файлы сжимаются заранее с использованием Brotli уровня 11 (.br) и zstd уровня 19–22 (.zst).
Нулевой оверхед по CPU: веб-сервер просто передает готовый сжатый бинарный файл с диска или из системного кэша страниц ядра ОС через системный вызов sendfile, экономя и процессорные циклы, и полосу пропускания.
Экономия трафика: обеспечивает максимально теоретически возможную плотность сжатия данных для всех ботов, поддерживающих соответствующие кодеки.

Динамическое сжатие «на лету» (On-the-fly Dynamic Compression)

Для страниц серверного рендеринга (SSR), динамической пагинации, результатов фильтрации каталога и ответов API действует другой принцип:

Приоритет Zstandard уровня 1–3: на этих уровнях zstd обеспечивает степень сжатия, близкую к Brotli уровня 4, но работает в разы быстрее, полностью исключая задержку первого байта (TTFB).
Жесткое ограничение Brotli: если клиент не поддерживает zstd и сервер вынужден использовать Brotli, уровень динамического сжатия не должен превышать 4 (для высоконагруженных узлов — не более 3).
Автоматический fallback на gzip: устаревшие краулеры и клиенты получают gzip уровня 4–5 как наименее затратный запасной вариант.

Практическая настройка веб-серверов

Рассмотрим эталонную конфигурацию стека на базе популярного веб-сервера Nginx с подключенными модулями динамического и статического сжатия.

Конфигурация Nginx для обслуживания zstd и Brotli

В блоке http или конкретном server настраивается параллельная работа обоих модулей с четким определением поддерживаемых MIME-типов:

Включение статических модулей: директивы zstd_static on; и brotli_static on; активируют автоматический поиск предварительно сжатых файлов с суффиксами .zst и .br перед обращением к исходному файлу.
Динамический zstd: установка директивы zstd on; с параметром zstd_comp_level 3;. Это оптимальная точка баланса, гарантирующая высокую компрессию без риска перегрузки ядер процессора.
Динамический Brotli: установка директивы brotli on; с параметром brotli_comp_level 4; и brotli_window 512k; для ограничения аппетитов алгоритма к оперативной памяти.
Фильтрация типов контента: сжатие активируется только для текстовых форматов: text/html, text/plain, text/css, application/json, application/javascript, application/xml, application/ld+json. Сжатие бинарных медиафайлов (изображений и видео) строго отключается, так как оно лишь расходует CPU без уменьшения размера.
Минимальная длина ответа: директивы zstd_min_length 256; и brotli_min_length 256; отсекают микроскопические ответы, накладные расходы на сжатие которых превышают выигрыш в байтах.

Управление заголовком Vary и проксирующим кэшированием

Критически важный нюанс при внедрении нескольких алгоритмов сжатия — предотвращение кэширования несовместимых ответов промежуточными узлами и CDN:

Заголовок Vary: сервер обязан всегда передавать заголовок Vary: Accept-Encoding. Без этого промежуточный кэш CDN может сохранить zstd-ответ и отдать его клиенту, запросившему только gzip, что приведет к поломке отображения или ошибке парсинга.
Согласование на Edge-уровне: при использовании CDN (например, Cloudflare или Fastly) рекомендуется включить сжатие zstd между origin-сервером и узлами доставки контента. Это снижает междатацентровый трафик и защищает канал основного сервера.

Оптимизация тяжелых каталогов для поисковых LLM-систем

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

Эффективность сжатия JSON-LD и микроразметки

Страницы каталогов интернет-магазинов и агрегаторов часто содержат десятки килобайтов семантической разметки Schema.org в формате JSON-LD. Такие структуры обладают высокой степенью лексической избыточности: ключи @type, offers, price, availability и названия категорий повторяются на странице сотни раз. Zstandard превосходно утилизирует эту избыточность, сжимая семантический блок на 80–85% за доли миллисекунды, что существенно ускоряет передачу карточек товаров в поисковый индекс.

Сохранение краулингового бюджета и предотвращение ошибок

Если сервер не справляется с динамическим сжатием при залповом обращении краулера, происходят следующие негативные сценарии:

Рост задержки первого байта (TTFB): время ожидания ответа возрастает от нормальных 80–120 мс до нескольких секунд.
Срабатывание защитных лимитов краулера: боты Perplexity и SearchGPT динамически регулируют интенсивность сканирования. При росте задержек бот снижает число параллельных потоков и сокращает объем исследуемых страниц сайта.
Ошибки 429 и 504: исчерпание свободных процессов веб-сервера приводит к отказам в обслуживании, из-за чего часть каталога выпадает из индекса поисковой ИИ-системы или теряет актуальность цен и остатков.

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

Пошаговый план внедрения: рекомендации Cobalt Media

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

Анализ логов веб-сервера: оцените долю трафика, приходящуюся на краулеры SearchGPT, PerplexityBot и других ИИ-агентов. Проверьте реальное присутствие токенов zstd и br в их заголовках Accept-Encoding.
Аудит текущей утилизации CPU: зафиксируйте базовую загрузку процессора в моменты пиковой активности поисковых ботов. Если процессор периодически упирается в 80–90%, переход на zstd для динамических ответов даст немедленный эффект разгрузки.
Внедрение раздельного конвейера: настройте сборку статических архивов (.zst и .br) максимальной плотности для всех неизменяемых ассетов и статических страниц каталога.
Конфигурация динамического zstd: активируйте модуль zstd на уровне reverse proxy с ограничением уровня компрессии не выше 3. Для Brotli зафиксируйте уровень 4.
Тестирование заголовков и распаковки: выполните серию проверок с помощью утилиты curl с передачей различных комбинаций заголовка Accept-Encoding. Убедитесь в корректности кодировки ответа (Content-Encoding) и наличии директивы Vary: Accept-Encoding.
Финальный мониторинг: оцените изменение показателей объема исходящего трафика, среднего TTFB и загрузки CPU веб-сервера в течение 7–14 дней после развертывания.

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

Cobalt Media проведет предварительный аудит, определит приоритетные направления роста и подготовит прозрачную оценку работ без обещаний гарантированного места в выдаче.

по теме

Стоимость SEO-продвижения Бесплатный SEO-Аудит