Что сжимать и чем

Если помнишь, что gzip_types по умолчанию покрывает один тип, - листай до «Теперь сам».

Сначала ответь сам

В конфиге написано ровно gzip on;. Что сожмётся из этого списка: HTML-страница, app.js, data.json, photo.jpg?

Замер на стенде, размер ответа при Accept-Encoding: gzip:

for f in data.json app.js photo.jpg; do printf '%-12s ' $f; curl -s -H 'Accept-Encoding: gzip' -o /dev/null -w '%{size_download}\n' http://shop.local/$f; done

data.json    120391
app.js        78000
photo.jpg   2000000

Только HTML. gzip_types по умолчанию содержит один тип - text/html, - и это единственное, что жмётся из коробки. Добавляем типы:

data.json     2204   (было 120391)
app.js         526   (было 78000)

На что это похоже

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

Текст - это свитер: в нём полно повторов. JPEG, видео и woff2 - кирпичи, внутри уже сжатые своим алгоритмом.

Механизм: договор через два заголовка

Правило

gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 1k;
gzip_types text/css text/plain text/xml application/javascript application/json
           application/xml image/svg+xml application/wasm;

text/html в список писать не нужно - он сжимается всегда. И смотри на content-type из ответа: application/javascript и text/javascript - разные строки, и если бэкенд отдаёт вторую, а в конфиге первая, сжатия не будет.

Разбор: почему не девятка

gzip_comp_level принимает от 1 до 9, по умолчанию 1. Замер на 300 КБ реального текста, лучшее время из семи прогонов:

Переход с 1 на 5 стоит удвоения времени и даёт минус четверть байт - выгодно. Переход с 5 на 9 стоит втрое большего времени, а размер режет всего с 28% до 27% от оригинала - то есть примерно на 6% относительно уже сжатого (85 355 → 79 704). На лету это не окупается. Отсюда и рабочий диапазон 4-6.

Разбор: как не платить процессором вовсе

gzip_static on;

nginx поищет рядом с app.js готовый app.js.gz и отдаст его как есть. Замер: файл, сжатый gzip -9 при сборке, весит 262 байта, и отдаётся он без единого такта на сжатие:

Content-Length: 262
Content-Encoding: gzip

Готовый .gz кладут рядом с файлом при сборке: gzip -9 -k app.js создаёт app.js.gz, не удаляя оригинал (-k). Файл готовится один раз при сборке фронтенда - там можно спокойно жать девятым уровнем, это уже не стоит времени запроса. Так делают для всей неизменяемой статики с хешем в имени.

Что ломается без этого

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

Пропадает Content-Length. Сжатый ответ едет как Transfer-Encoding: chunked - размер заранее неизвестен. Отсюда две вещи, которые ты уже видел: докачка по Range на сжатых типах не работает вовсе (пятый раздел), а ETag становится слабым (W/"...").

Поток задерживается. Сжатие обязано накопить данные, прежде чем их сжать, - именно оно, а не буферизация, копит потоковый ответ (седьмой раздел). На маршруте с событиями gzip off; ставят осознанно.

Зачем это в работе

Brotli на текстовых файлах даёт примерно на 15-20% меньше байт, чем gzip, и поддерживается всеми браузерами больше пяти лет. Zstd жмёт быстрее при похожем результате.

Важная деталь: в стандартной сборке nginx их нет. gzip - штатный модуль, а brotli и zstd - внешние: ngx_brotli собирается как динамический модуль (в популярных дистрибутивах есть готовые пакеты), zstd - только сторонние сборки. Поэтому строка brotli on; в чужом конфиге - не признак свежей версии, а признак того, что у человека собран модуль; на голом nginx:stable такой конфиг просто не запустится.

Порядок внедрения: gzip первым, он бесплатен и работает везде; gzip_static вторым, он снимает нагрузку; brotli третьим, когда готов собирать модуль и поддерживать его при обновлениях.

Теперь сам

На сайте включили gzip on; gzip_comp_level 9; и добавили все типы. Через неделю мониторинг показывает рост $request_time на страницах каталога при неизменном $upstream_response_time. Что произошло и что делать?