Настройка Gzip и Brotli: полное руководство по сжатию на Nginx и Apache

Представьте: ваш сайт загружается 5 секунд, но 80% времени уходит на передачу JavaScript-бандлов. Вы уже оптимизировали изображения, включили кэширование, но скорость почти не изменилась. Скорее всего, вы упустили сжатие на транспортном уровне. Мы настраиваем Gzip и Brotli на сервере, уменьшая размер контента в 3–10 раз без изменений в коде. Экономия на трафике может достигать 70% при использовании Brotli — это снижает затраты на хостинг и CDN.

Brotli даёт на 15–25% лучшее сжатие, чем Gzip, при сопоставимой нагрузке на CPU. Один из наших проектов — интернет-магазин с бандлом 1.2 МБ. После настройки Brotli с pre-compressed статикой размер уменьшился до 280 КБ, а LCP упал с 4.2 с до 1.8 с. Для статики мы используем pre-compressed файлы — .gz и .br создаются при сборке, сервер отдаёт их без повторного сжатия. Это экономит до 30% процессорного времени на пике.

Почему Brotli лучше Gzip?

Brotli использует словарь для HTML/JS/CSS, что даёт более плотную упаковку. Например, app.js 500 КБ сжимается до 130 КБ (Brotli) против 150 КБ (Gzip). Разница особенно заметна на мобильных сетях с ограниченной пропускной способностью. Кроме того, Brotli поддерживает уровни сжатия до 11, что позволяет максимально ужать статику при сборке. Однако на лету высокие уровни (9–11) сильно нагружают CPU, поэтому для динамического сжатия рекомендуется уровень 6.

Как минимизировать нагрузку на CPU при сжатии?

Основной способ — использовать pre-compressed статику. Файлы .gz и .br генерируются один раз при сборке проекта (например, с помощью vite-plugin-compression), а сервер отдаёт их напрямую, не тратя процессорное время на сжатие каждого запроса. Для динамического контента (HTML, JSON) применяется on-the-fly сжатие с уровнем 6 — баланс между степенью сжатия и нагрузкой. В пиковые часы можно отключить сжатие для больших файлов через директиву gzip_min_length 256. Мониторинг CPU позволяет своевременно скорректировать уровень сжатия — если нагрузка выше 80%, рассмотрите снижение уровня или увеличение gzip_min_length. Снижение нагрузки на CPU уменьшает затраты на серверные ресурсы.

Nginx: Gzip + Brotli

# /etc/nginx/nginx.conf или /etc/nginx/conf.d/compression.conf

# Gzip — поддерживается везде
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;        # 1-9, баланс CPU/сжатие; 6 — хорошая точка
gzip_min_length 256;      # не сжимать очень маленькие файлы
gzip_types
    application/javascript
    application/json
    application/xml
    application/rss+xml
    image/svg+xml
    text/css
    text/html
    text/javascript
    text/plain
    text/xml
    font/woff
    font/woff2;

# Brotli — нужен модуль ngx_brotli
# Установка: apt install libnginx-mod-brotli
brotli on;
brotli_comp_level 6;
brotli_types
    application/javascript
    application/json
    text/css
    text/html
    text/plain
    image/svg+xml
    font/woff2;

Проверка:

curl -H "Accept-Encoding: br" -I https://example.ru/
# Ответ должен содержать: Content-Encoding: br

curl -H "Accept-Encoding: gzip" -I https://example.ru/
# Ответ: Content-Encoding: gzip

Pre-compressed static assets

Для статических файлов (JS, CSS, бандлы) — генерировать .gz и .br файлы при сборке, отдавать напрямую. Нет расхода CPU при каждом запросе:

// vite.config.ts
import { defineConfig } from 'vite';
import viteCompression from 'vite-plugin-compression';

export default defineConfig({
    plugins: [
        viteCompression({ algorithm: 'gzip',   ext: '.gz' }),
        viteCompression({ algorithm: 'brotliCompress', ext: '.br' }),
    ]
});

# Nginx: отдавать pre-compressed файлы
location ~* \.(js|css|woff2)$ {
    gzip_static  on;    # ищет .gz версию
    brotli_static on;   # ищет .br версию (модуль ngx_brotli)
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Как проверить, что сжатие работает?

Используйте curl или вкладку Network в DevTools. В ответе должен быть заголовок Content-Encoding: br или gzip. Также проверьте Vary: Accept-Encoding — он указывает кеширующим серверам, что контент зависит от кодировки. Для пошаговой диагностики можно использовать онлайн-сервисы, например, проверку заголовков на сайте.

Если клиент не поддерживает Brotli, Nginx автоматически отдаёт Gzip или несжатый контент. Убедитесь, что директива gzip on включена — это гарантирует fallback. Использование CDN с поддержкой Brotli дополнительно ускоряет доставку контента и снижает нагрузку на исходный сервер.

Типичные результаты сжатия

Уровни сжатия: рекомендации

Уровни 1–3 — низкая нагрузка CPU, слабое сжатие. 4–6 — баланс. 7–9 — высокое сжатие, но CPU растёт нелинейно: уровень 9 требует в 3 раза больше времени, чем 6. Для pre-compressed файлов используйте 11 (только Brotli) — компилируется один раз при сборке.

Apache

# .htaccess
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/css application/javascript
    AddOutputFilterByType DEFLATE application/json image/svg+xml font/woff2
</IfModule>

Процесс настройки сжатия

1. Анализ текущей конфигурации сервера (Nginx/Apache).
2. Выбор уровня сжатия (Gzip 6, Brotli 6 — баланс).
3. Настройка исключений (несжимаемые форматы: PNG, JPEG, MP4).
4. Генерация pre-compressed файлов в сборке (Vite, Webpack).
5. Проверка заголовков ответов (Content-Encoding, Vary).
6. Мониторинг нагрузки на CPU.

Что входит в работу

• Настройка Gzip и Brotli на сервере (Nginx/Apache).
• Конфигурация pre-compressed статики (если используется сборщик).
• Проверка заголовков и тестирование сжатия.
• Документация с внесёнными изменениями.
• Рекомендации по уровням сжатия под ваш трафик.

Наши инженеры настраивают сжатие более 5 лет — мы оптимизировали скорость загрузки для 100+ проектов, снижая LCP и TTFB на 40–60%. Хотите так же? Свяжитесь с нами — проведём аудит и внедрим сжатие Gzip и Brotli за один день. Закажите настройку сжатия и получите консультацию по ускорению вашего сайта уже сегодня.

Мы регулярно сталкиваемся с ситуацией: «Сайт не открывается» в 3 часа ночи — и выясняется, что disk full на VPS, потому что логи nginx не ротировались полгода. Или сервер лёг под нагрузкой в день запуска рекламной кампании, потому что на shared хостинге стоял лимит в 50 одновременных соединений. Настройка хостинга и деплоя — это не про «где дешевле», это про то, что происходит в момент, когда что-то идёт не так. Наша команда помогает избежать таких инцидентов, проектируя инфраструктуру с учётом реальных паттернов нагрузки.

Когда выбирать Vercel и Netlify?

Vercel создан под Next.js — деплой в один push, preview deployments для каждого PR, автоматический CDN, Edge Functions, ISR без конфигурации. Для фронтенд-проектов и JAMstack это оптимальный выбор: нет операционной нагрузки, time-to-deploy измеряется минутами.

Ограничения реальные: Vercel Serverless Functions запускаются в us-east-1 по умолчанию (latency для Европы +80–100ms), Function timeout 300 секунд на Pro, Bandwidth 1TB/месяц на Pro. Для тяжёлого backend — нужны воркеры или отдельный сервер.

Netlify ближе к статике и Edge Functions на базе Deno Deploy. Build minutes — основное ограничение на бесплатном тарифе.

Почему Docker — основа предсказуемого деплоя?

«Работает на моей машине» — классика. Docker решает это через контейнеризацию окружения. Но плохой Dockerfile создаёт новые проблемы.

Типичная ошибка: копировать всё в образ без .dockerignore, получать 800MB образ вместо 80MB. node_modules внутри образа весит столько же. Правильно: multi-stage build.

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["npm", "start"]

Итоговый образ: 180MB вместо 1.2GB. Время сборки CI сокращается из-за layer caching — если package.json не изменился, слой с npm ci берётся из кэша.

Docker Compose для локальной разработки и простых продакшен-сценариев: приложение + PostgreSQL + Redis в одной конфигурации. Для production на одном сервере — вполне рабочий вариант, если нет требований горизонтального масштабирования.

Подробнее о контейнеризации — Wikipedia: Docker.

Как настроить Nginx как reverse proxy?

Nginx перед приложением — стандарт для VPS и выделенных серверов. Основные функции: SSL termination, gzip, static files, rate limiting, upstream балансировка.

Конфигурация, которую часто делают неправильно: worker_processes auto — количество процессов равно числу CPU. worker_connections 1024 — это 1024 на каждый воркер-процесс. При 4 CPU и 1024 connections = 4096 одновременных соединений. Для высоконагруженного сайта нужно worker_connections 4096 и настройка keepalive_timeout 65.

Для статических ассетов с хешем в имени файла:

location ~* \.(js|css|woff2|png|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

immutable сообщает браузеру: не проверяй этот файл даже при hard refresh. Правильно работает только с content-hashed именами файлов (что делает Vite/webpack по умолчанию). Документация — Wikipedia: Nginx.

AWS: гибкость и сложность

EC2 + Auto Scaling Group — классика для горизонтального масштабирования. AMI с предустановленным приложением, Launch Template, ASG с min/desired/max instances, Application Load Balancer. При CPU > 70% на 3 минуты — scale out, при CPU < 30% на 15 минут — scale in. Health check через ALB исключает нездоровые инстансы из ротации.

ECS Fargate — контейнеры без управления EC2. Деплой Docker-образа, задаёте CPU/память (512 CPU units = 0.5 vCPU, от 512MB памяти), Fargate запускает. Дороже Lambda, но нет cold start и нет timeout-ограничений. Подходит для long-running процессов, WebSocket-серверов, тяжёлых воркеров.

RDS для PostgreSQL с Multi-AZ: автоматический failover за 1–2 минуты при падении primary. Read Replicas для масштабирования чтения. RDS Proxy для connection pooling — Lambda-функции не умеют держать долгосрочные соединения, прокси буферизует это.

Kubernetes: когда это оправдано

K8s добавляет значительную операционную сложность. Оправдан, когда: несколько команд деплоят независимые сервисы, нужна тонкая настройка ресурсов на сервис, canary deployments и blue/green без простоя — требование.

AWS EKS, GKE или managed k8s от Hetzner (дешевле). Helm charts для стандартных сервисов. Horizontal Pod Autoscaler по CPU и custom metrics (RPS через Prometheus).

Для большинства стартапов и средних проектов — Kubernetes избыточен. ECS или Fly.io дают 80% возможностей при 20% операционной сложности.

Мониторинг и alerting

Сервер без мониторинга — это ожидание инцидента. Минимальный стек: Prometheus + Grafana (или Grafana Cloud для managed), alerting на disk > 80%, memory > 85%, CPU > 90% за 5 минут, error rate > 1%. Uptime через Better Uptime или Upptime (self-hosted).

Logs: Loki + Grafana или CloudWatch Logs Insights. Структурированные JSON-логи (winston, pino) — обязательно, иначе поиск по логам превращается в боль.

Что входит в настройку хостинга

• Аудит текущей инфраструктуры и профилирование нагрузки
• Выбор целевой архитектуры (VPS, AWS, serverless, Kubernetes)
• Настройка CI/CD pipeline (GitHub Actions, GitLab CI) с автоматическим деплоем
• IaC через Terraform или Pulumi (инфраструктура как код)
• Конфигурация Nginx, SSL-сертификаты, HTTP/2, brotli
• Мониторинг и алертинг (Prometheus + Grafana, PagerDuty)
• Документация runbooks и обучение команды

Дополнительно: пишите, если нужна миграция с текущего хостинга или интеграция с внешними сервисами.

Процесс работы

1. Аудит текущей инфраструктуры (2–5 дней)
2. Выбор целевой архитектуры с обоснованием по нагрузке и бюджету (1–3 дня)
3. Настройка CI/CD pipeline (GitHub Actions, GitLab CI) (2–5 дней)
4. IaC через Terraform или Pulumi (3–10 дней)
5. Настройка мониторинга и alerting (2–5 дней)
6. Документация runbooks и обучение команды (1–3 дня)

Наш опыт — 7 лет на рынке, более 50 проектов, гарантия работоспособности после деплоя.

Сроки

• Базовый деплой на VPS с Docker + Nginx + CI/CD: 1–2 недели.
• Настройка AWS инфраструктуры с Auto Scaling, RDS, CDN: 3–6 недель.
• Миграция на EKS с нуля: 6–12 недель.
• Настройка Vercel/Netlify для JAMstack: 3–5 дней.

Стоимость рассчитывается индивидуально в зависимости от сложности и объёма работ. Получите консультацию — оценим вашу архитектуру за один день.