Настройка Nginx под мобильный трафик: практические приёмы

Что именно нужно настраивать под мобильных пользователей

Мобильный пользователь чаще сидит на нестабильной сети, меняет тип подключения и ждёт первый экран на устройстве с ограниченными ресурсами. Nginx не ускорит тяжёлый JavaScript и не превратит десктопную страницу в адаптивную, но может заметно сократить объём ответа и число запросов к приложению.

Ниже — практический набор для nginx 1.24 и новее: сжатие текстовых ответов, кеширование статики, HTTP/2, корректная работа с соединениями и проверка результата. Примеры рассчитаны на сайт, где Nginx стоит перед PHP-FPM, Node.js или другим upstream-приложением. Директивы HTTP/2 и сжатия нужно сверять с конкретной сборкой Nginx.

Под мобильный трафик стоит оптимизировать не User-Agent, а количество байт, запросов и времени до первого полезного ответа.

1. Сначала измерьте, что тормозит

До изменения конфигурации зафиксируйте базовые значения. Иначе вы не поймёте, помогли ли настройки Nginx или просто изменился маршрут сети.

• размер HTML, CSS и JavaScript после передачи;
• время до первого байта и время загрузки основного документа;
• число запросов к странице;
• долю ответов из кеша и долю ответов от приложения;
• ошибки 499, 502 и 504 в логах.

Проверьте страницу в DevTools с профилем медленной мобильной сети. Отдельно протестируйте холодную загрузку без кеша и повторную загрузку. Для реальных данных полезны access-логи с полями времени ответа и размера переданного тела, но названия переменных в вашем формате логов могут отличаться.

Что считать хорошим результатом

Не используйте одну универсальную цифру для всех сайтов. Для каталога, новостной страницы и личного кабинета разные бюджеты загрузки. Сравнивайте один и тот же URL, устройство, регион и состояние кеша. Если после настройки HTML стал меньше, но главный контент появляется позже из-за блокирующего JavaScript, проблема находится уже не только в Nginx.

Сжатие — уменьшение размера ответа перед передачей по сети. Оно экономит трафик, но требует CPU на сервере и не помогает бинарным форматам вроде JPEG или уже сжатого видео.

2. Включите сжатие только для текстовых ответов

Для мобильной сети обычно выгодно сжимать HTML, CSS, JavaScript, JSON, XML и SVG. Изображения JPEG, WebP, AVIF, архивы и PDF чаще не стоит повторно прогонять через gzip: размер почти не изменится, а CPU будет потрачен.

Настройки размещают в контексте http, чтобы они применялись ко всем виртуальным хостам. Пример для Nginx 1.24+:

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

gzip_vary on добавляет заголовок Vary: Accept-Encoding. Это важно для промежуточных кешей: ответ, сжатый для одного клиента, не должен ошибочно выдаваться клиенту без поддержки gzip. Уровень 5 — не закон природы: проверьте баланс размера ответа и загрузки CPU на вашем сервере.

Проверка: выполните запрос с заголовком Accept-Encoding: gzip и убедитесь, что для текстового ответа есть Content-Encoding: gzip. Для изображения такой заголовок может отсутствовать — это нормально.

3. Кешируйте статику с длинным сроком

CSS, JavaScript, шрифты и изображения не должны каждый раз доходить до приложения. Если имена файлов содержат хеш сборки, например app.8f31c.js, для них можно задать длительный срок кеширования.

location ~* \.(?:css|js|jpg|jpeg|png|gif|webp|avif|svg|woff2?)$ {
    expires 30d;
    add_header Cache-Control "public, max-age=2592000, immutable";
}

Срок в примере — 30 дней. Параметр immutable сообщает браузеру, что файл не нужно лишний раз перепроверять в течение заданного срока. Используйте его только для файлов с версионированными именами. Если сайт каждый раз отдаёт один и тот же app.js, после релиза пользователь может продолжить получать старый код.

Проверка: в ответе статического файла должны появиться Cache-Control и ожидаемый срок кеширования. После новой сборки измените имя файла или настройте корректную стратегию сброса кеша.

4. Не разделяйте HTML по User-Agent без необходимости

Самая частая ошибка — отправлять мобильным устройствам отдельный HTML по строке User-Agent. Это усложняет кеширование: один URL превращается в несколько вариантов ответа, а список распознаваемых устройств быстро устаревает.

Если мобильная и десктопная версии отличаются только раскладкой, используйте адаптивную вёрстку и отдавайте один HTML. Если бизнес действительно требует разных документов, добавляйте Vary: User-Agent и проверяйте, умеет ли ваш CDN или reverse proxy хранить варианты по этому заголовку. Иначе кеш может вернуть десктопный документ мобильному клиенту.

Для редких исключений можно использовать map, но это не универсальный детектор устройств:

map $http_user_agent $is_mobile {
    default 0;
    ~*"Android|webOS|iPhone|iPad|iPod|BlackBerry|Opera Mini|IEMobile" 1;
}

server {
    add_header X-Mobile-Variant $is_mobile always;
}

Этот фрагмент только помечает запросы для диагностики. Он не создаёт мобильную версию и не должен становиться основанием для критически важной логики. Проверка: в ответе появится X-Mobile-Variant: 1 для совпавших User-Agent и 0 для остальных.

5. Используйте HTTP/2 там, где он уже поддержан

При большом количестве небольших ресурсов HTTP/2 может уменьшить накладные расходы за счёт одного защищённого соединения и мультиплексирования запросов. Это особенно заметно на страницах, где браузер загружает много CSS, шрифтов и небольших изображений. Сам протокол не заменяет сжатие и кеширование.

В актуальной конфигурации Nginx HTTP/2 включается на TLS-порту. Синтаксис зависит от версии и способа сборки; для Nginx 1.25.1 и новее директива http2 используется отдельно от listen:

server {
    listen 443 ssl;
    http2 on;

    server_name example.com;

    ssl_certificate /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;
}

Не копируйте этот блок целиком в рабочий сервер без проверки существующих настроек TLS, сертификата и маршрутизации. В старых версиях Nginx встречается другой синтаксис — параметр http2 у listen. Сначала выполните nginx -t и сверяйтесь с документацией вашей версии.

Проверка: в инструментах разработчика браузера протокол соединения должен отображаться как h2. Если перед Nginx стоит CDN, именно он может завершать TLS и определять фактический протокол клиента.

Какой приём выбрать первым

Что обычно ломается

Кеш отдаёт старый JavaScript

Проверьте, меняется ли имя файла после сборки. Если нет, не ставьте ему годовой или бессрочный кеш без механизма сброса. На время диагностики удалите кеш браузера и CDN, затем сравните заголовки ответа.

Gzip не появился

Проверьте MIME-тип ответа, размер файла и заголовок Accept-Encoding. Gzip не включится для ответа меньше значения gzip_min_length и не обязан применяться к типу, которого нет в gzip_types.

После включения HTTP/2 появились ошибки

Сначала проверьте конфигурацию командой nginx -t. Затем убедитесь, что запрос приходит на TLS-порт и что HTTP/2 поддержан установленной версией. Если TLS завершается на CDN, настройка на origin-сервере может не менять протокол между браузером и CDN.

Мобильный клиент получил не ту версию страницы

Причиной может быть кеширование ответа без учёта User-Agent или слишком агрессивное правило в CDN. Лучше отказаться от разных HTML-вариантов, а если это невозможно — явно проектировать ключ кеша и проверять заголовки на каждом слое.

Что сделать дальше

Сначала включите gzip для текстовых ответов и кеширование версионированной статики, затем снимите повторные замеры на том же URL и профиле сети. После этого проверьте долю ответов от приложения, ошибки 499–504 и фактический протокол соединения. Отдельно измерьте время появления главного контента: если Nginx уже передаёт небольшой ответ быстро, следующий узкий участок находится в изображениях, JavaScript, шрифтах или серверном рендеринге.