Время ответа сервера: какое нормальное и как проверить
Что такое время ответа сервера, какое значение считать нормальным и как замерить его самостоятельно, не гадая по ощущениям.
Время ответа сервера — это пауза между запросом страницы и первым байтом ответа. В измерениях её называют TTFB (time to first byte). Google считает хорошим значением 0,8 секунды и меньше, а больше 1,8 секунды — плохим: ориентиры приведены в материале web.dev о TTFB.
Одно медленное измерение — не проблема: сервер мог «проснуться» после простоя или обрабатывать тяжёлый запрос. Проблема начинается, когда время ответа стабильно высокое или растёт по вечерам и в часы рекламы. Тогда сайт грузится медленнее, посетители уходят до того, как страница начала отрисовываться, а заявки теряются, хотя формально сайт работает.
Что именно измеряет время ответа
TTFB — не только работа вашего сервера. Это сумма нескольких шагов, и каждый может тормозить отдельно:
- Редиректы, если адрес сначала ведёт на другой (например, с
httpнаhttpsили сwwwбезwww). - Поиск адреса сервера по домену — DNS-запрос.
- Установка соединения (TCP).
- Согласование шифрования (TLS), если сайт открыт по
https. - Отправка запроса и ожидание ответа.
- Работа сервера: код сайта, запросы к базе, сборка страницы.
Состав TTFB описан в том же материале web.dev: туда входят время редиректов, DNS, соединения и TLS, а также запрос до первого байта ответа. Поэтому медленный сервер и медленный TTFB — не одно и то же. Если сервер собирает страницу за 100 мс, а цепочка из трёх редиректов добавляет ещё секунду, посетитель увидит секунду с лишним. Про редиректы подробнее — в разборе переезда на новый домен.
Какое время ответа считать нормальным
Пороги из web.dev Google называет примерным ориентиром для большинства сайтов, а не жёсткой нормой:
| TTFB | Оценка | Что это значит |
|---|---|---|
| до 0,8 с | хорошо | запас для остальной загрузки есть |
| 0,8–1,8 с | требует улучшений | стоит искать причину, если значение держится постоянно |
| больше 1,8 с | плохо | страница начинает загружаться слишком поздно |
Для разных типов сайтов нормально выглядит по-разному. Статичный лендинг или страница из кэша отвечает заметно быстрее, чем интернет-магазин, где каждая карточка собирается из базы. Сравнивайте сайт с самим собой во времени и с порогами выше, а не с чужими цифрами из статей. И смотрите на ряд замеров, а не на один, сделанный из вашего браузера.
Время ответа важно и для поисковых роботов. В документации Google Search Central сказано: если время ответа сайта остаётся стабильным или улучшается, лимит обхода растёт, а если сайт замедляется, Google обходит его меньше. Медленный сервер — одна из причин, почему новые страницы попадают в поиск позже. Если страницы уже выпали из выдачи, посмотрите разбор про пропажу из Яндекса.
Как измерить время ответа самому
Есть три способа, от простого к точному.
Первый — вкладка Network в браузере. Откройте инструменты разработчика, обновите страницу, выберите первый запрос (документ) и на вкладке Timing найдите строку Waiting (TTFB). Её смысл объясняет справка Chrome DevTools: браузер ждёт первый байт ответа, и в это время входят один сетевой круг и обработка запроса сервером. Минус способа в том, что вы меряете со своего компьютера, из своей сети и с прогретым кэшем.
Второй — команда curl, которая раскладывает время по шагам:
curl -o /dev/null -s -w "dns: %{time_namelookup}\nconnect: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n" https://example.com/
Значения накопительные: ttfb включает всё, что выше. Время самого сервера примерно равно разнице между ttfb и tls, в неё попадает и один круг до сервера. Описание переменных — в документации curl. Запустите команду 5–10 раз с интервалом и смотрите на разброс, а не на одно число.
Третий — регулярные замеры из внешней точки. Один замер всегда случаен, а проблемы чаще проявляются в определённые часы. Только по ряду точек видно, что сервер замедляется каждый вечер или после каждой выкладки.
Проверьте не только главную. Она часто закэширована, а медленными оказываются карточки товаров, поиск, корзина и страницы с фильтрами.
Почему сервер отвечает медленно
Самые частые причины удобно держать перед глазами в таблице:
| Признак | Вероятная причина | Что делать |
|---|---|---|
| Медленно только первая загрузка после паузы | сервер или приложение засыпает при простое | прогрев, другой тариф, постоянно работающий процесс |
| Медленно по вечерам или в часы рекламы | не хватает ресурсов при нагрузке | смотреть загрузку процессора и памяти, оптимизировать или увеличить ресурсы |
| Медленны динамические страницы, главная быстрая | тяжёлые запросы к базе, нет кэша | включить кэширование, проверить медленные запросы |
| Большая доля времени уходит на DNS | медленный DNS-провайдер или длинная цепочка записей | проверить DNS-записи, сменить DNS-хостинг |
| Время растёт после обновления сайта | новый плагин, модуль или изменение кода | откатить изменение и сравнить замеры |
| Ответ то быстрый, то с задержкой в несколько секунд | перегруженный общий хостинг, соседние сайты | перенести на другой тариф или сервер |
Если вместе с медленным ответом появляются ошибки сервера, загляните в разбор ошибки 502: за медленным ответом часто стоит та же перегрузка, которая позже превращается в сбой.
Что делать, если время ответа выросло
Порядок действий, который помогает не лечить наугад:
- Измерьте TTFB для нескольких типов страниц: главная, карточка, страница с формой, поиск.
- Разложите время по шагам через
curl: DNS, соединение, TLS, ожидание сервера. Так видно, где именно потеряны секунды. - Проверьте цепочку редиректов: каждый лишний переход добавляет полный круг запроса.
- Вспомните, что менялось с тех пор, как всё было быстро: плагины, версия PHP, тариф, объём базы, трафик.
- Включите кэширование страниц и результатов тяжёлых запросов, если его нет.
- Проверьте ресурсы сервера в часы пик. Если процессор или память упираются в потолок, дело в нагрузке, а не в коде.
- После правок замерьте снова в том же режиме и сравните с исходными цифрами.
Не оценивайте скорость по одному инструменту. Время ответа — часть общей картины, а как читать остальные метрики, разобрано в статье про проверку скорости загрузки.
Почему код 200 не гарантирует нормальную работу
Сайт может отвечать кодом 200 и при этом отдавать страницу за четыре секунды. Для простой проверки доступности всё в порядке, а для посетителя это почти сбой. Подробнее — в статье почему аптайм 200 OK ничего не значит.
Поэтому мониторинг стоит настраивать не только на вопрос «жив или нет», но и на время ответа: задайте порог, при превышении которого придёт уведомление. Что вообще проверяет мониторинг и нужен ли он небольшому сайту, описано в отдельной статье.
Если сайт медленный только у части посетителей, причина может быть в расстоянии до сервера или в маршруте. Как проверить это из разных мест, показано в статье про доступность из регионов.
Как проверить время ответа прямо сейчас
Быстрый способ узнать, как сайт выглядит снаружи, — бесплатная проверка доступности Обходчика. Она проверяет, открывается ли сайт, регистрация не нужна.
Один замер — это отправная точка. Чтобы понять, медленный сайт всегда или только в определённые часы, повторите проверку в разное время суток и сравните результаты с ориентирами из таблицы выше.