Скорость сайта: TTFB, LCP, CLS и INP по-русски, с порогами

Скорость — один из немногих факторов, который одновременно влияет на позиции (Яндекс тратит краулинговый бюджет, Google считает Core Web Vitals), на конверсию (каждая секунда загрузки на мобильном стоит проценты конверсии) и на попадание в ответы нейросетей (медленную страницу ИИ-краулер может просто не дочитать). При этом «сайт тормозит» — не диагноз, а симптом четырёх разных болезней.

Короткий ответ: сначала серверное время ответа (TTFB < 800 мс), потом загрузка главного контента (LCP < 2,5 с), потом стабильность вёрстки (CLS < 0,1) и отзывчивость на клики (INP < 200 мс). Порядок именно такой, потому что каждый следующий пункт бессмысленно лечить при больном предыдущем.

Четыре метрики и что они измеряют

Метрика	Что измеряет	Хороший порог	Плохой	Кто это видит
TTFB (Time To First Byte)	Время до первого байта от сервера	<800 мс	>2000 мс	Роботы, все пользователи
LCP (Largest Contentful Paint)	Появление главного контента (картинка/заголовок)	<2,5 с	>4 с	Пользователь в первую секунду
CLS (Cumulative Layout Shift)	Скачки вёрстки при загрузке	<0,1	>0,25	Все, особенно мобильные
INP (Interaction to Next Paint)	Задержка отклика на действия	<200 мс	>500 мс	Активные пользователи

TTFB — «входная дверь»: пока она медленная, всё остальное (картинки, скрипты) едет по забитому коридору. TTFB — единственная метрика, которую Яндекс видит напрямую и по которой расходует бюджет обхода: медленный сервер = реже заходят роботы = медленнее попадают в индекс новые страницы.

TTFB: 90% случаев — это отсутствие кэша HTML

Типовая российская ситуация: WordPress на виртуальном хостинге, каждый запрос собирает страницу заново — 1,5–3 секунды только на TTFB. Лечение по нарастающей:

1. Плагин серверного кэша страниц (WP Super Cache, WP Fastest Cache и аналоги) — превращает динамическую страницу в готовый файл. Эффект: TTFB с 2 секунд до 200–400 мс. Это одна правка, закрывающая 80% проблем.

2. Кэш объектов и оптимизация базы (Redis, чистка транзиентов) — для магазинов на WooCommerce.

3. Переезд на VPS с правильным веб-сервером (nginx + FastCGI-кэш) — когда хостинг упёрся.

4. CDN — если аудитория по всей стране и сервер один.

Проверить, работает ли у вас кэш, просто: обновите страницу 3 раза подряд и посмотрите время ответа в инструментах разработчика (Сеть → Время). Первый заход медленный, остальные быстрые — кэш есть. Все медленные — кэша нет.

LCP: что мешает главному контенту появиться

Частые виновники в порядке статистики наших аудитов:

• Картинка-герой весом 2–4 МБ → сжатие в WebP, правильный размер под экран, preload главного изображения.
• Шрифты, блокирующие отрисовку → font-display: swap, загрузка одного-двух начертаний.
• CSS/JS в голове страницы → вынос некритичных скриптов в конец или с defer.
• Реклама и виджеты раньше контента → отложенная загрузка всего, что не нужно в первом экране.
• Серверный рендер отсутствует (SPA ждёт API) → SSR или пререндер.

Один практический приём: откройте страницу на мобильном интернете (не в офисном Wi-Fi) и засеките, через сколько секунд вы видите заголовок и первую картинку. Это и есть ваш LCP на глаз.

CLS: когда кнопки «уезжают» из-под пальца

CLS — метрика раздражения: пользователь целится в кнопку, а страница прыгает. Причины почти всегда одни:

1. Картинки без width/height → браузер не резервирует место.

2. Рекламные блоки, вставляющиеся позже контента.

3. Шрифты, подменяющие размеры текста при загрузке.

4. Баннеры и push-виджеты, выезжающие сверху.

Лечение механическое: каждому <img> — размеры или aspect-ratio; рекламным слотам — фиксированная высота; шрифтам — запас места под размер.

INP: скрипты, которые думают за вас

INP (пришёл на смену FID) измеряет, как быстро страница отвечает на любое действие: тап, ввод, клик. Плохой INP — это тяжёлый JavaScript: слайдеры, чаты, A/B-скрипты, аналитика с синхронной инициализацией. Лечится разбивкой длинных задач, выносом тяжёлых скриптов в воркеры и вычищением неиспользуемых библиотек. Честно: на большинстве контентных сайтов INP нормальный без спецработ — эта метрика болит у приложений и сложных каталогов.

Пороги для России: какие цели ставить

Смотреть стоит на две картины: лабораторную (замер тут и сейчас, как в PageSpeed Insights) и полевую (реальные пользователи, те же CWV в Search Console). Лабораторная — для отладки, полевая — для оценки «правды». Цели по полевым данным: 75% сессий лучше порога. Если полевые данные отсутствуют (мало трафика) — гоняйтесь за лабораторными, но с запасом.

Ситуация	Приоритет
TTFB > 2 с	Всё остальное не имеет смысла: сначала серверный кэш
TTFB ок, LCP > 4 с	Картинки, шрифты, блокирующие ресурсы
LCP ок, CLS > 0,25	Размеры картинок и слотов
Всё ок, INP > 500 мс	Аудит скриптов, обычно на SPA

Как замерять без покупки инструментов

1. PageSpeed Insights — один прогон мобильной и десктопной версии. Внимание: бесплатная квота API ограничена, для регулярного контроля берите данные из Search Console.

2. Search Console → Core Web Vitals — полевые данные по реальным пользователям Google.

3. curl -w "%{time_starttransfer}" — TTFB любой страницы из терминала, честно и без лабораторных искажений.

4. Аудит INSONT — TTFB по нескольким страницам сайта сразу, с порогами и рекомендациями в отчёте.

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

Скорость влияет на позиции в Яндексе? Прямо — как фактор обхода и качества; косвенно — через поведенческие: медленный сайт = отказы. Влияет и на ИИ-видимость: краулеры моделей не ждут медленных страниц.

Какие 2 часа дают максимум? Серверный кэш HTML + сжатие картинок в WebP с размерами. Это закрывает TTFB, LCP и половину CLS у 7 сайтов из 10.

Нужен ли идеальный 100/100 в PSI? Нет. После выхода на «зелёные» пороги полевых данных дальнейшая оптимизация — про конверсию и экономию трафика, а не про SEO.

Практикум: час оптимизации типового сайта

Реальный порядок работ, который мы применяем на типовых CMS-сайтах (цифры — усреднённые результаты таких часов).

Минута 0–10: замер «до». TTFB — 1,9 с; LCP мобильный — 4,8 с; вес главной — 3,8 МБ; картинок в первом экране — 4, суммарно 2,9 МБ. Фиксируем: без этого «стало быстрее» будет мнением.

Минута 10–25: серверный кэш. Включение страничного кэша и кэша объектов. TTFB — 320 мс. Одна правка сняла полторы секунды у всех посетителей и всех роботов.

Минута 25–40: картинки. Конвертация первого экрана в WebP с ресайзом под реальные размеры (1600 px вместо 4000), preload главного баннера, ленивая загрузка остальных. LCP — 2,3 с; вес — 1,1 МБ.

Минута 40–50: шрифты и скрипты. font-display: swap, два начертания вместо пяти, две сторонние библиотеки — в defer. CLS упал с 0,19 до 0,04 за счёт размеров картинок и резерва под шрифт.

Минута 50–60: контрольный замер и запись в таблицу «до/после». Итог часа: TTFB −83%, LCP −52%, CLS в зелёной зоне. Дальше — полевые данные через 2–3 недели в Search Console подтверждают (или нет) эффект у реальных пользователей.

Метрика	До	После часа работ
TTFB	1 900 мс	320 мс
LCP мобильный	4,8 с	2,3 с
CLS	0,19	0,04
Вес главной	3,8 МБ	1,1 МБ
Роботов-обходов в день (Вебмастер)	Рост на 40% через 2 недели	—

Словарь скорости

• TTFB — время до первого байта: работа сервера до начала передачи страницы.
• LCP — появление крупнейшего элемента экрана: главная картинка или заголовок.
• CLS — сумма скачков вёрстки за время загрузки.
• INP — худшая задержка отклика на действия пользователя.
• Серверный кэш HTML — готовые страницы отдаются без обращения к CMS.
• Preload — приоритетная загрузка критического ресурса (например, картинки первого экрана).
• WebP — современный формат картинок: на 25–35% легче JPEG при том же качестве.
• Defer — отложенное выполнение скриптов после построения страницы.

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

Мини-словарь и мифы скорости

Миф 1: «Скорость важна только Google». Нет: Яндекс прямо связывает скорость с качеством и краулинговым бюджетом, а ИИ-краулеры просто не дочитывают медленные страницы.

Миф 2: «Оценка 100 в PSI решает всё». Лабораторные 100 на быстром офисском интернете не означают полевого зелёного цвета у пользователей на 4G. Ориентируйтесь на полевые данные (CrUX/GSC).

Миф 3: «CDN ускоряет любой сайт». Если TTFB большой из-за отсутствия кэша и тяжёлой CMS, CDN лишь довезёт медленный ответ до пользователя быстрее. Сначала кэш и оптимизация бэкенда.

Миф 4: «Картинки уже сжаты, больше нечего жать». На типовых сайтах картинки — 60–80% веса страницы. WebP, правильные размеры и lazy для второго экрана — самые «дешёвые» секунды в оптимизации.

Что замерять еженедельно

Одна строка в таблице: дата, TTFB главной, TTFB категории, LCP мобильный (лабораторно), вес главной. Четыре цифры за две минуты — и деградация после очередного обновления CMS видна на следующий день, а не через месяц по падению позиций.

Кейс деградации: как скорость «утекает» после обновлений

Знакомая история: сайт разогнали до зелёных метрик, через полгода он снова медленный. Разбор обычно находит: (1) новое маркетинговое видео в первом экране — 8 МБ и LCP 5 секунд; (2) три новых скрипта аналитики и A/B-тестов — INP в красном; (3) каталог вырос, кэш перестал справляться — TTFB уполз за секунду. Лечение — не героическая повторная оптимизация, а регламент: еженедельные четыре цифры (TTFB главной, LCP мобильный, вес, INP) и правило «новый скрипт/видео — только с замером до/после». Скорость — это не проект, а гигиена.

Хостинг: когда оптимизация упирается в железо

Если после кэша и картинок TTFB держится выше секунды — вопрос не к сайту, а к хостингу. Типовые пороги деградации: дешёвый виртуальный хостинг при росте трафика; сосед по серверу, съевший ресурсы; база данных, разросшаяся за годы; SSL-сертификат с медленным рукопожатием. Проверка простая: один и тот же сайт на текущем хостинге и на чистом VPS с тем же кодом — если разница в разы, бюджет оптимизации правильнее вложить в переезд, а не в третью итерацию «оптимизации кода». Переезд обычно окупается за пару месяцев экономией на инженерных часах.

Резюме по приоритетам

Порядок лечения всегда один: TTFB (кэш) → картинки (WebP и размеры) → шрифты и скрипты → точечные метрики (INP). Две первые правки дают 80% эффекта за 20% времени. Замер до и после — обязательная часть каждой правки: скорость без цифр — это вкусовщина. И помните про полевые данные: лаборатория для диагностики, CrUX — для истины.

Одна история про две секунды

Онлайн-магазин расходников для принтеров получил от нас классический диагноз: TTFB 2,3 секунды из-за отсутствия кэша, LCP 5,1 секунды из-за тяжёлого шаблона с фотографиями. Владелец в это время планировал бюджет на «SEO-статьи», потому что «сайт есть, а клиентов нет». Мы настояли на обратном порядке: сначала кэш и сжатие картинок (два дня работ разработчика), статьи — потом.

Результат вышел поучительный в обе стороны. Через месяц после правок TTFB стал 380 мс, LCP — 2,2 секунды, и органический трафик вырос на 12% без единой новой страницы: роботы стали чаще обходить каталог, а люди — реже отскакивать. Но дальше произошло показательное: владелец законтрактовал те же статьи, и они наконец «поехали» — новые страницы стали попадать в индекс за два-три дня вместо трёх недель. Мораль: скорость — это не «технический пункт отчёта», это коэффициент полезного действия всего остального SEO. Сначала пропускная способность, потом контент — иначе вы поливаете цветы через закрытый кран.