Коротко. Nginx — это веб-сервер: программа, которая первой встречает каждого посетителя и решает, насколько быстро отдать ему страницу. Его настройка определяет TTFB (время до первого байта), сжатие страниц и кэширование статики — большую часть ощущаемой скорости сайта. В нашей практике интернет-магазин клиента отдавал первую страницу 21 секунду из-за заголовков, запрещавших кэширование; после исправления настройки — 0,08 секунды, без переписывания сайта. Если сайт «задумывается» перед показом контента, начинать стоит с сервера, а не с редизайна.
Что такое Nginx, если вы не разработчик
Представьте проходную завода. Каждый посетитель сайта — машина у ворот. Nginx — диспетчер: он решает, отдать готовую копию страницы из кэша за миллисекунды или отправить запрос вглубь, к CMS и базе данных, где страница собирается заново. По умолчанию диспетчер часто «гоняет каждую машину через весь завод».
Настройка — это правка конфигурации сервера, а не переделка сайта. Мы занимаемся ей сами: держим клиентские сервисы на собственном Linux-сервере в Docker и отвечаем за скорость на всех уровнях.
Из чего складывается TTFB
TTFB — пауза между кликом и первым байтом ответа. Всё это время пользователь смотрит на белый экран: работает только сервер.
| Этап | Что происходит | Норма | Тревожный знак |
|---|---|---|---|
| DNS-запрос | Браузер узнаёт адрес сервера | до 50 мс | от 200 мс |
| Соединение и TLS | Устанавливается защищённый канал | до 100 мс | от 300 мс |
| Генерация страницы | CMS собирает HTML, ходит в базу | до 200 мс | от 1 секунды |
| Отдача из кэша Nginx | Готовая копия, минуя CMS | 10–80 мс | кэш выключен |
Главный резерв — две нижние строки: с кэшем тяжёлая генерация выполняется один раз, а не при каждом визите. Как секунды превращаются в потерянные заявки — в материале о скорости сайта и конверсии.
Кейс: TTFB 21 секунда → 0,08 секунды
Интернет-магазин клиента открывался до 21 секунды. Симптомы выглядели как «слабый хостинг, пора делать новый сайт» — так обычно и продают редизайн за сотни тысяч. Диагностика показала другое: движок слал запрещающие кэширование заголовки на все страницы подряд, и Nginx собирал каждую с нуля для каждого посетителя. Под наплывом людей и поисковых ботов сервер захлёбывался.
- Причина: заголовки no-cache там, где кэш ничему не мешает.
- Решение: исправили логику заголовков, настроили отдачу копий на сервере.
- Результат: TTFB 0,08 секунды — быстрее в сотни раз. Дизайн и контент не тронули.
Вывод: прежде чем платить за новый сайт «потому что старый медленный», закажите диагностику. Иногда всё решает правка конфигурации.
Кэш и сжатие: страница легче в 5–10 раз
Сжатие (gzip и brotli). Текст страницы перед отправкой упаковывается, как файлы в архив: страница в 500 КБ улетает как 60–80 КБ. На мобильном интернете это разница между «открылось» и «закрыл вкладку». Brotli жмёт плотнее gzip; мы включаем оба — браузер выбирает лучший.
Кэш статики. Логотип, шрифты, стили и скрипты не меняются месяцами. Правильные заголовки Cache-Control говорят браузеру: «храни эти файлы и не спрашивай заново». Повторные визиты и переходы между страницами становятся почти мгновенными — сервер в них не участвует.
Security-заголовки и лимиты для ботов
- Security-заголовки (HSTS, X-Content-Type-Options, Content-Security-Policy) запрещают браузеру опасное поведение: подмену содержимого, встраивание сайта в чужие фреймы, работу без шифрования. Для B2B это и репутация: ИБ-службы заказчиков такие вещи проверяют сканерами.
- Лимиты на ботов. Заметная часть нагрузки — не люди, а парсеры. Лимиты частоты запросов в Nginx отсекают тех, кто долбит сайт сотнями запросов в минуту, освобождая мощность для живых посетителей и ботов Яндекса и Google.
Что проверить на своём сайте прямо сейчас
- TTFB. В Chrome: F12 → вкладка Network → обновить страницу. У первой строки в колонке Time — время ответа. Больше 0,5–0,8 секунды — есть что чинить.
- Сжатие. Онлайн-чекер gzip/brotli покажет, включена ли упаковка. Нет — вы отдаёте страницы в 5–10 раз тяжелее необходимого.
- Кэш статики. Обновите страницу второй раз: если у картинок и стилей в Network нет пометок «memory cache» / «disk cache», кэш не настроен.
- Security-заголовки. Сервис securityheaders.com выдаёт оценку от A до F за минуту.
Если картина плохая — закажите бесплатный аудит: замерим TTFB и покажем, где теряются секунды и заявки.
Когда дело не в сервере
Честно: настройка Nginx — не универсальная таблетка.
- TTFB уже меньше 200 мс, а сайт медленный. Тормозит фронтенд: мегабайты JavaScript, несжатые изображения, чужие виджеты. Разбор — в статье об оптимизации PageSpeed.
- Виртуальный (shared) хостинг. Доступа к Nginx там нет — только кэш-плагины и панель. Радикальное ускорение потребует VPS; рыночный ориентир — 500–3 000 ₽/мес.
- Медленная сама CMS. Если и админка еле ворочается, кэш лишь маскирует проблему — лечить нужно движок.
- Трафика почти нет. При десяти визитах в день сначала решается задача привлечения; скорость подтягивается параллельно.
FAQ
У меня виртуальный хостинг без доступа к Nginx — что делать?
Использовать доступное: кэш-плагин CMS, сжатие и заголовки через панель хостинга. Полный контроль появляется на VPS (ориентир — от 500 ₽/мес).
Влияет ли скорость сервера на позиции в Яндексе и Google?
Да: обе системы учитывают скорость, а медленный TTFB сокращает краулинговый бюджет — роботы обходят меньше страниц. Но скорость — гигиенический фактор, контент она не заменит.
Можно ли сломать сайт настройкой сервера?
Можно, если править наугад: неверный заголовок кэша способен показать одному клиенту корзину другого. Наша схема: бэкап конфигурации → изменение → замер и проверка на живом сайте.
Чем Nginx отличается от Apache и что лучше?
Оба — веб-серверы. Nginx эффективнее держит много одновременных посетителей и чаще стоит «первой линией». Но важнее настройка: ненастроенный Nginx проигрывает настроенному Apache.