Как SEO Crawler измеряет TTFB
TTFB (Time to First Byte) — это время от отправки HTTP-запроса до получения первого байта ответа. Это самая «ремонтопригодная» часть скорости сайта: её чинит бэкенд, а не фронтенд. SEO Crawler меряет TTFB для каждой страницы во время обхода и показывает распределение по порогам Google в разделе «Скорость» отчёта аудита.
Введите URL — краулер сделает запрос со своего сервера и покажет реальное время отклика с оценкой по порогам Google.
Что именно мы меряем
В нашем замере «TTFB» — это время от момента, когда HTTP-клиент отправил GET-запрос, до момента, когда он получил полный HTTP-ответ. Для небольших HTML-страниц (до ~500 KB) разница между «первым байтом» и «полным ответом» обычно меньше 50 мс, так что на практике мы называем этот показатель TTFB.
Что входит в наш замер:
- установка TCP-соединения с сервером;
- TLS-хендшейк (для HTTPS);
- отправка HTTP-запроса;
- серверная обработка: работа CMS, запросы к БД, генерация HTML;
- передача тела HTML-ответа (для чистого TTFB по спецификации — только первый байт).
Что НЕ входит:
- загрузка CSS, JS, шрифтов, картинок (мы не скачиваем эти ресурсы);
- исполнение JavaScript (мы не рендерим страницу);
- построение DOM/CSSOM, рендеринг, LCP, CLS, INP — всё это клиентские метрики;
- время работы Service Worker и браузерного кэша (их у нас нет).
Где замер делается
Все запросы наш краулер делает со своего сервера. Для российских сайтов это близко к реальным условиям пользователя из РФ: меньше сетевой задержки, меньше влияние трансграничного трафика. Для зарубежных сайтов наш TTFB будет выше «чистого серверного» из-за сетевой дистанции — это надо учитывать.
| Откуда замер | Для кого релевантен | Типичная сетевая задержка |
|---|---|---|
| SEO Crawler (РФ) | Сайты с аудиторией в РФ и СНГ | 10–40 мс до российского хостинга |
| Google PageSpeed (США/ЕС) | Глобальные сайты | 80–200 мс до российского хостинга |
| Яндекс.Метрика Вебвизор | Данные реальных пользователей | Зависит от каждого юзера |
Если вы видите у нас 200 мс, а в PageSpeed — 800 мс, разница в 600 мс — это сетевая латентность через океан. Оптимизация сервера эту разницу не уберёт, тут нужен CDN с edge-кэшем.
Пороги, которые мы используем
SEO Crawler использует два набора порогов, в зависимости от контекста.
Пороги Google в отчёте аудита
В разделе «Скорость» вкладки отчёта страницы группируются по порогам, которые Google использует для рекомендации по TTFB:
| TTFB | Оценка | Цвет в отчёте |
|---|---|---|
| < 800 мс | Хорошо | Зелёный |
| 800–1800 мс | Требует оптимизации | Жёлтый |
| > 1800 мс | Медленно | Красный |
Расширенная градация в чекере и Health Score
Для одиночной проверки URL (чекер выше) и для расчёта Health Score мы используем более строгую шкалу — она ближе к рекомендациям профессиональных SEO-инструментов:
| TTFB | Оценка | Рекомендация |
|---|---|---|
| < 200 мс | Отлично | Не требует действий |
| 200–600 мс | Приемлемо | Проверить кэш и SQL-запросы |
| 600–2000 мс | Медленно | Нужна оптимизация бэкенда |
| > 2000 мс | Критично | Срочная оптимизация |
TTFB в отчёте аудита
Найти TTFB в интерфейсе можно в двух местах:
1. Вкладка «Скорость» в отчёте
Открыть обход → вкладка «Скорость». Там три блока, связанных с TTFB:
- Распределение TTFB — три карточки с количеством страниц по порогам Google. Клик по карточке фильтрует таблицу.
- Средний TTFB по сайту — в шапке вкладки, рядом со счётчиком медленных страниц.
- Самые медленные страницы — топ URL с самыми высокими TTFB, с мини-графиком длительности.
2. Колонка TTFB в таблице «Все страницы»
На вкладке «Все страницы» для каждого URL видна колонка TTFB. Её можно сортировать: клик по заголовку колонки — от медленных к быстрым, повторный клик — наоборот. Это удобный способ увидеть весь список и глазами найти закономерности (например, что все карточки товаров быстрые, а все категории — медленные).
Как отфильтровать и выгрузить медленные страницы
Фильтрация в UI
- Открыть обход → вкладка «Скорость».
- Кликнуть по карточке «Требует оптимизации» или «Медленно» в блоке «Распределение TTFB».
- Ниже появится отфильтрованная таблица — только те URL, которые попали в выбранный диапазон.
- Сверху у таблицы — кнопка экспорта. Клик → выгрузка в CSV или XLSX только отфильтрованных страниц.
Экспорт всего отчёта
В правом верхнем углу страницы аудита есть кнопки CSV, XLSX, PDF. Для работы с TTFB удобнее всего XLSX — в нём есть листы:
| Лист в XLSX | Что внутри |
|---|---|
All pages | Все URL с TTFB, статусом, размером и остальными метриками |
Slow pages | Только страницы с TTFB > 800 мс |
Redirects | Все цепочки редиректов (редирект добавляет 100–500 мс к TTFB) |
Дальше в Excel можно отсортировать Slow pages по TTFB по убыванию, передать бэкенд-разработчику, и он по списку будет чинить самые болезненные URL.
Что влияет на TTFB
Здесь даём только перечень типовых причин. Подробный разбор каждой — в статье «Как ускорить сайт в 2026: TTFB и Core Web Vitals».
- Запросы к БД — чаще всего медленные страницы упираются в SQL без индексов или N+1-запросы.
- Отсутствие кэша — страница генерируется при каждом запросе, хотя могла бы быть закэшированной на 5 минут.
- CMS-шаблоны — тяжёлые шаблоны с десятками плагинов (особенно WordPress/Bitrix) могут добавлять секунды.
- Перегруженный хостинг — сервер без запаса CPU/RAM деградирует на пиках.
- Редиректы — цепочка HTTP → HTTPS → www добавляет 100–500 мс. Должен быть максимум один редирект.
- CDN и GZIP — правильная настройка снижает TTFB, неправильная (например, отключённое сжатие) — увеличивает.
Почему TTFB разный у разных страниц одного сайта
Это нормально и как раз то, что мы хотим видеть в аудите. Типовые причины разброса:
- Кэш. Главная часто в hot-кэше (её постоянно запрашивают), а редко посещаемая статья — в холодном. Разница может быть 10×.
- Сложность запроса. Карточка товара делает 3 запроса к БД. Категория с фильтрами — 30 запросов с join'ами. Время ответа отличается пропорционально.
- Разные CMS-шаблоны. Страница блога и страница каталога могут быть построены на совершенно разных template'ах с разным набором подключаемых плагинов.
- Лишние обращения к внешним API. Если template показывает курс валют через внешний сервис — он может отвалиться, и страница ждёт таймаута.
Отсортируйте таблицу «Все страницы» по TTFB и сгруппируйте URL в голове по разделам. Если все /catalog/* медленные — проблема в шаблоне категории. Если медленные все страницы одного поддомена — дело в инфраструктуре именно этого поддомена.
Частые вопросы
Зачем SEO Crawler меряет отдельно TTFB, а не полное время загрузки?
TTFB — это чистое время, которое сервер потратил на генерацию HTML: там нет JavaScript, картинок, шрифтов и CSS. Мы меряем именно его, потому что все клиентские метрики (LCP, INP) зависят от TTFB: если сервер отдаёт HTML за 2 секунды, ни один фронтенд-трюк не даст вам хорошего LCP. TTFB — самая «ремонтопригодная» часть скорости: её чинит бэкенд-команда.
С какого IP и региона идёт запрос нашего бота?
Все запросы наш краулер делает со своего сервера. Это важно по двум причинам: во-первых, для российских сайтов это близко к реальным условиям пользователя из РФ. Во-вторых, сайты с геоблокировкой у нас измеряются «по-честному». Если нужно измерить TTFB с зарубежной точки — используйте PageSpeed Insights.
Учитываете ли вы HTTP/2 и HTTP/3?
Да. Наш HTTP-клиент согласует протокол через ALPN: HTTP/2, если сервер его поддерживает, HTTP/1.1 — если нет. HTTP/3 пока не согласуется. На практике на TTFB разница между HTTP/1.1 и HTTP/2 для одиночного запроса небольшая — основной выигрыш HTTP/2 виден при множественных одновременных запросах.
Почему TTFB у вас отличается от PageSpeed Insights?
Три причины. Первая — разный регион запроса. Вторая — разный момент замера: мы меряем один раз в момент обхода, PageSpeed берёт агрегированные поле-данные за 28 дней из Chrome UX Report. Третья — PageSpeed может попадать в кэш, которого у нас нет. Используйте наш TTFB как ориентир в моменте, PageSpeed — как усреднённые пользовательские данные.
Меряете ли вы с холодного кэша?
Краулер не использует браузерный кэш и не держит кэш между страницами. Но сервер со своей стороны может закэшировать HTML — если у вас стоит Varnish, Nginx fastcgi_cache или CDN с edge-кэшем, то первый запрос к конкретному URL будет «холодным», а следующие — «горячими».
Можно ли сравнить два обхода по TTFB?
Да, через раздел «Сравнение» на тарифе Pro. Выберите два обхода — система покажет, как изменился средний TTFB, сколько страниц улучшилось, сколько ухудшилось, и какие конкретно URL стали медленнее. Это удобно после деплоя оптимизаций.
Влияет ли GZIP на TTFB в вашем замере?
Незначительно. TTFB — это время до первого байта. GZIP влияет на время передачи всего тела ответа, но первый байт сервер может начать отдавать, как только готов HTTP-заголовок. Наш клиент поддерживает gzip и brotli в Accept-Encoding.
Как CDN отражается на TTFB в SEO Crawler?
Для статики CDN почти всегда улучшает TTFB — файл отдаётся с ближайшей edge-точки. Для динамического HTML выигрыш зависит от настроек edge-кэширования: если кэш включён, наш TTFB будет измерять edge, а не origin. Если кэш только для статики, наш замер пойдёт до origin через CDN как прокси.
Почему TTFB разный у разных страниц одного сайта?
Три типовых причины. Первая — кэш: главная часто в hot-кэше, а редко посещаемая статья — в холодном. Вторая — сложность запроса к БД. Третья — CMS-шаблон: на странице товара может быть 10 join-ов к БД, на about-нас — один. Откройте таблицу «Все страницы» и отсортируйте по TTFB — там сразу видно, какие разделы тормозят.