Как проверить скорость загрузки сайта: TTFB, время ответа сервера и что ускорять первым

«Сайт тормозит» — это почти всегда две разные проблемы, которые лечат по-разному. Либо сервер долго думает, прежде чем выдать первый байт, либо он отвечает мгновенно, а страница потом полминуты собирается в браузере из картинок и скриптов. Начинать нужно с первой: пока сервер отвечает секунду, никакая оптимизация картинок не поможет. Введите домен — проверка сделает несколько замеров и разложит время ответа на этапы: поиск адреса, соединение, шифрование, ожидание и загрузка.

Из чего складывается время ответа

• DNS — сколько заняло превращение имени в IP-адрес. Обычно единицы миллисекунд, у посетителя — часто ноль, потому что ответ уже в кеше.
• Соединение — установка TCP-связи с сервером. Здесь видна география: до сервера в соседнем городе 5–15 мс, до Европы из Ташкента — 80–120 мс, до США — 200 мс и больше, и это физика, а не настройки.
• Шифрование — рукопожатие TLS, ещё один-два обмена с сервером. Современные протоколы делают его дешевле, но совсем бесплатным оно не бывает.
• Ожидание (TTFB) — главное число. Это пауза между «запрос ушёл» и «пришёл первый байт ответа»: ровно столько сервер собирал страницу.
• Загрузка — передача самого HTML. Зависит от размера документа и от того, сжат ли он.

Ориентиры простые: TTFB до 0,4 секунды — хорошо, от 0,4 до 1 секунды — терпимо, но заметно, больше секунды — сервер откровенно тормозит и это чувствует каждый посетитель. Проверка подсвечивает результат по этим порогам, а размер HTML показывает отдельно: документ тяжелее 150–200 КБ до сжатия почти всегда означает, что в шаблоне что-то лишнее.

Чем это отличается от PageSpeed и Core Web Vitals

Инструменты Google меряют не скорость сервера, а скорость показа страницы у человека: когда появился главный блок (LCP), насколько быстро сайт откликается на нажатия (INP), не прыгает ли вёрстка (CLS). Это ближе к ощущениям посетителя, но и зависит от всего сразу — от шрифтов, рекламы, мобильного процессора.

Наша проверка меряет один конкретный отрезок: работу сервера. Её ценность в том, что ответ однозначный. Если TTFB 1,2 секунды, то и LCP меньше 1,2 секунды быть не может ни при какой оптимизации фронтенда — сервер уже съел весь бюджет. Поэтому порядок работы такой: сперва довести TTFB до приличных значений здесь, потом заниматься картинками и скриптами там.

Почему сервер думает долго

Нет кеша страниц. Самая частая причина у сайтов на WordPress. Без кеша каждый заход — это запуск PHP, десятки запросов к базе и сборка страницы заново, хотя для анонимного посетителя она каждый раз одинаковая. Плагин страничного кеша обычно снимает 70–90 процентов времени за полчаса работы.

Слабый или перегруженный хостинг. На дешёвом виртуальном тарифе вы делите процессор с сотнями соседей. Признак — время ответа скачет: то 200 мс, то 2 секунды, без всякой связи с вашим трафиком.

Старая версия PHP. Разница между 7.4 и 8.3 на типичном сайте — десятки процентов времени, и это изменение одной галкой в панели. Перед переключением стоит проверить совместимость темы и плагинов.

Внешние запросы в шаблоне. Курс валют, погода, лента соцсети, подгружаемые синхронно при каждом заходе. Пока чужой сервер молчит, ваш ждёт вместе с ним. Лечится кешированием ответа на час-другой.

Плагины. Каждый добавляет свои запросы и свою работу. Особенно тяжелы конструкторы страниц, счётчики просмотров, «похожие записи» и всё, что пишет в базу при каждом открытии.

Раздутая база. Ревизии записей, логи, брошенные таблицы удалённых плагинов, транзиенты. Чистка и добавление индексов иногда ускоряет вдвое.

Редирект перед ответом. Если вход на сайт идёт через два-три перенаправления, к времени сервера добавляется по полному кругу на каждое. Проверить цепочку можно инструментом HTTP-заголовков и редиректов.

Что делать по порядку

• Включить кеш страниц и убедиться, что он действительно работает: повторный замер после первого должен стать заметно быстрее.
• Включить сжатие: в ответе должен появиться Content-Encoding со значением gzip или br.
• Обновить PHP до актуальной версии и проверить, включён ли OPcache.
• Свести цепочку редиректов к одному шагу.
• Убрать плагины, которыми не пользуются, — не отключить, а удалить.
• Перевести картинки в WebP и включить отложенную загрузку для тех, что ниже первого экрана.
• Если аудитория в одной стране, а сервер в другой — либо переехать ближе, либо поставить CDN.
• Убедиться, что включён HTTP/2: он позволяет тянуть десятки файлов по одному соединению.

Как мерить, чтобы не обмануться

Один замер не значит ничего. Первый запрос после долгого простоя почти всегда медленный: кеш пуст, соединения с базой не открыты, файлы не в памяти. Наша проверка поэтому делает несколько заходов и показывает лучший результат — он точнее отражает то, что увидит живой посетитель, который пришёл не первым за день.

Помните и про географию: мы меряем со своего сервера, и для посетителя из другой страны числа будут другими. Если аудитория распределена по миру, дополните эту проверку замерами из разных точек. И не сравнивайте свой сайт с чужим по одному показателю — сравнивайте свой сайт с самим собой до и после изменений.

Частые вопросы

TTFB хороший, а сайт всё равно медленный. Значит, дело во фронтенде: тяжёлые картинки, шрифты, сторонние скрипты. Смотрите отчёты о Core Web Vitals.

Замеры каждый раз разные. Разброс в 10–20 процентов нормален. Разброс в разы — признак перегруженного хостинга или соседей по серверу.

Помогает ли CDN, если сервер медленный сам по себе? Для картинок и статики — да, для HTML — только если CDN кеширует и его. Иначе сеть просто быстрее донесёт медленный ответ.

Влияет ли скорость на позиции? Да, но не так сильно, как принято думать: она заметна как фактор при прочих равных и как причина отказов. Секунда ожидания на мобильном отпугивает людей надёжнее любого алгоритма.

Почему результат берётся из кеша? Чтобы одна и та же проверка не грузила чужой сервер. Для скорости кеш короткий — около 15 минут.

Дальше: HTTP-заголовки и редиректы, на каком хостинге стоит сайт и все инструменты на одной странице.