Gzip / Brotli

Gzip и Brotli — алгоритмы сжатия, которые сервер применяет к текстовым ответам (HTML, CSS, JS, JSON) перед отправкой браузеру. Brotli современнее и эффективнее: сжимает на 15–25% лучше Gzip при сопоставимой нагрузке на CPU.

Сжатие включается на стороне сервера (Nginx, Apache) или на CDN. Эффект на скорость загрузки — минус 30–60% к размеру ответа, заметно ускоряет TTFB и LCP.

Включить — стандарт хорошего хостинга. Картинки и видео сжатие не трогает (они уже сжаты), а вот HTML и JS режутся хорошо.

styles.css        180 КБ
+ gzip (level 6)   38 КБ   ×4.7
+ brotli (level 6) 29 КБ   ×6.2
+ brotli (level 11) 24 КБ   ×7.5

// nginx: gzip on; brotli on; brotli_comp_level 6;
// Brotli лучше gzip на 20–30% для HTML/CSS/JS

У Brotli есть уровни сжатия 0–11, у Gzip — 1–9, и это место, где легко выстрелить себе в ногу. Brotli 11 даёт максимальную экономию, но и максимально грузит CPU — для динамического HTML, который генерируется на каждый запрос, ставят уровень 4–6, иначе растёт TTFB вместо того чтобы падать. А вот статику (CSS, JS, шрифты .woff2 уже сжаты, их не трогаем) выгодно сжать заранее Brotli 11 и отдавать готовые .br-файлы — тогда дорогое сжатие выполняется один раз при сборке, а не на каждый хит.

Проверить, что сжатие реально работает, можно в DevTools на вкладке Network: в заголовках ответа должно стоять Content-Encoding: br (или gzip). Частая ошибка — Brotli включён в Nginx, но не указан в списке brotli_types, и весь JSON/SVG уходит несжатым. Браузер сам сообщает серверу о поддержке через Accept-Encoding, поэтому держать оба алгоритма нормально: старые клиенты и часть прокси получат Gzip, остальные — Brotli. На скорость это бьёт напрямую через LCP и в целом по Core Web Vitals, особенно на мобильном с медленным каналом.