Проверка сжатия

Проверка gzip и Brotli: как читать результат

Инструмент дважды запрашивает указанный адрес. Первый раз — как браузер, который готов принять сжатый ответ: в заголовке Accept-Encoding перечислены поддерживаемые алгоритмы, и сервер выбирает один. Второй раз — с Accept-Encoding: identity, то есть без сжатия. Сравнение двух ответов даёт три цифры: размер без сжатия, размер, переданный по сети, и процент экономии.

• Метка алгоритма (GZIP, Brotli или Deflate) — то, что сервер записал в Content-Encoding. Подсвечивается один алгоритм: сервер всегда отдаёт ответ одним способом. Если поддерживаются и gzip, и Brotli, современный сервер выберет Brotli, и метка gzip останется серой — это не ошибка.
• Экономия. Для HTML нормальны 70–90%. Если сжатие включено, а экономия меньше 30%, вероятно, страница почти пустая или сжимается слабым уровнем.
• Метки не горят, но «со сжатием» заметно меньше «без сжатия». Скорее всего, сервер ответил алгоритмом zstd — отдельной метки для него нет. Так делает, например, Cloudflare. Проверьте заголовок через curl (команды ниже).

Проверяется только документ по указанному адресу. Чтобы убедиться, что сжимаются CSS, JS и SVG, введите прямую ссылку на файл.

Gzip, Brotli и zstd: в чём разница

Сжимать нужно текстовые форматы: HTML, CSS, JS, JSON, XML, SVG, шрифты TTF/OTF. JPEG, PNG, WebP, AVIF, MP4 и WOFF2 уже сжаты — повторное сжатие тратит процессор и почти ничего не даёт.

Как включить сжатие

nginx: gzip

gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_vary on;
gzip_proxied any;
gzip_types text/css application/javascript application/json
           application/xml image/svg+xml font/ttf font/otf;

text/html перечислять не нужно — он сжимается всегда. gzip_vary on добавляет Vary: Accept-Encoding, чтобы прокси и CDN не отдали сжатую версию клиенту, который её не понимает.

nginx: Brotli

Brotli нет в стандартной сборке nginx — нужен модуль ngx_brotli. В ряде дистрибутивов он есть готовым пакетом, иначе его собирают как динамический модуль под вашу версию nginx.

load_module modules/ngx_http_brotli_filter_module.so;
load_module modules/ngx_http_brotli_static_module.so;

brotli on;
brotli_comp_level 5;
brotli_static on;
brotli_types text/css application/javascript application/json
             application/xml image/svg+xml font/ttf font/otf;

brotli_static on отдаёт заранее подготовленные файлы .br (например, app.js.br, сжатые на уровне 11 при сборке), а динамический HTML сжимается на лету на уровне 4–6 — так нет лишней нагрузки на процессор. Оставьте и gzip: он нужен клиентам без Brotli.

Apache и .htaccess

<IfModule mod_brotli.c>
  AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript application/json image/svg+xml
</IfModule>
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json image/svg+xml
</IfModule>

mod_brotli есть в Apache 2.4.26 и новее. Несмотря на название, mod_deflate отдаёт gzip. На виртуальном хостинге модули иногда отключены — тогда сжатие включают в панели хостинга или просят поддержку.

Cloudflare и другие CDN

Cloudflare сам сжимает текстовые ответы для посетителей (gzip, Brotli, zstd); тонкая настройка — в Compression Rules. Учтите, что проверка показывает ответ CDN, а не вашего сервера: соединение «сервер → CDN» может оставаться несжатым. На сайт это почти не влияет, но для проверки исходного сервера запрашивайте его напрямую.

CMS

В WordPress сжатие лучше включать на сервере, а не плагином: плагины кэширования обычно лишь дописывают правила в .htaccess, и на nginx они не сработают. На Tilda и других конструкторах сжатием управляет платформа.

Check Brotli и gzip через curl

Чтобы посмотреть, что сервер отвечает на конкретный алгоритм, используйте GET-запрос (на HEAD некоторые серверы отвечают без сжатия):

curl -s -o /dev/null -D - -H 'Accept-Encoding: br' https://example.com/ | grep -i content-encoding
curl -s -o /dev/null -D - -H 'Accept-Encoding: gzip' https://example.com/ | grep -i content-encoding
curl -s -o /dev/null -D - -H 'Accept-Encoding: zstd' https://example.com/ | grep -i content-encoding

Размер, переданный по сети, покажет curl -s -o /dev/null -H 'Accept-Encoding: br' -w '%{size_download}\n' https://example.com/. Тот же запрос без заголовка даст несжатый размер. В браузере то же видно в DevTools → Network: столбец Content-Encoding и разница между переданным размером и размером ресурса.

Предварительное сжатие статики

Для CSS, JS и SVG выгоднее сжать файлы один раз при сборке на максимальном уровне, чем каждый раз на лету. Рядом с оригиналом кладутся версии .br и .gz, а сервер (brotli_static on и gzip_static on в nginx) отдаёт готовый файл тому, кто его поддерживает:

brotli -q 11 -k dist/app.js      # создаст dist/app.js.br
gzip -9 -k dist/app.js           # создаст dist/app.js.gz
zstd -19 -k dist/app.js          # создаст dist/app.js.zst

Флаг -k сохраняет оригинал — он нужен клиентам без поддержки сжатия. В сборщиках то же делают плагины (например, для Vite и webpack есть плагины компрессии). Важно пересобирать сжатые копии вместе с оригиналом: устаревший .br рядом с новым app.js — частая причина «на одном браузере работает, на другом нет».

Что даёт сжатие для SEO: меньше байт — быстрее приходит HTML, раньше браузер находит CSS и картинку первого экрана, и это напрямую сокращает LCP на медленных мобильных сетях. Googlebot тоже запрашивает сжатые ответы, поэтому сервер быстрее отдаёт ему страницы.

Частые проблемы

• Сжатие включено, но не для всех типов. Обычная история: HTML сжимается, а JS и CSS — нет, потому что их MIME-типов нет в gzip_types. Проверьте прямую ссылку на крупный скрипт.
• Двойное сжатие. Приложение (например, PHP с zlib.output_compression) сжимает ответ, а сервер пытается сжать ещё раз. Оставьте сжатие на одном уровне — лучше на веб-сервере.
• Нет Vary: Accept-Encoding. Кэширующий прокси может отдать сжатую копию клиенту без поддержки. Все заголовки ответа видны в проверке HTTP-заголовков.
• Слишком высокий уровень на лету. Brotli 11 или gzip 9 для динамических страниц увеличивают время ответа сервера сильнее, чем экономят на передаче.

Сжатие — один из самых дешёвых способов ускорить загрузку: меньше байт — быстрее приходит HTML и раньше начинается отрисовка. Общую картину скорости даст проверка скорости страницы, а версию протокола — проверка HTTP/2. Как скорость связана с ранжированием, разобрано в статье о Core Web Vitals.