Сжатие Gzip в Nginx: Ускорьте загрузку вашего сайта

Сжатие Gzip в Nginx помогает вашему сайту загружаться быстрее, уменьшая размер текстовых ответов перед их передачей по сети. Если ваши страницы содержат HTML, CSS, JavaScript, JSON, XML или SVG-файлы, сжатие может сократить объем передаваемых данных без изменения того, что видит пользователь в браузере.

Цель проста: отправлять меньше байтов, сократить время ожидания и эффективнее использовать пропускную способность. Для большинства production-сайтов Gzip — одно из самых простых и безопасных улучшений производительности Nginx.

Как работает сжатие Gzip в Nginx

Сжатие Gzip происходит после того, как Nginx выбрал ответ, но до того, как отправил его клиенту. Браузер сообщает о поддержке сжатия через заголовок запроса Accept-Encoding. Если Gzip включен и тип ответа соответствует вашей конфигурации, Nginx сжимает тело ответа и отправляет его с заголовком Content-Encoding: gzip.

Это лучше всего работает для текстовых форматов, так как они содержат повторяющиеся шаблоны. HTML-шаблоны, CSS-классы, идентификаторы JavaScript и ключи JSON часто хорошо сжимаются. Изображения, видео, PDF и архивы обычно уже сжаты, поэтому попытка сжать их с помощью gzip может только потратить ресурсы CPU без значительного уменьшения размера.

Базовая конфигурация обычно размещается в блоке http, чтобы применяться ко всем серверным блокам:

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_vary on;
gzip_proxied any;
gzip_types
    text/plain
    text/css
    text/xml
    application/json
    application/javascript
    application/xml
    application/rss+xml
    image/svg+xml;

Директива gzip on включает сжатие. gzip_types указывает Nginx, какие MIME-типы сжимать в дополнение к стандартному text/html. gzip_min_length позволяет не тратить CPU на маленькие ответы, где накладные расходы заголовка Gzip могут свести на нет выгоду.

gzip_vary on добавляет заголовок Vary: Accept-Encoding. Это важно, если ваш сайт работает через CDN или общий кеш, так как кешам нужно знать, что сжатая и несжатая версии — это разные варианты одного и того же URL.

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

Одна деталь, которая часто сбивает с толку: Nginx всегда сжимает text/html, когда Gzip включен, поэтому text/html не нужно указывать в gzip_types. Если вы все же добавите его, Nginx может предупредить, что MIME-тип дублируется. Это предупреждение безвредно, но оно указывает на то, что конфигурация была скопирована без очистки.

Выбор безопасных настроек сжатия

Самая большая ошибка при настройке сжатия Gzip в Nginx — это воспринимать уровень сжатия как регулятор громкости. Более высокий уровень не всегда лучше. Уровни Gzip обычно варьируются от 1 до 9. Уровень 1 самый быстрый, но сжимает меньше. Уровень 9 сжимает больше, но может значительно увеличить нагрузку на CPU.

Для большинства веб-сайтов gzip_comp_level 4, 5 или 6 — это практичный диапазон. Он обеспечивает хорошее сжатие без чрезмерной нагрузки на сервер. Если ваш сервер Nginx обрабатывает большой трафик или работает на небольшом экземпляре, избегайте сразу переходить на уровень 9.

Хорошие настройки по умолчанию выглядят так:

• Используйте gzip_comp_level 5 для сбалансированной конфигурации.
• Используйте gzip_min_length 1024, чтобы маленькие ответы пропускали сжатие.
• Сжимайте текстовые ресурсы, а не уже сжатые медиафайлы.
• Оставляйте gzip_vary on, если используются кеши или CDN.
• Проверяйте загрузку CPU после включения сжатия.

Вот распространенный сценарий. У вас есть сайт документации с множеством CSS, JavaScript и HTML-страниц. До Gzip страница загружает 650 КБ текстовых ресурсов. После включения сжатия объем передаваемых данных может резко уменьшиться, при этом браузер все равно получит те же файлы после декомпрессии. Пользователи с медленным соединением почувствуют улучшение больше всего.

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

Для API будьте более осмотрительны. Сжатие крошечного JSON-ответа, такого как {"ok":true}, обычно бессмысленно. Сжатие результата поиска размером 300 КБ или полезной нагрузки отчета может быть оправдано. Если ваш API возвращает приватные данные и отражает вводимые пользователем данные в том же ответе, обсудите риски сжатия с командой разработки приложения, прежде чем включать его везде. Это не означает "никогда не сжимайте API". Это означает, что сжатие должно рассматриваться в том же контексте, что и кеширование, куки и заголовки ответов.

Как проверить, что Gzip работает

После изменения конфигурации Nginx проверьте синтаксис перед перезагрузкой:

nginx -t

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

Вы можете проверить ответ с помощью curl:

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

Ищите этот заголовок:

Content-Encoding: gzip

Также проверьте наличие:

Vary: Accept-Encoding

Если вы не видите Content-Encoding: gzip, проверьте MIME-тип ответа. Например, JavaScript-файл, отдаваемый как text/plain, все равно может сжиматься, если text/plain включен в список, но пользовательский API-ответ с необычным типом контента может не соответствовать вашему списку gzip_types.

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

Если вы также используете CDN, помните, что CDN может выполнять собственное сжатие. В этом случае Nginx может не быть последним слоем, определяющим, что получит браузер. По возможности тестируйте как прямой доступ к источнику, так и публичный URL CDN.

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

Когда следует быть осторожным с Gzip

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

Не сжимайте файлы, которые уже сжаты. Распространенные примеры:

• .jpg, .jpeg, .png и .webp
• .mp4, .mov и другие видеоформаты
• .zip, .gz, .tar.gz и архивные пакеты
• Большинство файлов шрифтов, в зависимости от формата и способа доставки

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

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

Для статических ресурсов есть еще один вариант: предварительно сжимать файлы во время сборки и отдавать .gz-версии с диска. Это может снизить нагрузку на CPU во время выполнения, особенно для больших JavaScript-бандлов. Динамические API-ответы все равно требуют сжатия во время выполнения, если вы хотите их сжимать.

Если вы отдаете предварительно сжатые файлы, включите gzip_static on; и убедитесь, что .gz-файл создан из той же версии ресурса, что и несжатый файл. Устаревший app.js.gz рядом с новым app.js — это неприятная ошибка: только клиенты, запрашивающие Gzip, увидят старый код.

gzip_static on;

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

Когда обращаться за помощью

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

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

Сжатие Gzip в Nginx — это практичный способ ускорить загрузку для сайтов и API с большим количеством текста. Сосредоточьтесь на MIME-типах, выберите умеренный уровень сжатия и проверьте заголовки после перезагрузки. Как только все заработает, пользователи будут получать меньшие ответы, а ваш код приложения останется неизменным.