Brotli или Gzip: как настроить сжатие файлов сайта и не увеличить нагрузку на сервер

Brotli или Gzip: как настроить сжатие файлов сайта и не увеличить нагрузку на сервер

Передача HTML, CSS, JavaScript, JSON и других текстовых ресурсов без сжатия увеличивает объем ответа и задерживает загрузку страницы. Однако простого включения максимального уровня Brotli недостаточно. Чем сложнее серверу сжимать ответ на лету, тем больше процессорного времени он тратит под нагрузкой. Поэтому задача бизнеса — уменьшить трафик, не превратив оптимизацию в новый источник задержек и нестабильности.

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

Что происходит при передаче сжатого ответа

Браузер сообщает серверу поддерживаемые форматы в заголовке Accept-Encoding. Сервер выбирает доступный вариант, сжимает тело ответа и указывает результат в Content-Encoding. Если клиент принимает Brotli, ответ может получить значение br; если нет — gzip или несжатое представление. Браузер распаковывает данные автоматически, поэтому код страницы для пользователя не меняется.

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

Почему нужен заголовок Vary

Один URL может возвращаться в нескольких вариантах: br, gzip и без сжатия. Заголовок Vary: Accept-Encoding сообщает промежуточным кешам и CDN, что эти ответы нельзя смешивать. Без корректного разделения кеша клиент может получить неподдерживаемый формат либо несжатую копию, хотя браузер умеет работать со сжатием.

Brotli и Gzip решают одну задачу по-разному

Brotli

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

Gzip

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

Выбор не должен быть взаимоисключающим

Корректная архитектура не заставляет выбирать один формат для всех запросов. Сервер проводит согласование с браузером: отдает Brotli при поддержке, Gzip — остальным совместимым клиентам и исходный файл, если сжатие недоступно. Такой подход сохраняет совместимость и позволяет постепенно внедрять новую конфигурацию.

Какие ресурсы стоит сжимать

• HTML-страницы и фрагменты разметки;
• CSS и JavaScript;
• JSON, XML, SVG и текстовые ответы API;
• шрифты и другие форматы — только после проверки конкретного типа и способа доставки;
• текстовые выгрузки и документы, если сервер действительно отдает их без собственного сжатия.

Ориентироваться только на расширение файла рискованно. Сервер применяет правила по MIME-типам, поэтому неверный Content-Type может исключить нужный ресурс или, наоборот, отправить в компрессор неподходящий объект.

Что обычно не нужно сжимать повторно

• JPEG, PNG, WebP, AVIF и большинство других оптимизированных изображений;
• MP4, WebM, MP3 и другие медиаконтейнеры;
• ZIP, GZ, 7Z, PDF и иные форматы, внутри которых уже используется сжатие;
• очень маленькие ответы, где заголовки и вычисления могут перевесить экономию.

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

Динамическое или предварительное сжатие

Динамическое сжатие

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

Предварительное сжатие

Для неизменяемых CSS, JavaScript и SVG можно заранее создать версии .br и .gz. Веб-серверу останется выбрать готовый файл по Accept-Encoding. Это позволяет применять более плотное сжатие без постоянных вычислений. Важно обновлять такие версии при каждом изменении оригинала и выдавать правильные Content-Type, Content-Encoding и правила кеширования.

Рабочая комбинация

• статические ассеты с хешем в имени — предварительное Brotli и Gzip;
• HTML и динамические ответы — умеренное сжатие на лету;
• CDN — отдельная проверка, поскольку он может сжимать, кешировать или изменять ответ самостоятельно;
• редко запрашиваемые крупные выгрузки — решение по замерам, а не единое глобальное правило.

Как внедрять сжатие без риска

1. Зафиксируйте исходные показатели: размер ответов, время до первого байта, загрузку CPU, пропускную способность и долю ошибок.

2. Составьте перечень MIME-типов и разделите статические и динамические ресурсы.

3. Включите Gzip на текстовых ответах и проверьте заголовки, если сжатия еще нет.

4. Добавьте Brotli с приоритетом для поддерживающих клиентов, сохранив Gzip как резерв.

5. Для ассетов сборки подготовьте .br и .gz заранее и настройте обновление вместе с оригиналом.

6. Проверьте Vary: Accept-Encoding, CDN, reverse proxy и серверный кеш.

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

8. Развертывайте настройку поэтапно и наблюдайте за CPU, памятью, задержками и ошибками после релиза.

Пример базовой настройки Nginx

Стандартная сборка Nginx содержит модуль Gzip. Поддержка Brotli зависит от окружения: модуль может поставляться отдельно или быть реализован на CDN. Перед изменением конфигурации проверьте доступные модули и сделайте резервную копию.

gzip on;

gzip_comp_level 5;

gzip_min_length 1024;

gzip_vary on;

gzip_types text/plain text/css application/javascript

application/json application/xml image/svg+xml;

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

brotli on;

brotli_comp_level 5;

brotli_static on;

brotli_types text/plain text/css application/javascript

application/json application/xml image/svg+xml;

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

Пример базовой настройки Apache

В Apache Gzip обычно реализуется модулем с фильтром DEFLATE, а Brotli — отдельным модулем. Включайте сжатие только для текстовых типов.

AddOutputFilterByType DEFLATE text/html text/plain text/css

AddOutputFilterByType DEFLATE application/javascript application/json

AddOutputFilterByType DEFLATE application/xml image/svg+xml

AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css

AddOutputFilterByType BROTLI_COMPRESS application/javascript application/json

AddOutputFilterByType BROTLI_COMPRESS application/xml image/svg+xml

Если оба фильтра активны, приоритет и согласование должны быть проверены на реальном ответе. Убедитесь, что сервер не применяет двойное сжатие и что модуль добавляет корректный Vary. На проектах с управляемым хостингом безопаснее использовать штатную панель или согласовать изменения с администратором.

Как проверить результат

Проверка заголовков

Откройте несколько HTML, CSS, JavaScript и JSON-ресурсов в инструментах разработчика. В ответе должны быть корректные Content-Type, Content-Encoding и Vary. Размер переданных данных должен быть меньше исходного. Проверяйте как минимум три режима: запрос с br, запрос только с gzip и запрос без поддерживаемого сжатия.

curl -I -H 'Accept-Encoding: br' https://example.ru/app.js

curl -I -H 'Accept-Encoding: gzip' https://example.ru/app.js

curl -I -H 'Accept-Encoding: identity' https://example.ru/app.js

Команда с методом HEAD не во всех конфигурациях полностью повторяет обработку GET. Если заголовки вызывают сомнение, загрузите тело ответа с тем же Accept-Encoding и сравните поведение.

Проверка кеша и CDN

• варианты br и gzip не подменяют друг друга;
• после обновления ассета не остается устаревшая предварительно сжатая копия;
• ETag и условные запросы работают для конкретного представления;
• CDN не удаляет Vary и не возвращает двойной Content-Encoding;
• ответы с персональными данными не попадают в общий кеш из-за сопутствующих настроек.

Проверка серверной нагрузки

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

Ошибки, которые сводят пользу к нулю

• Максимальный уровень Brotli используется для каждого динамического ответа. Сервер тратит много CPU ради небольшой дополнительной экономии.
• Brotli включен без Gzip-резерва. Часть клиентов и технических систем получает несжатые ответы.
• Сжимаются изображения, архивы и видео. Трафик почти не уменьшается, а вычисления растут.
• Не указан Vary: Accept-Encoding. Кеш хранит и раздает несовместимые представления как один объект.
• Предварительно сжатые файлы не обновляются вместе с оригиналом. Пользователь получает старый код после релиза.
• Сжатие настроено одновременно на приложении, reverse proxy и CDN без проверки. Возникает повторная обработка или конфликт заголовков.
• Учитывается только оценка теста скорости. Реальная загрузка сервера, география пользователей и кеширование остаются без контроля.
• Сжатие применяют к очень коротким ответам. Накладные расходы оказываются сопоставимы с экономией.

Безопасность и сжатие защищенных страниц

Сжатие ответов по HTTPS само по себе является штатной практикой, но динамические страницы с секретными значениями требуют отдельной оценки. Известны классы атак, использующие изменение размера сжатого ответа, когда атакующий способен влиять на часть содержимого и многократно наблюдать результат. Для форм, токенов и чувствительных персонализированных данных решение должен проверять специалист по безопасности. Нельзя компенсировать риск только сменой Brotli на Gzip: принцип атаки связан с контекстом сжатия, а не с названием формата.

Как сжатие связано с SEO и бизнесом

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

Однако сжатие — лишь один слой производительности. Если приложение медленно формирует HTML или интерфейс выполняет тяжелый код, уменьшенный ответ не устранит задержку. Поэтому результат оценивают в связке с кешированием, оптимизацией изображений, сокращением JavaScript, скоростью backend и пользовательскими метриками.

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

Краткий чек-лист перед публикацией

• Brotli включен только там, где он поддерживается инфраструктурой.
• Gzip сохранен как резервный вариант.
• Сжимаются текстовые MIME-типы, а не все файлы подряд.
• Для статических ассетов рассмотрено предварительное сжатие.
• Для динамики выбран умеренный уровень качества.
• Ответ содержит корректные Content-Encoding и Vary: Accept-Encoding.
• CDN, proxy и origin не сжимают один ответ повторно.
• Версии .br и .gz обновляются вместе с исходными файлами.
• Проверены HTML, CSS, JavaScript, JSON и ответы без поддержки сжатия.
• После релиза контролируются CPU, задержки, ошибки и фактический объем передачи.

Резюме

Для большинства сайтов разумна совместная схема: Brotli для современных клиентов, Gzip как резерв и несжатый ответ для остальных. Статические ресурсы лучше готовить заранее, а динамические — сжимать на лету без максимального качества. Основной риск возникает не из-за выбранного формата, а из-за настройки без учета кеша, MIME-типов, CDN и ресурсов сервера.

Успешное внедрение подтверждается не названием алгоритма в отчете, а совокупностью результатов: объем ответа уменьшился, время загрузки не ухудшилось, сервер сохраняет запас производительности, а все варианты корректно кешируются и доставляются клиентам.