TTFB и скорость
Что такое TTFB
TTFB (Time to First Byte) — время от отправки HTTP-запроса до получения первого байта ответа от сервера. Измеряется в миллисекундах.
Это один из ключевых показателей серверной производительности. Высокий TTFB означает, что сервер долго обрабатывает запрос — до того, как вообще начинает отдавать данные.
Введите URL — краулер сделает запрос с вашего сервера и покажет реальное время отклика.
Ориентиры
| TTFB | Оценка | Рекомендация |
|---|---|---|
| < 800 мс | Хорошо | Норма по стандарту Google |
| 800–1800 мс | Требует оптимизации | Стоит оптимизировать сервер |
| > 1800 мс | Медленно | Нужна срочная оптимизация |
В отчёте вкладка «Скорость» показывает все страницы с TTFB выше 800 мс. Пороги соответствуют рекомендациям Google.
Что влияет на TTFB
- Медленные запросы к базе данных — самая частая причина.
- Отсутствие кеширования — страница генерируется при каждом запросе.
- Перегруженный сервер — недостаточно ресурсов CPU/RAM.
- Географическое расстояние — краулер работает с российского сервера; для зарубежных сайтов TTFB будет выше из-за латентности сети.
- Тяжёлые плагины и скрипты на PHP/Python — долгая серверная генерация.
- Rate limiting сайта — если сайт намеренно замедляет ответы для краулеров.
Редиректы
Поле Редиректов показывает, сколько HTTP-перенаправлений произошло до финального URL. Например, HTTP → HTTPS → www → без www — это 3 редиректа.
Каждый редирект добавляет задержку. Для SEO рекомендуется не более 1 редиректа для любого URL. Проверить цепочку редиректов можно с помощью инструмента проверки редиректов.
Частые вопросы
Какой TTFB считается нормальным?
По рекомендациям Google: менее 800 мс — хорошо, 800–1800 мс — требует оптимизации, более 1800 мс — медленно. Для большинства сайтов стоит стремиться к TTFB менее 500 мс.
Почему TTFB в краулере отличается от реального?
Краулер работает с российского сервера, не выполняет JavaScript, не загружает изображения и стили, не использует браузерный кеш. Это чистое время ответа сервера без клиентской обработки. Используйте как ориентир, а не абсолютную метрику.
Как уменьшить TTFB сайта?
Включить серверное кеширование, оптимизировать запросы к БД, использовать CDN для статики, перейти на быстрый хостинг. Если TTFB высокий на отдельных страницах — проблема в тяжёлых запросах на этих страницах, а не в сервере.
Влияет ли TTFB на ранжирование в Google?
Напрямую — нет, TTFB не является отдельным фактором ранжирования. Но он входит в метрику LCP (Largest Contentful Paint), которая является Core Web Vital и учитывается Google при ранжировании. Высокий TTFB увеличивает LCP.
Чем TTFB отличается от скорости загрузки страницы?
TTFB — время до получения первого байта ответа от сервера. Скорость загрузки — полное время до готовности страницы: получение HTML, загрузка CSS/JS/изображений, рендеринг. TTFB — только серверная часть, обычно 10–30% от общего времени загрузки.
Почему TTFB разный для разных страниц одного сайта?
Разные страницы выполняют разные запросы к базе данных и используют разный объём серверной логики. Главная может генерироваться 100 мс, а каталог с фильтрами — 2 секунды. Проверяйте TTFB на конкретных проблемных страницах, а не только на главной.
Как редиректы влияют на TTFB?
Каждый редирект — дополнительный HTTP-запрос, добавляющий 100–500 мс. Цепочка HTTP → HTTPS → www легко добавляет полсекунды. Рекомендуется не более одного редиректа. Проверить цепочку редиректов.
Может ли CDN улучшить TTFB?
Для статических ресурсов (CSS, JS, изображения) — да, значительно. Для динамических HTML-страниц CDN помогает меньше, если не настроено edge-кеширование. Основной выигрыш — сокращение географической задержки между пользователем и сервером.