Сжатие

Что такое сжатие сайта

В контексте технической оптимизации под сжатием сайта обычно понимают HTTP сжатие данных при передаче от сервера к браузеру.

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

Для текстовых ресурсов применяется сжатие без потерь. После распаковки браузер получает те же данные, которые существовали до сжатия. HTTP стандарт отдельно определяет Content-Encoding как характеристику представления, позволяющую передавать сжатые данные без изменения исходного типа содержимого.

Пользователь при этом не выполняет дополнительных действий. Согласование происходит между HTTP клиентом и сервером.

С практической точки зрения задача проста: передать те же HTML, CSS, JavaScript или JSON меньшим количеством байтов.

Что находится в текущей taxonomy Vagizov.com

На странице «Сжатие» сейчас опубликован один специализированный материал о Brotli. Он уже подробно разбирает проверку Content-Encoding: br, сравнение с gzip, настройку Nginx, работу через CDN и типичные ошибки конфигурации.

Поэтому taxonomy не должна становиться расширенной копией статьи о Brotli.

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

Рядом в разделе «Техническая оптимизация» уже существуют отдельные направления «Кэширование» и «Скорость сайта». Это позволяет сохранить понятные границы между темами.

Как работает HTTP сжатие

Механизм строится на согласовании поддерживаемого формата между клиентом и сервером.

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

Условный запрос может содержать:

Accept-Encoding: br, gzip

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

Сервер выбирает подходящий вариант и возвращает ответ, например:

Content-Encoding: br

или:

Content-Encoding: gzip

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

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

Сжатие не меняет содержимое страницы

HTTP сжатие нужно отличать от преобразования самого контента.

Если сервер сжал HTML с помощью Brotli, после распаковки браузер должен получить исходный HTML.

То же относится к CSS, JavaScript и JSON.

Поэтому корректно работающий gzip или Brotli сам по себе не меняет:

Title

H1

текст страницы

canonical

структурированные данные

ссылки

HTTP статус страницы

Сжатие меняет способ передачи представления по сети.

Именно поэтому Content-Encoding не является аналогом HTML оптимизатора или минификатора.

Какие ресурсы особенно хорошо сжимаются

Наиболее очевидные кандидаты это текстовые форматы.

Например:

HTML

CSS

JavaScript

JSON

XML

SVG

текстовые API ответы

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

Chrome Lighthouse также рассматривает текстовые ресурсы без Content-Encoding как потенциальную возможность уменьшить количество передаваемых байтов.

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

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

JPEG, WebP, AVIF, видео, аудио и архивы уже используют собственные способы сжатия.

Дополнительное HTTP сжатие таких данных обычно даёт значительно меньше пользы и при этом требует вычислительных ресурсов.

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

Поэтому настройка вида «сжимать абсолютно всё» не является оптимальной.

Лучше определить подходящие MIME types и применять HTTP compression там, где она действительно уменьшает передачу.

Сжатие изображений это другая задача

Термин «сжатие сайта» иногда смешивает два разных процесса.

Первый процесс это HTTP compression:

HTML

CSS

JavaScript

JSON

SVG

Другой процесс это оптимизация медиаконтента:

JPEG

WebP

AVIF

PNG

видео

В случае изображения может изменяться формат, качество, разрешение и количество визуальной информации.

Для HTTP текстового сжатия основная задача состоит в том, чтобы восстановить исходное содержимое без изменений.

MDN отдельно различает lossless и lossy compression. Для текстового HTTP ответа требуется восстановление исходных данных, тогда как JPEG и многие видеоформаты могут использовать сжатие с потерями.

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

gzip

gzip остаётся одним из основных способов HTTP сжатия.

Он давно поддерживается веб инфраструктурой и используется серверами, браузерами, прокси и CDN.

Клиент может сообщить о поддержке:

Accept-Encoding: gzip

а сервер ответить:

Content-Encoding: gzip

Для Nginx существует штатный модуль ngx_http_gzip_module. MDN также указывает gzip модуль Nginx как стандартный способ серверного сжатия.

Главное достоинство gzip на практике заключается не в том, что он всегда обеспечивает максимальную степень сжатия, а в зрелости и совместимости экосистемы.

Поэтому даже после внедрения Brotli gzip часто сохраняют как резервный вариант.

Brotli

Brotli является другим алгоритмом сжатия без потерь.

В HTTP для него используется обозначение:

Content-Encoding: br

MDN и HTTP инфраструктура используют br как стандартное обозначение Brotli.

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

Но выбор алгоритма нельзя делать только по принципу:

Brotli новее, значит всегда лучше.

Для динамического ответа также имеет значение стоимость сжатия на сервере.

Более тяжёлый уровень компрессии способен уменьшить количество байтов, но увеличить процессорное время.

Поэтому реальный результат нужно измерять.

Brotli уже подробно разобран отдельно

На Vagizov.com существует специализированная статья «Brotli: зачем нужно, как проверить и настроить для SEO». В ней уже рассмотрены Accept-Encoding, Content-Encoding, Nginx, предварительно сжатые файлы, CDN и сравнение gzip, Brotli и несжатого ответа.

Поэтому taxonomy «Сжатие» не должна повторять полную инструкцию настройки Brotli.

Здесь Brotli является одним из вариантов HTTP compression наряду с gzip и другими алгоритмами.

Так структура остаётся логичной: taxonomy раскрывает принцип и архитектуру, специализированная статья отвечает за конкретную технологию и её диагностику.

Zstandard

Современный HTTP также может использовать Zstandard.

Для него применяется:

Content-Encoding: zstd

MDN включает zstd в актуальный набор content encoding и связывает его с алгоритмом Zstandard, определённым RFC 8878.

Это означает, что технический аудит в 2026 году уже не стоит искусственно ограничивать только двумя строками:

gzip

br

В инфраструктуре могут встречаться и другие современные варианты.

Но сам факт существования Zstandard не означает, что его нужно обязательно включать на каждом сайте.

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

Как сервер выбирает алгоритм

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

Например:

Accept-Encoding: br, zstd, gzip

Сервер или CDN выбирает один из поддерживаемых способов в соответствии со своими возможностями и правилами согласования.

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

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

Если клиент не сообщил поддержку br, сервер должен учитывать согласование.

Правильная архитектура строится не вокруг одного жёстко заданного файла, а вокруг HTTP negotiation.

Что означает identity

identity обозначает представление без дополнительного content coding.

Иными словами, ресурс передаётся без gzip, Brotli или другого HTTP сжатия.

RFC 9110 определяет identity как значение, обозначающее отсутствие кодирования.

Этот вариант полезен при диагностике.

Можно сравнить один и тот же ресурс:

без сжатия

через gzip

через Brotli

После этого становится видно фактическую экономию передачи.

Без такого сравнения сама надпись Content-Encoding: br ещё не говорит, насколько полезна настройка для конкретного файла.

Content Encoding нужно проверять в реальном ответе

Наличие настройки в Nginx, Apache, панели хостинга или WordPress плагине не гарантирует, что именно этот вариант получает пользователь.

Между origin сервером и браузером могут находиться:

reverse proxy

CDN

балансировщик

edge cache

защитный сервис

Один из этих уровней способен изменить способ передачи ответа.

Поэтому проверять нужно публичный URL.

Этот принцип уже используется в специализированной статье Vagizov.com о Brotli: конечный HTTP ответ считается более надёжным источником фактического состояния, чем одна строка конфигурации origin сервера.

Сжатие на origin и на CDN

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

Origin может передавать уже сжатый ответ.

CDN может получить несжатый ресурс и самостоятельно сжать его для клиента.

CDN может хранить несколько вариантов.

Конкретная схема зависит от провайдера и конфигурации.

Поэтому фраза:

На Nginx включён gzip

ещё не отвечает на вопрос:

Что получает посетитель?

Проверяется конечная цепочка:

сервер

прокси

CDN

браузер

Для SEO и производительности важен фактический ответ на внешнем URL.

Vary Accept Encoding

Если один URL может возвращать разные представления в зависимости от Accept-Encoding, кеш должен понимать это различие.

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

Vary: Accept-Encoding

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

RFC 9110 также показывает ответы gzip с:

Vary: Accept-Encoding
Content-Encoding: gzip

Это не декоративный HTTP заголовок.

Он помогает промежуточному кешу не перепутать сжатую версию для клиента, который её поддерживает, и другой вариант ответа.

Сжатие и кеширование это разные механизмы

Кеширование уменьшает необходимость повторно получать ресурс.

Сжатие уменьшает размер ресурса, когда его всё таки нужно передать.

Например, браузер впервые загружает CSS.

HTTP compression уменьшает объём передачи.

При следующем посещении browser cache может вообще не потребовать повторную загрузку полного файла.

Поэтому два механизма работают совместно, но решают разные задачи.

На Vagizov.com кеширование уже выделено в отдельную taxonomy с материалами про browser cache и object cache.

Taxonomy «Сжатие» не должна повторять правила TTL, Cache-Control, object cache WordPress и другие отдельные вопросы кеширования.

Сжатие и object cache вообще относятся к разным уровням

Object cache уменьшает повторные обращения приложения к базе или другие внутренние вычисления.

HTTP compression уменьшает сетевой объём готового ответа.

Представим WordPress страницу.

PHP формирует HTML.

Object cache может помочь быстрее получить необходимые данные.

После генерации страницы HTTP сервер или CDN может сжать готовый HTML.

Это два последовательных, но независимых уровня.

Поэтому включение Redis не заменяет gzip.

И включение Brotli не ускоряет тяжёлый SQL запрос.

Сжатие и минификация

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

Минификация изменяет сам исходный ресурс.

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

HTTP compression оставляет логическое содержимое неизменным и компактно кодирует данные только для передачи.

Условно процесс может выглядеть так:

исходный JavaScript

минифицированный JavaScript

Brotli представление минифицированного файла

передача по сети

распаковка браузером

исполнение JavaScript

Поэтому наличие минифицированного .min.js не является причиной отключать HTTP сжатие.

Нужно ли минифицировать перед сжатием

Минификация способна уменьшить исходный размер ресурса.

Сжатие затем дополнительно уменьшает сетевое представление.

Но итоговый выигрыш зависит от конкретного файла.

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

Главное правило практичнее: измерять итоговый transfer size и не применять преобразования только ради галочки в оптимизаторе.

Особенно если агрессивная обработка JavaScript начинает ломать функциональность сайта.

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

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

Такой подход удобен для HTML и другого динамического содержимого.

Но компрессия требует CPU.

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

Поэтому нельзя оценивать оптимизацию только по уменьшению килобайтов.

Если ради небольшого уменьшения transfer size значительно увеличилось время формирования ответа, результат может оказаться хуже.

Особенно это актуально для слабого сервера под высокой нагрузкой.

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

Статические ресурсы можно сжать заранее.

Например, во время deployment рядом с основным JavaScript файлом создаётся предварительно подготовленное сжатое представление.

В таком сценарии серверу не нужно выполнять тяжёлое сжатие при каждом запросе.

Он выбирает уже готовый вариант в соответствии с возможностями клиента.

Такой подход особенно удобен для редко меняющихся:

CSS

JavaScript

SVG

других статических ресурсов

Специализированная статья Vagizov.com о Brotli уже разбирает работу brotli_static и предварительно подготовленных .br файлов применительно к Nginx.

Как выбирать уровень сжатия

Максимальный уровень алгоритма не означает максимальную производительность сайта.

Более плотное сжатие может потребовать больше процессорного времени.

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

Для динамического HTML она может повторяться при каждом запросе.

Поэтому выбор уровня представляет собой компромисс между:

размером ответа

временем компрессии

нагрузкой CPU

характером ресурса

частотой запросов

наличием кеша

Универсальное значение для всех сайтов невозможно рекомендовать без измерений.

Маленькие ответы

Сжатие имеет собственные накладные расходы.

Поэтому для очень маленького ответа выигрыш может быть практически незаметным.

Современные диагностические инструменты обычно не предлагают исправлять каждый крошечный текстовый ресурс.

Например, Lighthouse не помечает некоторые небольшие ответы или случаи, где потенциальная экономия слишком мала относительно исходного размера.

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

Сжатие HTML

HTML является хорошим кандидатом для HTTP compression.

Разметка содержит большое количество повторяющихся конструкций:

теги

атрибуты

классы

пробелы

повторяющиеся фрагменты шаблона

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

Поэтому gzip или Brotli можно применять и к динамически сформированному HTML.

Но важно помнить о серверной стоимости.

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

Сжатие CSS

CSS также хорошо подходит для текстового HTTP compression.

Даже минифицированный stylesheet обычно остаётся кандидатом для gzip или Brotli.

Это особенно важно для больших общих файлов темы или frontend framework.

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

После распаковки браузеру всё равно нужно разобрать полученный stylesheet.

Поэтому уменьшение transfer size не заменяет работу с реальным объёмом клиентского кода.

Сжатие JavaScript

JavaScript можно сжимать теми же HTTP механизмами.

Но здесь особенно важно понимать границу оптимизации.

Brotli уменьшает передачу файла по сети.

Он не уменьшает количество JavaScript, который браузеру нужно после распаковки:

проанализировать

скомпилировать

выполнить

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

Сжатие помогает передаче, но не заменяет code splitting, удаление ненужного кода и другие frontend оптимизации.

Сжатие JSON и API

JSON содержит много повторяющихся названий полей и текстовых конструкций, поэтому также является естественным кандидатом для HTTP compression.

Для крупного API ответа уменьшение сетевого объёма может быть существенным.

Но и здесь нельзя использовать compression как оправдание чрезмерно большого payload.

Если клиенту нужно десять полей, передача двухсот полей, сжатых Brotli, всё равно остаётся плохим контрактом.

Поэтому оптимизация API состоит из двух независимых задач:

не передавать лишние данные

сжимать подходящие данные при передаче

SVG

SVG является текстовым XML форматом.

Поэтому его можно сжимать gzip, Brotli или другим подходящим HTTP content coding.

Это отличает SVG от уже сжатых растровых изображений вроде JPEG, WebP или AVIF.

При этом сам SVG также можно оптимизировать на уровне содержимого, например убрать ненужные метаданные или лишние элементы.

Как и с CSS, эти процессы дополняют друг друга.

Шрифты

Современные web font форматы уже используют собственные механизмы компрессии.

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

Решение следует принимать по конкретному формату и измерению реальной экономии.

Общее правило остаётся прежним: уже эффективно сжатый бинарный формат обычно не является главным кандидатом для дополнительного HTTP compression.

Почему double compression бессмысленна

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

Иногда результат способен даже стать немного больше из за служебных данных нового слоя.

При этом сервер всё равно тратит процессорное время.

Поэтому идея:

включим gzip для JPEG, вдруг станет ещё меньше

обычно не имеет смысла.

MDN рекомендует исключать уже сжатые изображения, аудио и видео из общего HTTP compression.

Transfer size и исходный размер

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

Например, JavaScript после распаковки может иметь размер 400 KB.

Через Brotli по сети передаётся значительно меньше.

В DevTools эти показатели могут отображаться отдельно.

Для оценки HTTP compression важен именно сетевой объём.

Но для оценки стоимости выполнения JavaScript важен уже распакованный ресурс.

Поэтому одна цифра не описывает все аспекты производительности.

Сжатие и TTFB

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

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

В результате время до начала ответа способно измениться в противоположную сторону.

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

На Vagizov.com TTFB уже рассматривается в отдельном направлении технической оптимизации.

Taxonomy «Сжатие» должна только учитывать этот компромисс, не превращаясь в отдельное руководство по серверной производительности.

Сжатие и LCP

Уменьшение передаваемого HTML, CSS или JavaScript способно сократить сетевую работу, которая участвует в загрузке страницы.

Поэтому сжатие может косвенно помогать пользовательской производительности.

Но LCP зависит не только от text compression.

На него способны влиять:

TTFB

LCP изображение

CSS

JavaScript

шрифты

приоритет загрузки

render delay

архитектура страницы

Поэтому нельзя обещать:

включите Brotli и LCP станет хорошим

Сначала нужно измерить фактическое узкое место.

Сжатие и Core Web Vitals

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

HTTP compression можно считать одним из технических инструментов, который способен уменьшить сетевой объём и помочь производительности.

Но у Google нет правила:

gzip включён = SEO бонус

или:

Brotli используется = сайт получает более высокую позицию

Оценивать нужно реальный пользовательский результат.

Влияние сжатия на SEO

Сжатие не следует представлять самостоятельным фактором ранжирования.

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

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

Google при этом прямо рекомендует рассматривать page experience комплексно, а не оптимизировать один параметр ради поисковой системы.

Поэтому наличие:

Content-Encoding: br

не является доказательством хорошего технического SEO.

Страница всё ещё может иметь медленный сервер, огромный JavaScript bundle, тяжёлое LCP изображение или другие проблемы.

Сжатие не исправляет медленный backend

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

После этого готовые 150 KB HTML сжимаются до значительно меньшего размера.

Передача стала легче.

Но пользователь всё равно долго ждёт начало ответа.

В таком случае основное узкое место находится до этапа HTTP compression.

На Vagizov.com уже существует отдельный материал о причинах медленного сайта, где производительность рассматривается комплексно: сервер, изображения, JavaScript, кеш, база данных и другие уровни.

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

Сжатие не исправляет тяжёлое изображение

Другой сценарий:

HTML хорошо сжат.

CSS хорошо сжат.

JavaScript хорошо сжат.

Но hero изображение весит несколько мегабайт.

Основной сетевой объём находится в медиа.

Дополнительная настройка gzip уже практически не меняет ситуацию.

Тогда нужно работать с:

размером изображения

форматом

разрешением

качеством

responsive вариантом

способом загрузки

Это уже другая задача оптимизации.

Сжатие не уменьшает работу браузера после распаковки

Браузер должен распаковать ответ и затем использовать исходные данные.

Для HTML это означает parsing.

Для CSS parsing и style calculation.

Для JavaScript parsing, compilation и execution.

Поэтому хорошо сжатый JS bundle может быстро передаться по сети, но всё равно долго обрабатываться слабым мобильным устройством.

HTTP compression уменьшает transfer cost.

Она не устраняет execution cost.

Эта граница особенно важна при анализе современных JavaScript сайтов.

Как проверить сжатие через браузер

В DevTools браузера можно открыть Network и выбрать нужный ресурс.

Полезно проверить:

response headers

Content-Encoding

размер передачи

тип ресурса

время ответа

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

Content-Encoding: gzip

Если Brotli:

Content-Encoding: br

Если Zstandard:

Content-Encoding: zstd

MDN перечисляет эти варианты среди актуальных HTTP content encoding.

Но проверять нужно несколько типов ресурсов, а не только главную HTML страницу.

Что проверять кроме главной страницы

Практический аудит включает как минимум типичные ответы сайта.

Например:

HTML основной посадочной

главный CSS

крупный JavaScript bundle

JSON API ответ

SVG

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

Или наоборот.

Особенно часто различия появляются, если HTML идёт через PHP и Nginx, а CSS и JavaScript через CDN.

Поэтому результат одного URL нельзя автоматически переносить на всю инфраструктуру.

Проверка через curl

Командная строка позволяет отправить запрос с конкретным Accept-Encoding и посмотреть фактические response headers.

Именно этот метод подробно разобран в отдельной статье Vagizov.com о Brotli. Там сравниваются запросы с br, gzip и identity, а также фактический объём переданных данных.

На уровне taxonomy важнее сам принцип:

один и тот же URL проверяется при разных условиях

смотрится фактический Content-Encoding

сравнивается размер передачи

контролируется время ответа

проверяется работа кеша

Так становится понятно, приносит ли настройка реальную пользу.

PageSpeed Insights и Lighthouse

PageSpeed Insights использует полевые данные CrUX и лабораторную диагностику Lighthouse для оценки производительности страницы.

Lighthouse традиционно проверяет отсутствие сжатия у текстовых ресурсов и оценивает потенциальное уменьшение сетевого объёма. В актуальной документации Chrome указано, что отдельный audit text compression был перенесён в более новую систему диагностических insights Lighthouse 13.

Поэтому интерфейс отчёта со временем может меняться.

Сама техническая задача остаётся прежней: не передавать крупные подходящие текстовые ресурсы без эффективного сжатия.

Что означает предупреждение о text compression

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

Сначала нужно посмотреть, какие конкретно ответы не сжимаются.

Если это большой JavaScript или HTML, проблема может быть значимой.

Если это маленький технический ответ, экономия может быть минимальной.

Затем определяется уровень, который реально формирует ответ:

origin

CDN

proxy

application

После настройки повторяется проверка публичного URL.

Nginx и gzip

Nginx имеет штатный механизм gzip.

MDN прямо указывает ngx_http_gzip_module как модуль Nginx для HTTP compression.

При настройке обычно определяются:

включение gzip

подходящие MIME types

минимальный размер ответа

уровень компрессии

работа с proxy

вариативность по Accept-Encoding

Но taxonomy не должна превращаться в инструкцию по копированию одного конфигурационного блока.

Правильные значения зависят от сервера и нагрузки.

Главная проверка всегда выполняется на фактическом ответе после reload конфигурации.

Nginx и Brotli

В отличие от gzip, Brotli обычно подключается к Nginx отдельным модулем.

Специализированная статья Vagizov.com уже подробно рассматривает ngx_brotli, динамический режим и предварительно сжатые .br файлы.

Поэтому здесь достаточно понимать архитектурную разницу.

Наличие штатного gzip не означает автоматическое наличие Brotli.

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

Apache

Apache также поддерживает серверное сжатие через соответствующие модули.

Для Brotli используется mod_brotli, который сжимает output перед отправкой клиенту. Официальная документация Apache описывает его как output filter для Brotli compression.

Для gzip и deflate используются другие механизмы Apache.

Практический принцип остаётся тем же, что и для Nginx: не достаточно включить модуль, нужно проверить конечный HTTP ответ.

WordPress и плагины оптимизации

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

Иногда gzip уже настроен на Nginx.

Иногда compression выполняет CDN.

Иногда хостинг управляет этой функцией на уровне панели.

Поэтому установка ещё одного WordPress оптимизатора не обязательно добавляет новый эффект.

Более того, приложение не всегда является оптимальным местом для выполнения HTTP compression.

Эту задачу часто эффективнее решает веб сервер или CDN.

Сначала нужно проверить текущее состояние, а потом выбирать инструмент.

Почему две настройки сжатия могут конфликтовать

Если compression одновременно пытаются контролировать несколько слоёв, диагностика усложняется.

Например:

WordPress плагин

Nginx

reverse proxy

CDN

Каждый компонент способен иметь собственные правила.

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

Поэтому желательно иметь понятную архитектуру ответственности.

Нужно знать, какой уровень выбирает конечный Content-Encoding.

Повторное сжатие ответа

Повторное HTTP сжатие уже сжатого представления обычно не даёт полезного результата.

В худшем случае появляется дополнительная вычислительная работа или проблемы совместимости.

Если origin уже отдаёт gzip, CDN должен корректно понимать существующий encoding и собственную политику обработки.

Нельзя просто накладывать дополнительные кодирования без понимания HTTP цепочки.

RFC допускает несколько content coding и требует перечислять их в порядке применения, но это техническая возможность, а не рекомендация многократно сжимать веб страницу.

Для обычного сайта нужен один подходящий эффективный вариант передачи.

Сжатие и HTTPS

HTTPS шифрует соединение.

HTTP compression уменьшает размер содержимого.

Это разные уровни.

Сначала представление может быть сжато, затем данные передаются внутри защищённого соединения.

Поэтому HTTPS не делает gzip или Brotli ненужными.

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

Для обычного технического SEO это не означает необходимость отключить compression на всём HTTPS сайте.

Но чувствительные ответы с секретами требуют отдельной security оценки.

Почему безопасность тоже имеет значение

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

Особенно внимательно нужно относиться к ответам, в которых одновременно присутствуют:

секретные значения

контролируемый атакующим ввод

наблюдаемый размер ответа

Современные руководства по HTTP compression отдельно упоминают атаки BREACH и CRIME как класс рисков, связанных с компрессией зашифрованного трафика.

Для обычной публичной HTML страницы это не причина отказаться от gzip или Brotli.

Для чувствительных сценариев нужна отдельная модель угроз.

Что измерять до и после настройки

Перед изменением полезно сохранить исходное состояние.

Например:

какой Content-Encoding используется

сколько байтов передаётся

каков размер исходного ресурса

каково время ответа

где выполняется compression

какая нагрузка на сервер

После изменения выполняются те же проверки.

Так можно ответить на реальные вопросы:

уменьшилась ли передача

не вырос ли TTFB

не появились ли ошибки кеша

получают ли клиенты совместимый вариант

сохранилось ли корректное содержимое

Без сравнения настройка остаётся просто технической галочкой.

Почему нельзя оценивать результат только процентом сжатия

Предположим, один алгоритм уменьшает файл немного сильнее другого.

Но для динамического HTML он требует значительно больше CPU.

На слабом сервере общий пользовательский результат может оказаться хуже.

Другой пример: CSS удалось уменьшить ещё на несколько килобайт, но LCP страницы определяется тяжёлой фотографией.

В обоих случаях процент compression сам по себе мало что говорит.

Поэтому правильная метрика зависит от исходной проблемы.

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

Когда gzip уже достаточно

Нет требования заменять рабочий gzip только ради более современного названия алгоритма.

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

Техническое SEO всегда работает с ограниченными ресурсами.

Исправление критической ошибки индексирования обычно важнее перехода с одного уже работающего алгоритма compression на другой ради небольшого выигрыша.

Поэтому сначала проводится измерение.

Когда Brotli имеет смысл

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

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

Для динамического HTML нужно дополнительно учитывать CPU и время ответа.

Подробные практические проверки уже разобраны в существующей статье Vagizov.com о Brotli.

Когда имеет смысл Zstandard

Zstandard стоит рассматривать как ещё один современный HTTP content coding в инфраструктуре, где его поддерживают клиенты, сервер или CDN.

Но внедрение должно решать реальную задачу.

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

Полезнее сравнить:

реальный transfer size

стоимость компрессии

поддержку edge инфраструктуры

fallback

сложность эксплуатации

Для простого сайта правильно работающих Brotli и gzip может быть достаточно.

Ошибка: включить максимальное сжатие без измерений

Название уровня compression легко создаёт ложную цель:

если 11 максимум, нужно поставить 11

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

Для статической сборки это может быть приемлемо.

Для динамической страницы под высокой нагрузкой нет.

Поэтому максимальный уровень алгоритма не является автоматически оптимальным уровнем сайта.

Специализированная статья Vagizov.com о Brotli отдельно предупреждает против максимального динамического уровня без замеров.

Ошибка: сжимать уже сжатые форматы

Повторное gzip сжатие JPEG, WebP, ZIP или видео обычно не является полезной оптимизацией.

MDN прямо рекомендует исключать уже сжатые форматы из общего механизма HTTP compression.

Правильнее направить ресурсы сервера на HTML, CSS, JavaScript, JSON, SVG и другие форматы, где эффект действительно заметен.

Ошибка: проверить только конфигурацию

Файл nginx.conf может содержать идеальные директивы.

Но пользователь получает ответ от CDN.

Или другой server block.

Или proxy меняет заголовок.

Поэтому конфигурация является только предполагаемым состоянием.

Истиной для пользователя остаётся фактический HTTP response.

Именно поэтому проверка публичного URL обязательна после каждого изменения.

Ошибка: забыть про кеш

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

Для этого используется Vary: Accept-Encoding.

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

Поэтому compression и cache negotiation необходимо проверять совместно.

Ошибка: считать Brotli отдельным SEO фактором

Brotli не является кнопкой роста позиций.

Google рекомендует хорошую page experience в целом и отдельно отмечает, что даже хорошие Core Web Vitals не гарантируют верхних позиций.

Следовательно, правильная формулировка звучит так:

сжатие может уменьшить сетевой объём

меньший сетевой объём может помочь производительности

производительность является частью пользовательского опыта

но один Content-Encoding не определяет ранжирование

Это значительно точнее обещания «включите Brotli для SEO».

Ошибка: пытаться ускорить весь сайт одной настройкой

Производительность сайта состоит из нескольких этапов.

Сервер должен сформировать ответ.

Сеть должна его передать.

Браузер должен загрузить дополнительные ресурсы.

Затем разобрать и выполнить код.

После этого отрисовать страницу.

HTTP compression оптимизирует прежде всего сетевую передачу подходящих ресурсов.

Если проблема находится на другом этапе, эффект будет ограниченным.

Именно поэтому родительский раздел Vagizov.com отдельно содержит темы TTFB, Speed Index, кэширование, скорость сайта и JavaScript SEO.

Практическая последовательность проверки

Сначала нужно определить крупные текстовые ресурсы страницы.

Затем проверить их Content-Encoding.

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

Далее определить, кто выполняет compression: origin или CDN.

Затем проверить Vary: Accept-Encoding и работу кеша.

После изменения необходимо повторно измерить размер и время ответа.

И только после этого можно оценивать пользу настройки.

Такой подход лучше, чем установка нового модуля только потому, что диагностический сервис показал одно предупреждение.

Что считать хорошим результатом

Хорошая настройка сжатия не определяется названием алгоритма.

Она должна обеспечивать несколько свойств одновременно.

Подходящие текстовые ресурсы передаются в сжатом виде.

Клиент получает поддерживаемый им формат.

Несжатые и сжатые варианты корректно взаимодействуют с кешем.

Уже сжатые медиа не обрабатываются без необходимости.

Нагрузка сервера остаётся приемлемой.

Фактический transfer size уменьшается.

Функциональность сайта не меняется.

Именно совокупность этих условий показывает, что HTTP compression настроена правильно.