Как на самом деле работает HTTP-сжатие
Сжатие в вебе — это тихое согласование, которое происходит при каждом запросе. Браузер объявляет, что он умеет распаковывать, в заголовке Accept-Encoding — современные браузеры отправляют gzip и br. Сервер выбирает один вариант, сжимает тело ответа и помечает его заголовком Content-Encoding, чтобы браузер знал, как его распаковать. Ни код вашего приложения, ни ваш HTML не меняются; преобразование целиком происходит в пути.
Выигрыш велик, потому что текст сжимается исключительно хорошо. HTML-страница в 100 КБ обычно передаётся как 20 КБ с Gzip; бандл JavaScript часто уменьшается на три четверти. Для посетителей на медленных или мобильных соединениях эта разница — видимая часть времени загрузки, поэтому сжатие — та редкая оптимизация, которая почти бесплатна и почти всегда правильна для текста.
Что на самом деле улучшает Brotli
Преимущество Brotli складывается из двух проектных решений: более умного формата и встроенного словаря строк, которые постоянно встречаются в вебе — HTML-теги, имена CSS-свойств, типичные токены JavaScript. Веб-текст — именно то, под что он настраивался, и на нём Brotli обычно выдаёт файлы на 15–20% меньше, чем Gzip, на тех уровнях сжатия, которые серверы используют в реальном времени.
Но сохраним честную рамку: это 15–20% поверх уже существующего сокращения Gzip на 70–80%. Если страница передаётся как 20 КБ в gzip, Brotli делает её примерно 16–17 КБ. Стоит того — эффект складывается по каждому ресурсу и каждому посетителю — но это доработка, а не революция. Если вы видите графики бенчмарков с драматической разницей, проверьте, не сравнивают ли они самый медленный, максимальный уровень Brotli с уровнем Gzip по умолчанию; на таких настройках Brotli слишком медленный для пожатия на каждый запрос и используется для предварительного сжатия статических файлов.
Совместимость перестала быть проблемой много лет назад: практически каждый современный браузер отправляет br в своём Accept-Encoding, а благодаря согласованию редкий старый клиент, который этого не делает, просто получает Gzip. Для посетителя минусов нет вообще.
Что нельзя сжимать никогда
Зеркальное правило не менее важно: сжатие уже сжатых байтов тратит CPU и часто делает файлы чуть больше. Изображения (JPEG, PNG, WebP, AVIF), видео и аудио, шрифты в WOFF2, ZIP-архивы, PDF со встроенными изображениями — их форматы уже выжали всю избыточность. Gzip и Brotli там нечего искать.
Именно поэтому сжатие настраивается по типу контента, и поэтому сплошное правило «сжимать всё» — небольшая, но реальная ошибка. Практическое разделение: текстовые типы включаем (HTML, CSS, JS, JSON, XML, SVG), бинарные медиа выключаем. SVG — единственный формат изображений, который относится к текстовой колонке: это XML, и он сжимается превосходно.
Где сжатие должно работать: на edge, а не на сервере приложения
Сжатие стоит CPU на каждом ответе, и чем дальше вниз по потоку оно выполняется, тем реже оно выполняется. Когда сжимает edge, закешированная страница сжимается один раз, и именно сжатая копия отдаётся из кеша тысячи раз — ваш origin не тратит ничего, а edge хранит каждый вариант, который клиент может принять.
На cdn.com.tr это настройка на уровне правила доставки: у каждого правила есть список сжатия (gzip, zip, brotli), который вы переключаете в панели рядом с настройками кеширования и оптимизации того же правила. Включить Brotli — это чекбокс, а не миграция сервера, и поскольку настройка живёт на правиле, вы можете агрессивно сжимать свои страницы, не трогая правило для уже сжатых медиафайлов — именно то разделение, о котором шла речь в предыдущем разделе.
Проверьте, что вы отдаёте на самом деле
Предположения о сжатии оказываются ошибочными достаточно часто, чтобы проверка стоила тридцати секунд. Запросите страницу дважды с разными предложениями Accept-Encoding и прочитайте Content-Encoding в ответе. Заодно сравните переданные размеры — разница и есть ваша экономия, измеренная, а не предполагаемая.
Одна оговорка при тестировании через CDN: edge мог закешировать вариант от более раннего запроса, поэтому используйте query-параметр для обхода кеша, чтобы увидеть свежее поведение, — и помните, что мгновенный ответ сжатой копией из кеша — это ровно та цель, к которой вы стремитесь.
Два запроса, два предложения — читаем, что приходит в ответ
# what does the server send when offered brotli?
curl -sI -H 'Accept-Encoding: br' https://example.com/ | grep -i content-encoding
# and when offered only gzip?
curl -sI -H 'Accept-Encoding: gzip' https://example.com/ | grep -i content-encoding
# compare actual transferred bytes (compressed vs uncompressed)
curl -so /dev/null -H 'Accept-Encoding: br' -w 'brotli: %{size_download} bytes\n' https://example.com/
curl -so /dev/null -H 'Accept-Encoding: identity' -w 'plain: %{size_download} bytes\n' https://example.com/Часто задаваемые вопросы
Стоит ли включать Brotli и Gzip одновременно?
Да — это стандартная конфигурация. Согласование выбирает Brotli для браузеров, предлагающих br, и откатывается на Gzip для остальных. Включить оба — строго лучше, чем любой из них по отдельности.
Замедляет ли сжатие мой сервер?
Оно стоит CPU, но на уровнях, используемых для каждого запроса, эта цена мала по сравнению со сэкономленным трафиком — а когда edge сжимает кешируемый контент, ваш origin не платит вообще ничего: сжатая копия создаётся один раз и отдаётся из кеша.
Почему трафик изображений через CDN идёт без сжатия?
Потому что так и должно быть: JPEG, PNG, WebP и AVIF — уже сжатые форматы, и повторное сжатие тратит CPU при нулевом (иногда отрицательном) выигрыше. Сжатие — для текста. Если вам нужны изображения меньшего размера, рычаг — формат и размеры: конвертация в WebP/AVIF, а не Content-Encoding.
Нужно ли менять код сайта, чтобы использовать Brotli?
Нет. Сжатие согласуется между браузером и сервером/edge на каждом запросе; ваши HTML, CSS и JavaScript остаются нетронутыми. На cdn.com.tr это переключатель в правиле доставки — остальное берёт на себя edge.