gzip

gzip: как работает сжатие данных на сайте

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

Для сайта gzip особенно полезен при передаче текстовых ресурсов. HTML, CSS, JavaScript, JSON, XML и SVG обычно хорошо поддаются такому сжатию, поскольку содержат повторяющиеся последовательности текста. Уменьшение передаваемого объёма сокращает количество данных, которое необходимо получить через сеть. Именно поэтому сжатие текстовых ресурсов относится к базовым способам оптимизации загрузки страницы.

Эта taxonomy страница Vagizov.com посвящена технологии gzip и её применению в веб инфраструктуре. Сейчас к терму не привязано опубликованных материалов, поэтому страница выполняет роль справочного хаба для будущих публикаций о настройке, диагностике и использовании gzip.

Как gzip используется в HTTP

HTTP сжатие работает через согласование возможностей клиента и сервера.

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

Для gzip типичная пара выглядит так:

Accept-Encoding: gzip

и в ответе:

Content-Encoding: gzip

После получения такого ответа браузер понимает, что тело необходимо распаковать перед обработкой. Сам тип содержимого при этом не меняется. HTML остаётся HTML, CSS остаётся CSS, а JavaScript остаётся JavaScript. Content-Encoding описывает способ представления передаваемых данных, а не их исходный MIME тип.

Зачем нужен Vary: Accept-Encoding

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

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

Это особенно важно при работе через CDN, reverse proxy и другие промежуточные уровни инфраструктуры.

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

Наибольшую практическую пользу gzip обычно даёт для текстовых ресурсов.

К ним относятся HTML документы, CSS, JavaScript, JSON, XML, обычный текст и текстовые SVG.

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

Уже сжатые форматы обрабатывать gzip обычно нецелесообразно. JPEG, WebP, AVIF, MP4, ZIP и другие форматы уже используют собственные методы сжатия. Дополнительная обработка может почти не уменьшить размер, но потребует процессорного времени. MDN отдельно рекомендует применять HTTP сжатие прежде всего к ресурсам, для которых оно действительно эффективно.

gzip и скорость загрузки сайта

gzip не делает HTML, CSS или JavaScript логически проще и не уменьшает количество ресурсов на странице.

Он решает другую задачу: сокращает размер данных, передаваемых через сеть.

Это различие важно при оптимизации производительности. Минификация удаляет лишние символы непосредственно из исходного файла. Кэширование позволяет повторно не загружать уже полученный ресурс. gzip уменьшает объём конкретной передачи между сервером и клиентом.

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

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

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

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

Самый надёжный способ проверки состоит в анализе фактически полученного HTTP ответа.

Проверка через браузер

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

Если ресурс передан через gzip, среди Response Headers будет:

Content-Encoding: gzip

В Network также можно сравнить переданный и исходный размер ресурса. Chrome описывает этот способ как стандартную проверку текстового сжатия.

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

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

Например:

curl -I -H "Accept-Encoding: gzip" https://example.com/

Если сервер применил gzip к этому ответу, среди заголовков ожидается:

Content-Encoding: gzip

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

Почему gzip может работать не для каждого файла

Решение о сжатии зависит от типа ресурса, его размера и серверной конфигурации.

Например, Nginx позволяет определить минимальный размер ответа и перечень MIME типов, для которых применяется gzip. Поэтому HTML может сжиматься, а другой ресурс при неверной конфигурации оставаться несжатым.

Диагностику стоит проводить для нескольких типов ресурсов, а не только для главного HTML документа.

gzip в Nginx

Nginx имеет отдельный модуль ngx_http_gzip_module, который сжимает HTTP ответы методом gzip. Основная директива включения выглядит так:

gzip on;

По документации Nginx по умолчанию gzip применяется к text/html. Для других типов содержимого используются дополнительные настройки, включая gzip_types.

Например, сервер может быть настроен на сжатие текстовых MIME типов, JavaScript, CSS, JSON и XML.

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

gzip_comp_level

Директива gzip_comp_level регулирует уровень сжатия в Nginx. Допустимые значения находятся в диапазоне от 1 до 9. Более высокий уровень не означает автоматически лучшую настройку для рабочего сервера, поскольку увеличение степени сжатия требует дополнительных вычислений.

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

gzip_min_length

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

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

gzip_static

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

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

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

gzip на Apache

Для Apache HTTP Server сжатие обычно реализуется средствами серверных модулей, в частности mod_deflate.

Смысл остаётся тем же: сервер определяет подходящие типы ответов, проверяет поддержку кодирования клиентом и передаёт ресурс с соответствующим Content-Encoding.

При настройке важно понимать, какой уровень инфраструктуры фактически формирует ответ. Если перед Apache находится Nginx, CDN или другой reverse proxy, сжатие может выполняться уже там.

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

gzip на WordPress

WordPress сам по себе не является оптимальным местом для решения задачи HTTP сжатия.

Chrome рекомендует для WordPress включать текстовое сжатие на уровне веб сервера.

На практике gzip может обеспечиваться Nginx, Apache, CDN, reverse proxy или инфраструктурой хостинга.

Некоторые плагины производительности предлагают переключатель сжатия, но фактическая реализация всё равно зависит от серверного окружения. Поэтому после изменения настроек важно проверять Content-Encoding, а не ориентироваться только на состояние опции в WordPress.

gzip и Brotli

gzip остаётся широко поддерживаемым способом HTTP сжатия, но это не единственный современный вариант.

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

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

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

Например, современный браузер может отправить:

Accept-Encoding: gzip, deflate, br

и получить:

Content-Encoding: br

Другой клиент может получить тот же ресурс через gzip.

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

Как правило, наличие Brotli не делает поддержку gzip бессмысленной.

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

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

gzip и файлы .gz

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

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

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

Nginx также поддерживает промежуточный вариант через gzip_static, когда заранее подготовленный .gz файл хранится на сервере и используется для HTTP ответа.

Частые ошибки при настройке gzip

Сжатие включено, но не для нужных MIME типов

Одна из наиболее распространённых ситуаций возникает, когда gzip работает для HTML, но CSS, JavaScript, JSON или другие текстовые ответы не входят в серверную конфигурацию.

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

Попытка сжимать изображения

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

Применение gzip к таким данным обычно практически бесполезно.

Проверка только по PageSpeed

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

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

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

Сайт может работать через цепочку из приложения, Apache, Nginx, reverse proxy и CDN.

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

gzip, CDN и reverse proxy

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

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

Поэтому диагностика gzip всегда должна учитывать путь фактического ответа.

Если на origin Content-Encoding отсутствует, а публичный сайт через CDN отдаёт br или gzip, это может быть полностью корректной конфигурацией.

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

gzip и безопасность

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

Документация Nginx отдельно предупреждает о классе атак BREACH при сжатии ответов в сочетании с SSL или TLS.

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

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

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

gzip и SEO

gzip относится прежде всего к производительности и серверной передаче данных.

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

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

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

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

Материалы про gzip на Vagizov.com

Страница gzip находится в каталоге продуктов и технологий Vagizov.com и предназначена для материалов, где gzip является существенной частью технической задачи.

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

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

Общие материалы о скорости сайта, кэшировании, Nginx и других элементах инфраструктуры должны сохранять собственный интент. Страница gzip остаётся узким технологическим хабом именно о формате и механизме сжатия.