Проверка скорости и редиректов в SEO Crawler

TTFB, размер HTML, цепочки редиректов — где смотреть в отчёте и как выгрузить медленные URL

Скорость сайта SEO Crawler проверяет с серверной стороны: на каждой странице мы замеряем TTFB (время ответа), размер HTML-тела и длину цепочки редиректов. Все три показателя собраны на вкладке «Скорость» отчёта аудита — вместе они дают быструю карту того, какие разделы сайта тормозят, а какие в порядке.

Где посмотреть. Дашборд → откройте обход → вкладка «Скорость». В шапке — средний TTFB по сайту, ниже — распределение по порогам Google, блок с самыми медленными страницами и таблица редиректов. Детально по каждому URL — на вкладке «Все страницы», колонка TTFB.

Вкладка Скорость в отчёте SEO Crawler с картой распределения TTFB и списком медленных страниц — Вкладка «Скорость»: распределение TTFB по зонам Google, размер страниц, редиректы и список самых медленных URL.

TTFB — кратко

TTFB (Time to First Byte) — время от отправки HTTP-запроса до получения первого байта ответа. В SEO Crawler мы меряем его для каждой страницы во время обхода и группируем по порогам Google: < 800 мс — хорошо, 800–1800 мс — требует оптимизации, > 1800 мс — критично.

TTFB	Оценка	Где учитывается
< 800 мс	Хорошо	Зелёная зона в распределении
800–1800 мс	Требует оптимизации	Жёлтая зона, попадает на лист Slow TTFB в XLSX
> 1800 мс	Критично	Красная зона, влияет на Health Score

Хотите детально? Как именно мы считаем TTFB, с какого сервера идёт запрос, чем наш замер отличается от PageSpeed и как разводить сетевую задержку от серверной — отдельная статья Как SEO Crawler измеряет TTFB. Там же — разовый чекер TTFB для одного URL.

Размер HTML-страницы

Для каждого URL SEO Crawler записывает в page_size_bytes реальный размер HTML-тела после распаковки gzip/brotli. Это именно размер HTML — картинки, CSS и JS в него не входят, краулер не скачивает их отдельно. Наш порог «тяжёлой страницы» — 500 КБ (512 000 байт): всё, что больше, попадает в карточку «Heavy page» и на лист XLSX.

Размер HTML	Оценка	Что обычно внутри
до 100 КБ	Лёгкая	Статья блога, карточка товара, главная с чистой разметкой
100–300 КБ	Средняя	Категория с листингом, страница с галереей, лендинг с секциями
300–500 КБ	Повышенный	Длинный лендинг, каталог с большим числом товаров, много SVG
> 500 КБ	Тяжёлая — порог SEO Crawler	Инлайновые стили в каждом элементе, JSON-дампы в script, избыточная разметка

Таблица самых тяжёлых страниц в отчёте SEO Crawler с колонкой page_size_bytes — Блок «Тяжёлые страницы» на вкладке «Скорость»: URL с page_size_bytes > 500 КБ, отсортированные по убыванию размера.

Почему размер HTML важен для SEO:

Парсинг. Поисковик строит DOM из HTML. Чем больше файл — тем дольше парсинг и тем позже стартуют загрузка CSS и исполнение JS. На LCP это влияет напрямую.
Crawl budget. Googlebot выделяет на обход сайта ограниченный бюджет по байтам. Тяжёлые страницы «съедают» его быстрее — на сайтах с десятками тысяч URL это критично.
Мобильная аудитория. На 3G/4G загрузка 500 КБ HTML занимает секунды. Это до того, как начнут грузиться CSS и картинки.

Цепочки редиректов

Редирект — это промежуточный HTTP-ответ с кодом 3xx и заголовком Location, который говорит браузеру (и боту) пойти на другой URL. Краулер следует за редиректами до финальной страницы и записывает длину цепочки в redirect_count, а сам маршрут — в redirect_chain.

Длина цепочки	Оценка SEO Crawler	Типичный пример
0 редиректов	Идеально	URL сразу отдаёт 200 OK
1 редирект	Нормально	http→https, www→без www, склейка старого URL на новый
2 редиректа	Повод починить	http→https→финальный URL — лишний хоп
3+ редиректа	Критично — попадает в отчёт	http→www→https→слеш — раздутые правила перезаписи

Раздел Редиректы на вкладке Скорость с картой длинных цепочек и карточкой Redirect loops — Раздел «Редиректы» на вкладке «Скорость». Карточки «Длинные цепочки» и «Redirect loops» подсвечиваются, если в обходе нашлись проблемные URL.

Почему лишние редиректы — это плохо:

Задержка. Каждый хоп — это новый DNS-lookup (если домен другой), TCP-хендшейк (если это новый хост), TLS-хендшейк (для HTTPS) и собственно запрос. В сумме 50–500 мс на каждый редирект.
Потеря ссылочного веса. Google формально утверждает, что через 301 вес передаётся полностью, но на длинных цепочках (3+) на практике вес «сыпется». YandexBot и вовсе может не дойти до финала.
Crawl budget. Бот тратит один слот на каждый промежуточный URL. Если у вас 10 000 URL и все они через 3 редиректа — краулер тратит 40 000 запросов вместо 10 000.

Цель — один редирект максимум. Самые частые «лишние» хопы: http → http www → https www вместо прямого http → https www. Исправьте одним правилом в Nginx/Apache, которое сразу переводит любой вариант на итоговый URL. Проверить отдельный URL можно в инструменте проверки редиректов.

Redirect loops

Отдельный случай — замкнутая цепочка, когда URL в итоге редиректит сам на себя (прямо или через посредников). Краулер определяет это по повторению URL в цепочке: если во время прохода мы уже видели этот адрес, значит это loop. Страница помечается флагом has_redirect_loop = true, и дальнейший обход по этой цепочке прерывается.

Классические причины redirect loop:

Два конфликтующих правила редиректа — одно гонит на www, другое убирает www;
Редирект на страницу, которая сама редиректит на исходный URL (cookie-проверка, которая не срабатывает для ботов);
Canonical, указывающий на URL, который 301-редиректит обратно — Googlebot такое частично переваривает, наш краулер честно помечает как loop;
Локализация через прокси, которая зациклилась между языковыми версиями.

Детали страницы с redirect loop в отчёте SEO Crawler: цепочка URL и причина ошибки — Карточка URL с флагом `has_redirect_loop`. В деталях — полная цепочка редиректов до момента, когда мы обнаружили повторение.

HTTPS, HTTP-протокол и сжатие

Дополнительно SEO Crawler отрабатывает несколько «гигиенических» проверок, которые влияют на общую оценку скорости и безопасности.

HTTPS. Наш краулер отдельно проверяет SSL: валидность сертификата, срок действия, mixed content (запросы на http-ресурсы с https-страниц). Это относится к разделу «Безопасность», но на скорость влияет косвенно — устаревший TLS-сертификат и медленный handshake замедляют TTFB. Подробнее — в справке про ссылки и canonical, блок «Mixed content».
HTTP-протокол. Клиент (на curl_cffi с Chrome-impersonation) согласует протокол через ALPN: HTTP/2, если сервер поддерживает, иначе HTTP/1.1. HTTP/3 пока не используем. На одиночный TTFB разница между 1.1 и 2 небольшая.
Сжатие. В Accept-Encoding мы всегда передаём gzip и brotli. Если сервер отдаёт сжатый ответ — распаковываем и пишем в page_size_bytes реальный размер. Если сервер не умеет сжимать — это отдельно в отчёте не отмечается, но размер страницы будет заметно больше, чем мог бы быть.

Фильтрация медленных страниц в UI

Найти именно медленные URL в отчёте можно двумя путями.

Через вкладку «Скорость»

Открыть обход → вкладка «Скорость».
Кликнуть по карточке «Требует оптимизации» (жёлтая) или «Критично» (красная) в блоке распределения TTFB.
Ниже раскроется отфильтрованная таблица — только URL из выбранной зоны.
Кнопка экспорта над таблицей выгружает отфильтрованный набор в CSV/XLSX.

Через блок «Самые медленные страницы»

На вкладке «Скорость» ниже распределения TTFB есть таблица «Самые медленные страницы» с колонками URL, TTFB, график, оценка, размер и глубина. Она уже отсортирована от самого медленного URL к самому быстрому — удобно, когда нужен не фильтр по порогу, а взгляд на топ-10 проблем.

Таблица Самые медленные страницы на вкладке Скорость с колонками TTFB, график, оценка, размер и глубина — Таблица «Самые медленные страницы» на вкладке «Скорость». Колонки *TTFB*, *Размер* и *Глуб.* сразу показывают, какие разделы сайта системно тормозят.

Экспорт скоростных проблем в XLSX

Кнопка XLSX в шапке отчёта собирает все проблемы в Excel. По скорости полезны три листа:

Лист в XLSX	Что внутри
`Slow TTFB >800ms`	Все URL с временем ответа больше 800 мс, отсортированные по убыванию TTFB
`Redirects`	Все URL с редиректами: колонки `redirect_count`, `has_redirect_loop`, `redirect_chain` с полным маршрутом
`All pages`	Все URL с колонками `response_time_ms`, `page_size_bytes`, `redirect_count` и остальными метриками

Практика: выгрузите XLSX, откройте All pages, отсортируйте по response_time_ms по убыванию и передайте топ-20 бэкенд-разработчику. В колонке page_size_bytes он сразу увидит, связана ли проблема с тяжёлым HTML или с долгой генерацией на сервере. Лист Redirects уходит отдельно — его чинит DevOps через правила на фронте Nginx.

Подробнее обо всех листах и форматах — в разделе Экспорт CSV / XLSX / PDF.

Что делать после правок

После того как включили кэш, оптимизировали SQL-запросы и перенастроили редиректы — запустите повторный обход и сравните три показателя:

Средний TTFB по сайту. В шапке вкладки «Скорость». Должен уменьшиться. Если не уменьшился — проблема не в тех URL, которые вы чинили, а где-то ещё.
Число страниц в жёлтой и красной зонах TTFB. В блоке распределения. Жёлтая должна перейти в зелёную, красная — минимум в жёлтую.
Длина цепочек редиректов. На листе Redirects в XLSX: отфильтруйте redirect_count > 1 — после правок таких URL должно не остаться.

На тарифе Pro есть сравнение двух обходов — оно само покажет дельту по каждому URL и подсветит страницы, где TTFB вырос или упал. Удобно сразу после деплоя оптимизации — за 5 минут видно, сработало или нет.

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

В чём разница между TTFB и LCP и что важнее для ранжирования?

TTFB — это серверное время: сколько сервер готовил HTML. LCP — клиентская метрика: когда на экране пользователя появился основной контент. Google в Core Web Vitals учитывает LCP как фактор ранжирования, а TTFB — как часть его «медленной зоны». Но LCP почти всегда упирается в TTFB: если сервер отдал HTML за 2 секунды, никакой фронтенд не даст хорошего LCP. Мы меряем TTFB потому, что это самая ремонтопригодная часть скорости — её чинит бэкенд, а не дизайнер.

Размер HTML мы меряем до или после GZIP?

После распаковки — то есть реальный размер HTML-тела, как его видит парсер. Краулер поддерживает gzip и brotli в Accept-Encoding; если сервер отдал сжатый ответ, мы его распаковываем и в page_size_bytes записываем уже «развёрнутый» размер. Это правильная метрика для SEO: поисковик видит именно этот размер, когда строит DOM. Сжатый размер важен для трафика, но не для краулинга.

Почему вы не меряете полное время загрузки страницы?

Потому что мы не браузер. Полное время — это DOMContentLoaded, загрузка картинок, исполнение JS, рендер. Для этого нужен headless Chromium с обходом по каждому URL — это в 50 раз медленнее и дороже. Наша задача — проверить серверную часть сайта на большом числе URL (сотни и тысячи страниц). Для полного рендерного замера отдельных URL используйте PageSpeed Insights или WebPageTest — они как раз заточены под клиентские метрики.

Влияет ли CDN на TTFB в нашем замере?

Да, и сильно. Если CDN кэширует HTML на edge (например, Cloudflare с правилом Cache Everything), наш TTFB — это время от нашего сервера до ближайшей edge-точки CDN, обычно 50–200 мс. Если CDN работает только как прокси для origin (HTML на edge не кэшируется), наш замер пойдёт до origin через CDN — будет показывать реальное время генерации плюс сетевую дистанцию. Для статики CDN почти всегда выигрывает, для динамики — зависит от настроек edge-кэширования.

Как уменьшить цепочку редиректов?

Перепишите правила так, чтобы конечный URL достигался за один прыжок. Классический пример раздутой цепочки: http://site.com → http://www.site.com → https://www.site.com → https://www.site.com/page/. Четыре хопа, ~400 мс задержки. Правильный вариант: единое правило в Nginx или Apache, которое сразу переводит любой вариант на итоговый https://www.site.com/page/. В SEO Crawler проверить можно нашим инструментом /tools/redirects или в отчёте аудита — на вкладке «Скорость».

Цепочка 301 → 301 → 200 — это плохо?

Два редиректа вместо одного — не катастрофа, но устранимо. Каждый 301 добавляет 50–300 мс сетевой задержки и небольшую потерю ссылочного веса (исторически Google говорил про 10–15% потери, сейчас ближе к 0, но риск остаётся). SEO Crawler считает любую цепочку длиной больше 1 как повод обратить внимание. Если редиректов 3 и больше — это уже попадает в карточку «Redirect loops / длинные цепочки» на вкладке «Скорость».

Где в отчёте посмотреть самые медленные страницы?

Два места. Первое — вкладка «Скорость»: сразу под распределением TTFB есть таблица «Самые медленные страницы» с колонками URL, TTFB, график оценки, размер и глубина. Она уже отсортирована от самых медленных к быстрым. Второе — XLSX-экспорт: на листе Slow TTFB >800ms лежат все URL, у которых время ответа превысило 800 мс, отсортированные по убыванию TTFB. UI удобен для быстрого взгляда на топ, XLSX — для полного списка.

Можно ли сравнить скорость своего сайта со скоростью конкурента?

Напрямую нет — у нас нет «чужого сайта» как фичи, и пробный обход конкурента не даёт полную картину (часто крупные сайты защищены от ботов). Но вы можете запустить обход конкурента через SEO Crawler как любой другой сайт (в рамках лимитов вашего тарифа и при отсутствии блокировок) и сравнить числа визуально. Для разовой точечной проверки одного URL против другого используйте инструмент /tools/ttfb — он меряет время ответа без полного обхода.

Что больше всего влияет на размер HTML-страницы?

По нашему опыту четыре источника. Первый — инлайновые стили в каждом элементе (style="color:red"): на длинных каталогах лёгко уводят в +200 КБ. Второй — огромные SVG-иконки, зашитые в HTML вместо <use xlink:href>. Третий — JSON-конфиги, инжектируемые в <script type="application/json"> для фронтенд-фреймворков. Четвёртый — избыточная разметка: 5 div-обёрток там, где хватит одного. Смотрите в отчёте страницы с page_size_bytes > 500 КБ и начинайте с них.

Когда SEO Crawler обнаруживает redirect loop?

Когда во время прохождения цепочки редиректов мы встречаем URL, который уже был в этой цепочке — это замкнутый цикл. Обычно это происходит, когда неправильно настроено правило HTTPS/www: одно правило гонит на www, другое — без www. Краулер прерывает такой обход и помечает страницу флагом has_redirect_loop. В отчёте аудита такие URL видны на вкладке «Скорость» в карточке «Redirect loops» и попадают на лист Redirects в XLSX с пометкой has_redirect_loop=yes.