Brotli

Brotli для сжатия ресурсов сайта

Brotli представляет собой алгоритм сжатия данных без потерь, который применяется в том числе для уменьшения объёма передаваемых по HTTP ресурсов. Формат стандартизирован в RFC 7932, а при HTTP передаче Brotli обозначается значением br заголовка Content-Encoding.

На веб сайтах Brotli используют прежде всего для текстовых ресурсов. Это HTML, CSS, JavaScript, JSON, XML, SVG и другие данные, размер которых хорошо уменьшается при сжатии. Уже сжатые форматы изображений, видео и аудио обычно не требуется дополнительно пропускать через HTTP компрессию.

Страница Brotli в разделе продуктов и технологий объединяет материалы, где этот алгоритм является существенной частью технической задачи. Здесь рассматриваются применение Brotli на сайтах, взаимодействие с HTTP, веб серверами, CDN, кэшем и диагностикой производительности.

Как Brotli работает при загрузке сайта

При запросе ресурса браузер сообщает серверу поддерживаемые способы сжатия через HTTP заголовок Accept-Encoding. Среди значений может присутствовать br.

Если сервер или CDN поддерживает Brotli и конфигурация разрешает его применение к запрошенному ресурсу, ответ может быть передан в сжатом виде. В этом случае сервер указывает:

Content-Encoding: br

Браузер получает ответ, распаковывает его и передаёт исходные данные дальше для обработки. Сам HTML, CSS или JavaScript после декомпрессии остаётся тем же содержимым, которое сервер должен был отправить без сжатия.

При согласовании кодировки ответа также важно корректное кэширование разных вариантов ресурса. MDN указывает на использование Vary: Accept-Encoding, чтобы кэш мог различать представления, сформированные с разными способами сжатия.

Accept-Encoding и Content-Encoding

Accept-Encoding относится к запросу клиента. С его помощью браузер сообщает, какие кодировки содержимого он способен обработать.

Content-Encoding относится к ответу сервера. Значение br означает, что тело ответа передано с использованием Brotli.

Эти заголовки удобно использовать и для диагностики. Наличие слова Brotli в настройках сервера само по себе ещё не подтверждает, что конкретный HTML, CSS или JavaScript действительно отдаётся браузеру в формате br.

Brotli и gzip

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

Для gzip используется:

Content-Encoding: gzip

Для Brotli используется:

Content-Encoding: br

MDN отмечает, что Brotli способен обеспечивать более плотное сжатие по сравнению с gzip, однако само сжатие Brotli может требовать больше вычислительных ресурсов. Поэтому выбор нельзя сводить только к максимальному уровню компрессии. Для динамически формируемых и некэшируемых ответов необходимо учитывать затраты процессора и время формирования ответа.

На практике Brotli и gzip не обязательно противопоставлять. Сервер или CDN может поддерживать несколько алгоритмов и выбирать подходящий вариант с учётом Accept-Encoding клиента.

Нужен ли gzip после включения Brotli

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

Современные браузеры широко поддерживают HTTP кодировку Brotli, но серверная конфигурация всё равно должна корректно обрабатывать клиентов, для которых br не выбран.

Поэтому при настройке важно проверять фактическую схему согласования кодировки, а не только наличие Brotli на сервере.

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

Brotli можно применять к данным непосредственно в момент формирования HTTP ответа либо заранее создавать сжатые варианты статических ресурсов.

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

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

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

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

Статические CSS, JavaScript и другие ресурсы можно сжимать заранее и хранить подготовленную Brotli версию рядом с исходным файлом.

В этом случае серверу не требуется выполнять полное сжатие при каждом запросе. Например, документация NGINX описывает отдельные механизмы для динамического Brotli сжатия и выдачи предварительно сжатых файлов.

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

Какие файлы имеет смысл сжимать Brotli

Наибольший практический интерес представляет текстовый контент.

HTML содержит разметку и текст документа.

CSS содержит повторяющиеся селекторы, свойства и значения.

JavaScript состоит из текстового программного кода.

JSON и XML используются для передачи структурированных данных.

SVG также является текстовым форматом и в подходящих сценариях может эффективно сжиматься.

Для изображений JPEG, WebP, AVIF, PNG, видеоархивов и других уже сжатых форматов дополнительная HTTP компрессия обычно не даёт той же пользы, что для текстовых данных. MDN рекомендует применять компрессию прежде всего к подходящим ресурсам, исключая уже сжатые изображения, аудио и видео.

Как проверить, работает ли Brotli

Проверять необходимо фактический HTTP ответ конкретного ресурса.

В инструментах разработчика браузера можно открыть вкладку Network, выбрать HTML документ, CSS или JavaScript файл и посмотреть Response Headers.

При работающем Brotli ожидается:

Content-Encoding: br

Если указан:

Content-Encoding: gzip

ресурс передан с использованием gzip.

Если Content-Encoding отсутствует, конкретный ответ может передаваться без HTTP сжатия. Это не всегда означает ошибку, поскольку результат зависит от типа файла, размера ответа, заголовков запроса и настроек инфраструктуры. Принцип проверки по Content-Encoding также используется в документации CDN провайдеров.

Проверка только одного URL недостаточна

Главный HTML документ и статические файлы могут обслуживаться по разным правилам.

Например, HTML может динамически сжиматься веб сервером, CSS и JavaScript поступать через CDN, а изображения передаваться без дополнительной компрессии.

Поэтому при аудите желательно отдельно проверить HTML и несколько характерных статических ресурсов.

Brotli на Nginx

Поддержка Brotli зависит от сборки Nginx и подключённых модулей. Нельзя считать, что директивы Brotli доступны на любом сервере Nginx автоматически.

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

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

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

Brotli и CDN

Если сайт использует CDN, сжатие может выполняться не на основном сервере, а на пограничных узлах CDN.

В таком случае браузер получает Content-Encoding: br, хотя origin сервер может передавать CDN несжатый ответ.

Это важно при диагностике. Проверка только конфигурации Nginx или Apache не всегда объясняет, почему посетитель получает Brotli. Аналогично включение Brotli на origin сервере не гарантирует, что CDN сохранит эту схему без изменений.

Необходимо смотреть итоговый HTTP ответ, правила CDN и поведение кэша.

Brotli и кэширование

Компрессия и кэширование связаны, но выполняют разные функции.

Кэширование позволяет повторно использовать уже полученный или заранее сформированный ответ.

Brotli уменьшает объём представления, передаваемого по сети.

Один и тот же ресурс может существовать в кэше в нескольких вариантах кодировки. Именно поэтому при согласовании сжатия имеет значение заголовок Vary: Accept-Encoding.

Ошибки в этой части инфраструктуры могут привести к тому, что разные клиенты получают неподходящие варианты ответа. При настройке Brotli следует учитывать не только веб сервер, но и CDN, reverse proxy и промежуточные кэши.

Влияние Brotli на скорость сайта

Сжатие уменьшает количество данных, которые необходимо передать клиенту. Это делает Brotli одним из технических инструментов оптимизации передачи текстовых ресурсов.

Однако включение Brotli само по себе не решает все проблемы производительности.

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

Поэтому Brotli следует рассматривать как один элемент общей оптимизации производительности, а не как способ автоматически получить хорошие показатели PageSpeed или Core Web Vitals.

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

Влияние Brotli на SEO

Brotli не является самостоятельным фактором ранжирования, который достаточно включить для роста позиций.

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

Поэтому при техническом SEO аудите наличие Brotli оценивают вместе с кэшированием, серверным ответом, размером HTML, CSS и JavaScript, загрузкой изображений, работой CDN и другими причинами производительности.

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

Типичные проблемы при настройке Brotli

Brotli включён, но Content-Encoding br отсутствует

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

Диагностику следует начинать с фактических заголовков запроса и ответа.

Сжимается не тот тип содержимого

Нет смысла одинаково обрабатывать все форматы. Основной эффект HTTP компрессия даёт на подходящих текстовых данных.

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

Brotli настроен одновременно на нескольких уровнях

Компрессией могут управлять приложение, веб сервер, reverse proxy и CDN. Если неизвестно, какой компонент формирует итоговый ответ, диагностика быстро становится запутанной.

Сначала необходимо определить реальную цепочку доставки ресурса.

Выбран слишком тяжёлый режим динамического сжатия

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

Для часто используемых статических файлов в такой ситуации имеет смысл рассматривать предварительную компрессию или возможности CDN.

Что учитывать при внедрении Brotli

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

Нужно определить, где формируется ответ, какие ресурсы обслуживаются непосредственно веб сервером, используется ли CDN, какие MIME типы требуется сжимать, какие ответы динамические, а какие можно подготовить заранее.

После изменения конфигурации проверяют реальные HTTP ответы для основных типов страниц и файлов. Контролировать следует Accept-Encoding, Content-Encoding, работу кэша и отсутствие ошибок при загрузке ресурсов.

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