Brotli: зачем нужно, как проверить и настроить для SEO

У сайта может быть быстрый сервер, хороший кеш и аккуратный код, но HTML, CSS и JavaScript всё равно передаются посетителю тяжелее, чем нужно. Brotli решает именно эту узкую задачу: уменьшает объём текстовых данных при передаче, а браузер распаковывает их автоматически.

Для владельца бизнеса смысл простой: посетителю не нужен «Brotli ради Brotli». Нужна страница, которая быстрее получает необходимые данные. Поэтому проверять стоит не красивую галочку в панели хостинга, а реальный HTTP-ответ и фактический объём переданных файлов.

Brotli: что происходит между сервером и браузером

Brotli — алгоритм сжатия без потерь. Исходный HTML, CSS или JavaScript после распаковки остаётся тем же: сервер не переписывает страницу, а лишь плотнее упаковывает данные на время передачи. Примерно как зимняя куртка в вакуумном пакете: вещь та же, но чемодан внезапно закрывается без помощи колена.

Браузер сообщает серверу, какие способы сжатия он понимает:

Accept-Encoding: br, gzip

Если сервер или CDN выбирает Brotli, ответ содержит:

Content-Encoding: br

После получения браузер сам восстанавливает исходные данные. Поэтому отдельный brotli.js обычному сайту для HTTP-сжатия не нужен. Утилита Brotli или brotli.exe пригодится в другом сценарии — например, чтобы заранее подготовить статические файлы .br и потом раздавать уже готовую сжатую версию.

Где здесь SEO, а где начинается магия отчётов

Brotli не стоит воспринимать как самостоятельный «фактор SEO». Поисковая система не выдаёт бонус просто за наличие Content-Encoding: br. Практическая польза в другом: меньший объём текстовых ресурсов может сократить время их передачи и тем самым помочь производительности конкретной страницы.

Google указывает, что Core Web Vitals используются системами ранжирования, но одновременно предупреждает: хорошие показатели сами по себе не гарантируют высоких позиций. Поэтому включить Brotli и ждать, что сайт проснётся утром на первом месте, — примерно как поставить новые шины и рассчитывать, что машина сама выиграет ралли.

Для технического SEO сжатие — лишь одна деталь доставки страницы. Если тормозит сервер, LCP-картинка весит несколько мегабайт или браузер занят тяжёлым JavaScript, правильный br эту проблему не вылечит. Эффект стоит оценивать по реальным веб-показателям, а не по факту включения модуля.

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

Проверять нужно ответ сайта, а не галочку в панели

Надёжнее всего запросить один URL с разными Accept-Encoding и посмотреть, что реально получает посетитель. Особенно это важно при CDN: внешний узел может самостоятельно сжимать или преобразовывать ответ, поэтому конфигурация origin-сервера ещё не рассказывает всей истории.

Проверка Brotli:

curl -sS -D - -o /dev/null \
  -H 'Accept-Encoding: br' \
  https://example.com/

При корректной выдаче Brotli в ответе появится:

Content-Encoding: br

Для кешируемых вариантов также важно корректное разделение представлений по Accept-Encoding.

Затем сравните фактический размер передачи:

curl -sS -o /dev/null -w '%{size_download}\n' \
  -H 'Accept-Encoding: gzip' https://example.com/

curl -sS -o /dev/null -w '%{size_download}\n' \
  -H 'Accept-Encoding: br' https://example.com/

curl -sS -o /dev/null -w '%{size_download}\n' \
  -H 'Accept-Encoding: identity' https://example.com/

Лучше проверить не только главную страницу, а HTML типовой посадочной, основной CSS и крупный JavaScript-файл.

Проверка	Что должно происходить
Accept-Encoding: br	при поддержке Brotli ответ получает Content-Encoding: br
Только gzip	сервер или CDN способен отдать резервный вариант
identity	приходит несжатое представление
HTML, CSS, JS	объём передачи после сжатия уменьшается
Кеш	разные варианты ответа не смешиваются

Как настраивать Brotli без лишней нагрузки

Для Nginx Brotli обычно подключается отдельным модулем. ngx_brotli умеет как сжимать ответ на лету, так и отдавать заранее подготовленные .br-файлы. Второй вариант особенно удобен для редко меняющейся статики: процессор тратит время на сжатие один раз, а не при каждом запросе.

После установки модуля базовая конфигурация может выглядеть так:

brotli on;
brotli_comp_level 6;
brotli_static on;

brotli_types
    text/plain
    text/css
    application/javascript
    application/json
    application/xml
    image/svg+xml;

gzip on;
gzip_types
    text/plain
    text/css
    application/javascript
    application/json
    application/xml
    image/svg+xml;

После изменения:

nginx -t && systemctl reload nginx

У Brotli есть уровни качества до 11, но «11» не означает «сайт летает в 11 раз быстрее». Более плотное динамическое сжатие требует больше вычислений. Выкручивать максимум без замеров — примерно как вакуумировать каждую булку хлеба прямо на кассе: упаковка компактная, зато очередь быстро объяснит цену идеи.

На Apache аналогичную задачу решает mod_brotli. Если перед сайтом стоит CDN, сначала проверьте именно внешний ответ: CDN уже может выбирать Brotli, gzip или другой поддерживаемый формат самостоятельно, и доработка origin-сервера не всегда меняет результат для посетителя.

Ошибки, из-за которых сжатие превращается в проблему

Первая ошибка — принудительно отдавать .br независимо от возможностей клиента. Например, brotli_static always в ngx_brotli позволяет использовать предварительно сжатый файл без проверки поддержки. Для обычного публичного сайта правильнее согласовывать формат с клиентом.

Вторая — пытаться повторно сжимать JPEG, WebP, ZIP, видео и другие уже сжатые форматы. Дополнительная экономия там обычно невелика, зато работа сервера вполне настоящая.

Третья — смотреть только на наличие br. Страница может получать Brotli и всё равно быть медленной из-за огромного изображения, ответа базы данных или тяжёлого JavaScript. Сжатие исправлено, а проблема осталась.

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

Пятая — проверять nginx.conf, но не боевой URL. Пользователь общается с итоговой цепочкой сервер → прокси → CDN → браузер. Именно последний HTTP-ответ и является истиной для диагностики.

Практический сценарий: когда Brotli стоит оставить

Представим интернет-магазин, у которого категория товаров открывается медленнее ожидаемого. В ней большой HTML, общий CSS и несколько JavaScript-файлов. Вместо предположения «включим Brotli — станет быстро» проверка начинается с фактов.

Для HTML, CSS и основного JS фиксируют объём передачи при identity, gzip и br. Затем убеждаются, что статусы ответов, типы содержимого и сама страница после распаковки не изменились. После этого смотрят время ответа и нагрузку сервера: выигрыш в килобайтах не должен покупаться заметным замедлением генерации динамических страниц.

Если Brotli уменьшает передачу и не создаёт проблем на сервере, настройку имеет смысл оставить. Если разница невелика, а основное время уходит на LCP-изображение, внешний виджет или медленный backend, приоритет нужно перенести туда.

Именно так и стоит относиться к Brotli: не как к медали «техническое SEO выполнено», а как к одному измеримому инструменту. В конце проверки нужен простой ответ — что стало легче передавать, не стало ли серверу тяжелее работать и заметно ли исправление там, где страницу действительно тормозило.