Представьте интернет-магазин, который при каждом открытии карточки товара отправляет покупателю не только сам товар, но ещё несколько пачек служебных документов. Покупателю эти бумаги нужны, но ему совершенно безразлично, насколько объёмную коробку использовал магазин.
Примерно эту проблему и решает сжатие Gzip. Браузер всё равно получает исходный HTML, стили и JavaScript, но по сети они едут в более компактном виде.
Для бизнеса смысл довольно приземлённый: не заставлять клиента скачивать лишние килобайты только потому, что сервер умеет быть расточительным.
Что именно делает сжатие Gzip
HTML, CSS, JavaScript и JSON состоят из текста, где одни и те же конструкции повторяются снова и снова. Названия HTML-тегов, CSS-свойств, классов, фрагменты JavaScript — для алгоритма сжатия это множество повторяющихся шаблонов.
Gzip находит такие повторения и кодирует их компактнее. По данным web.dev, для крупных текстовых ресурсов Gzip и Brotli способны уменьшать передаваемый объём на десятки процентов, в удачных случаях — примерно на 70–90%. Конкретная экономия зависит от содержимого файла.
То есть условные 600 КБ текстовых ресурсов могут превратиться, например, в 180 КБ. Это не обещание для любого сайта, а понятная модель: вместо 600 КБ клиенту нужно передать 180 КБ, а оставшиеся 420 КБ вообще не едут по сети.
С фотографиями такой трюк почти бессмысленен. JPEG, WebP, PNG, видео и архивы уже сжаты своими алгоритмами. Пытаться дополнительно «утрамбовать» их Gzip — примерно как пытаться вакуумировать уже запаянную вакуумную упаковку: работы добавили, места почти не выиграли.

Технически разговор занимает два HTTP-заголовка. Браузер сообщает серверу, какие варианты понимает:
Accept-Encoding: gzip, br
А сервер отвечает, чем именно упаковал содержимое:
Content-Encoding: gzip
Браузер распаковывает ответ автоматически. Посетителю не нужно устанавливать расширение, нажимать кнопку или вообще знать о существовании Gzip. Именно поэтому правильно настроенное сжатие для пользователя практически незаметно — заметно его отсутствие.
При использовании разных вариантов представления серверу также важно корректно работать с Vary: Accept-Encoding, чтобы промежуточные кеши различали сжатые и несжатые ответы.
Где здесь SEO, а где начинается маркетинговая магия
В выдаче по теме Gzip регулярно встречается простая формула: «включили сжатие → сайт быстрее → позиции выше». Последний переход в этой цепочке слишком смелый.
Google прямо пишет, что его системы учитывают различные аспекты удобства страницы, включая Core Web Vitals, но хорошие показатели этих метрик не гарантируют высоких позиций. Релевантность и качество самого содержания никуда не исчезают.
Яндекс, в свою очередь, прямо включает настройку Gzip-сжатия в рекомендации по ускорению сайта. Но и здесь речь идёт именно об улучшении производительности, а не о волшебном переключателе ранжирования.
Поэтому нормальная бизнес-логика выглядит так:
Gzip → меньше передаваемых данных → потенциально быстрее получение нужных ресурсов → лучше фактическая производительность страницы.
А вот стрелку Gzip → ТОП-3 лучше оставить продавцам чудес.
Возьмём простой пример. У интернет-магазина первый экран карточки товара зависит от HTML, CSS и JavaScript. Если суммарно браузеру приходится получить 600 КБ сжимаемого текста, а после настройки передачи остаётся 200 КБ, пользователь на слабой мобильной сети получает на 400 КБ меньше данных.
Это уже реальный результат. Но если главным тормозом страницы остаётся фотография товара на 4 МБ, включение Gzip не спасёт ситуацию. Мы просто очень эффективно сжали небольшую часть груза, оставив слона сидеть в кузове.
Поэтому при комплексном SEO-продвижении сайта Gzip имеет смысл рассматривать как один пункт технической диагностики вместе с серверным ответом, изображениями, кешированием, JavaScript и реальными Core Web Vitals, а не как самостоятельную стратегию продвижения.
Как проверить сжатие Gzip без гадания
Самая надёжная проверка — посмотреть, что действительно получил браузер, а не что отмечено галочкой в панели хостинга.
В Chrome можно открыть инструменты разработчика, перейти в Network, выбрать HTML-документ, CSS или JavaScript и посмотреть Response Headers. Если там есть:
Content-Encoding: gzip
Gzip работает для этого ответа.
Если вместо него вы видите:
Content-Encoding: br
сжатие тоже работает — просто сервер и браузер договорились использовать Brotli. Это не ситуация «Gzip сломался», а более современный вариант передачи. Chrome рекомендует использовать Brotli при наличии поддержки, а Gzip оставлять совместимым резервным вариантом.
Для разработчика тот же тест можно сделать одним запросом:
curl -I -H "Accept-Encoding: gzip" https://example.com/
Смотреть нужно опять же на фактический Content-Encoding.
Проверять стоит не только главную. Возьмите хотя бы HTML страницы, основной CSS, JavaScript и крупный JSON-ответ, если сайт активно загружает данные через API.

В актуальном Lighthouse отдельный старый аудит Enable text compression уже перенесён в более общий диагностический блок, поэтому искать именно такое название рекомендации в каждом новом отчёте не нужно. При этом сам принцип не изменился: инструмент анализирует текстовые ответы и потенциальную экономию от сжатия.
Как настроить Gzip и не превратить задачу в недельный проект
Для владельца бизнеса главный вопрос звучит не «какую директиву написать», а на каком уровне сейчас раздаётся сайт.
Сжатие может включать:
- веб-сервер Nginx или Apache;
- панель хостинга;
- CDN или reverse proxy;
- серверная платформа;
- реже — приложение или WordPress-плагин.
Поэтому установка ещё одного плагина WordPress «для ускорения» без проверки инфраструктуры напоминает покупку второго дверного звонка, когда проблема была в отключённом электричестве.
На Nginx базовая конфигурация может выглядеть так:
gzip on;
gzip_vary on;
gzip_types
text/plain
text/css
application/javascript
application/json
application/xml
image/svg+xml;
Официальная документация Nginx подтверждает, что модуль ngx_http_gzip_module сжимает ответы методом Gzip, а список дополнительных MIME-типов задаётся через gzip_types. HTML обрабатывается отдельно и не требует добавления в этот список.
Для Apache используется модуль mod_deflate, например:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/css
AddOutputFilterByType DEFLATE application/javascript application/json application/xml
AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>
Конкретную конфигурацию всё равно нужно согласовать с сервером и хостингом, а не копировать вслепую.
Если сервер уже отдаёт br, необязательно возвращать его на Gzip ради красивой галочки. В соседней теме техническое SEO — сжатие Brotli стоит рассматривать именно как альтернативный способ уменьшения текстовых ответов, а не как совершенно другую задачу.
Пять ошибок, которые встречаются чаще отсутствующего Gzip
| Ошибка | Что происходит на практике |
|---|---|
| Пытаются Gzip-сжимать JPEG, WebP и видео | Сервер тратит работу, а объём почти не уменьшается |
| Проверяют настройку плагина, а не HTTP-ответ | В панели всё «включено», но CDN или сервер фактически отдаёт другое |
Видят br и считают, что Gzip сломан | На самом деле браузер получил сжатую Brotli-версию |
| Сжимают HTML, но забывают CSS, JS или JSON | Основной объём текстовых данных всё ещё передаётся без компрессии |
| Ставят максимальный уровень Gzip «потому что 9 лучше 5» | Дополнительная нагрузка на CPU может оказаться дороже небольшой экономии трафика |
У Nginx действительно есть уровни Gzip от 1 до 9, но число 9 не означает «правильное SEO». Это просто баланс между степенью компрессии и вычислительной работой сервера.

Как понять, что задачу можно закрывать
Нормальный результат выглядит скучно — и это хорошо.
HTML, CSS, JavaScript и другие крупные текстовые ответы передаются с Content-Encoding: gzip, br или другим поддерживаемым алгоритмом. Изображения и видео не пытаются бессмысленно пережимать Gzip. Страница после изменения работает так же, как до него. Повторная проверка показывает уменьшенный объём передачи.
Дальше имеет смысл смотреть уже не на сам факт наличия Gzip, а на результат для бизнеса: стал ли легче первый визит, уменьшился ли сетевой объём, улучшились ли реальные показатели загрузки и не остались ли более крупные проблемы — тяжёлые изображения, сторонние скрипты, медленный сервер или неудачная загрузка первого экрана.
Gzip в этом смысле похож на хорошую упаковку товара. Покупатель не обязан восхищаться коробкой. Он просто должен получить заказ быстрее и без лишнего груза.
FAQ
Когда Gzip действительно помогает сайту, а когда проблема в другом
Это упаковка текстовых данных перед передачей по сети. Сервер отправляет браузеру более компактную версию HTML, CSS, JavaScript или JSON, а браузер автоматически распаковывает её. Пользователь не видит разницы в содержимом страницы, но скачивает меньше данных.
Отдельного подтверждённого сигнала ранжирования «на сайте включён Gzip» нет. Сжатие относится к оптимизации производительности: меньший объём передаваемых данных способен ускорить загрузку, а Google учитывает сигналы удобства страницы, включая Core Web Vitals. При этом хорошие показатели скорости сами по себе не гарантируют высоких позиций.
Проверьте заголовок ответа у HTML и текстовых ресурсов. Content-Encoding: gzip означает использование Gzip, а Content-Encoding: br — что сервер выбрал Brotli. Отсутствие слова gzip при наличии br не является ошибкой.
Обычно нет. Эти форматы уже используют собственное сжатие, поэтому повторное Gzip-сжатие часто практически ничего не экономит и иногда даже увеличивает объём. Основная зона применения Gzip — текстовые ресурсы.
Если инфраструктура поддерживает Brotli, сервер может отдавать его современным браузерам, оставляя Gzip как совместимый резервный вариант. Главное для владельца сайта — не название алгоритма, а фактически уменьшенный объём передачи и отсутствие ошибок при выдаче ресурсов.
Рейтинг статьи
Материал был полезен?
Оценка помогает понимать, какие материалы стоит обновлять и расширять.


