Стандартная история: включают gzip on, радуются, потом кто-то замечает, что JSON-ответы API приходят несжатыми. Причина почти всегда в одном: gzip_types по умолчанию содержит только text/html.
Что настроить в первую очередь
gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 512;
gzip_proxied any;
gzip_types
text/css
text/plain
text/xml
application/json
application/javascript
application/xml
image/svg+xml;
gzip_comp_level 5 вместо дефолтной единицы — это разница между 12% и 45% экономии для JSON при почти нулевой разнице в процессорном времени. Девятка даёт ещё пару процентов и втрое больше CPU; на маленьком сервере это плохая сделка.
gzip_vary on обязателен, если перед nginx стоит кэширующий прокси: без него кэш отдаст сжатый ответ клиенту, который его не понимает.
Brotli
Если nginx собран с ngx_brotli, картина такая: brotli выигрывает у gzip на тексте примерно 15–20%, но статику надо сжимать заранее, а не на лету.
brotli on;
brotli_comp_level 6;
brotli_static on;
brotli_types text/css application/javascript application/json image/svg+xml;
brotli_static on заставляет nginx искать готовый .br рядом с файлом. Это единственный вариант, где brotli не стоит ничего.
О чём забывают
Не сжимать уже сжатое. JPEG, PNG, WOFF2, MP4 — они уже упакованы; попытка их gzip-нуть тратит процессор и иногда увеличивает размер.
Не сжимать ответы, которые отдаёт приложение потоком. Стриминговые события (SSE, длинные выгрузки) при сжатии буферизуются, и «поток» превращается в «приходит в конце». Лечится gzip off; для конкретного location.
Проверять надо не на глаз. Одна команда отвечает на все вопросы:
curl -sI -H 'Accept-Encoding: gzip, br' https://example.com/api/items \
| grep -iE 'content-encoding|content-length|vary'
Если content-encoding пуст, а content-length равен несжатому размеру — сжатие не включилось, и весь ваш конфиг выше работает вхолостую.
И самое неочевидное: экономия от сжатия заметна на медленном канале и почти не заметна на быстром. Прежде чем оптимизировать, стоит измерить, что вообще является узким местом.