Как ускорить сайт в 2026: TTFB и Core Web Vitals

Core Web Vitals — три метрики пользовательского опыта, которые Google учитывает при ранжировании с 2021 года. В марте 2024 одна из них поменялась: FID заменён на INP, и многие русскоязычные гайды ещё этого не отразили. TTFB — отдельная техническая метрика, от которой напрямую зависит LCP, а значит и оценка Core Web Vitals.

В гайде разбираем, что измеряет каждая метрика, какие пороги считаются нормальными, чем их замерять (PageSpeed Insights, CrUX, Search Console, SEO Crawler) и как реально улучшить каждую — с примерами HTTP-заголовков, HTML-разметки и конкретных шагов. Отдельно — разоблачение ситуации «PSI показывает 30, а сайт быстрый».

Почему скорость сайта важна для SEO

Core Web Vitals — подтверждённый фактор ранжирования Google. Не решающий — сильный релевантный контент на медленном сайте всё ещё обойдёт слабый на быстром, — но в конкурентных нишах разница в миллисекундах определяет, кто выше. Page Experience у Google включает в себя мобильную адаптивность, безопасность соединения и именно Core Web Vitals.

Есть и второй эффект, уже поведенческий. Чем медленнее сайт, тем выше процент отказов: по исследованиям Google, при росте задержки загрузки с 1 до 3 секунд вероятность отказа значимо увеличивается. Отказы ухудшают поведенческие сигналы, которые учитываются при ранжировании. Медленный сайт бьёт по позициям дважды — напрямую через Core Web Vitals и косвенно через отказы.

Яндекс также учитывает скорость, хотя формула менее публична, чем у Google. Для обеих систем — быстрый сайт выгоднее. Подробнее о других сигналах качества сайта — в чек-листе SEO-аудита.

Что такое Core Web Vitals: LCP, INP, CLS

Google измеряет пользовательский опыт тремя конкретными метриками. Все три собираются на реальных пользователях через поле CrUX (Chrome UX Report), а не в лабораторных условиях.

LCP — Largest Contentful Paint

Время до отрисовки самого крупного элемента на первом экране. Обычно это hero-изображение, заголовок или видео-preview. Если LCP долгий — пользователь видит пустую страницу, это воспринимается как «сайт тормозит».

LCP зависит от трёх факторов: TTFB (сколько ждёт первый байт), загрузка ресурсов (картинки, шрифты, CSS), рендеринг (блокирующий JS).

INP — Interaction to Next Paint

С 12 марта 2024 — основная метрика интерактивности вместо FID. FID измерял только первое взаимодействие пользователя со страницей; INP берёт одно из самых долгих среди всех взаимодействий за сессию (конкретно — близкое к 98-му перцентилю). Это более честная оценка: если сайт быстро реагирует на первый клик, но тормозит на открытии меню через 5 секунд, INP это покажет, FID — нет.

INP включает время от клика/тапа до обновления экрана. Считается клик, нажатие клавиши, тап — не прокрутка и не наведение мыши.

CLS — Cumulative Layout Shift

Сумма смещений элементов на странице в процессе загрузки. Когда пользователь собирается кликнуть на кнопку, а реклама подгружается сверху и кнопка уезжает — это CLS. Метрика измеряется за всё время загрузки, а не только при инициализации.

TTFB: базовая метрика

TTFB (Time to First Byte) — время от отправки HTTP-запроса до получения первого байта ответа. Технически не входит в Core Web Vitals, но влияет на LCP напрямую: если сервер 2 секунды генерирует HTML, LCP не может быть лучше двух секунд.

TTFB состоит из четырёх частей: DNS-lookup (поиск IP по домену), TLS-handshake (установка HTTPS), обработка запроса на сервере (приложение + БД), отдача первого байта. На практике основная доля — работа бэкенда.

Для SEO важно одно: высокий TTFB автоматически тянет за собой плохой LCP, а значит и плохую общую оценку Core Web Vitals. Измерение TTFB по всему сайту — первый шаг оптимизации производительности. Проверка TTFB в SEO Crawler замеряет метрику сразу по всем страницам и выдаёт список медленных.

Пороги Good / Needs Improvement / Poor

Google публикует конкретные числовые пороги для каждой метрики. Оценка считается по 75-му перцентилю — то есть у 75% пользователей метрика должна быть в зелёной зоне.

«Good» — зелёная зона в PageSpeed Insights. «Needs Improvement» — жёлтая. «Poor» — красная. Для Page Experience Google требует зелёной зоны по всем трём CWV (LCP, INP, CLS).

Чем измерять: PageSpeed Insights, CrUX, Search Console

Есть четыре способа получить оценку Core Web Vitals. У каждого свой источник данных и случай применения.

PageSpeed Insights — основной инструмент для проверки одного URL. Показывает и полевые данные (из Chrome), и лабораторные (Lighthouse). Мобильная оценка отображается первой — и это правильно, потому что Google индексирует по мобильной версии.

Search Console → отчёт «Core Web Vitals» показывает, какие группы URL на сайте в зелёной/жёлтой/красной зоне. Подходит для поиска проблемных разделов. Данные — за 28 дней, отстают от реального состояния сайта.

CrUX Dashboard — BigQuery-отчёт на сырых данных, нужен для аналитиков. Обычному SEO-специалисту хватит PSI и Search Console.

SEO Crawler добавляет четвёртый сценарий: обход всего сайта с замером TTFB по каждой странице. Удобно, когда нужно понять, какие страницы медленные, а не получить оценку одной.

Как снизить TTFB

TTFB — это ответственность бэкенда и хостинга. Фронтенд-оптимизации на TTFB не влияют.

Оценить текущее состояние

Хороший TTFB — до 800 мс. Если выше 1800 мс — сервер отвечает медленно, пользовательский опыт страдает, Core Web Vitals в красной зоне. Перед оптимизацией нужно понять, где узкое место: в хостинге, в приложении, в базе, в геолокации.

Хостинг и CDN

Если сайт на дешёвом shared-хостинге и TTFB 2+ секунды — первое, что стоит сделать, — переехать на VPS или managed-решение. Shared-хостинг делит ресурсы между сотнями клиентов, и нагрузка соседа бьёт по скорости вашего сайта.

CDN (Content Delivery Network) помогает, если пользователи распределены по географии. Статика отдаётся с ближайшего узла, TTFB для картинок и CSS падает в разы. Для HTML на динамическом сайте CDN не так эффективен — HTML генерируется один раз на сервере происхождения.

Кеширование

Страничный кеш отдаёт готовый HTML вместо того, чтобы пересобирать его из БД на каждом запросе. Для WordPress — WP Rocket или W3 Total Cache. Для Bitrix — встроенный кеш «Композит». Для Django/Rails — Redis/Memcached на уровне view. TTFB закешированной страницы — обычно 50–200 мс.

Сжатие ответов

HTTP-заголовок Content-Encoding: gzip или br (Brotli) сокращает размер HTML в 4–6 раз. Настраивается в nginx:

gzip on;
gzip_types text/plain text/css application/javascript application/json;
gzip_min_length 1000;

Для HTTPS предпочтителен Brotli — сжимает сильнее gzip. Поддерживается всеми современными браузерами.

Заголовки кеширования для статики

Cache-Control: public, max-age=31536000, immutable

Файл будет закеширован на год. Применяется для версионированных статических ресурсов (styles.v2.css, app.abc123.js) — при изменении просто меняется имя файла.

Медленный бэкенд

Если страница выполняет 50 SQL-запросов, никакой CDN не спасёт. Признаки: TTFB плавающий, днём выше, чем ночью; падает при росте трафика. Решение — профилировать код, добавить индексы в БД, оптимизировать N+1-запросы. Это уже не SEO-задача, а инженерная — но без неё Core Web Vitals не улучшить.

Как улучшить LCP

LCP = TTFB + загрузка LCP-ресурса + рендеринг. Если TTFB в норме, фокус — на загрузке главного элемента первого экрана.

Preload hero-изображения

<link rel="preload" as="image" href="/static/hero.webp" fetchpriority="high">

Браузер начнёт скачивать картинку параллельно с парсингом HTML, а не после нахождения тега <img>. Работает только для LCP-элемента — не навешивайте preload на всё подряд.

Preconnect к CDN и сторонним доменам

<link rel="preconnect" href="https://cdn.example.com">
<link rel="preconnect" href="https://fonts.googleapis.com">

Устанавливает TLS-соединение заранее, пока идёт парсинг HTML. Экономит 100–300 мс на первом запросе.

Современный формат картинок

WebP на 25–35% легче JPEG, AVIF — ещё на 20–30% легче WebP. Для hero-картинки разница между 300 КБ JPEG и 80 КБ AVIF на мобильном интернете — секунда LCP.

Корректный <img> с размерами

<img src="/hero.webp" alt="" width="1200" height="600" loading="lazy" decoding="async">

Атрибуты width и height нужны, чтобы браузер зарезервировал место до загрузки (бьёт одновременно по LCP и CLS). loading="lazy" — откладывает загрузку картинок вне первого экрана; для самого LCP-элемента лучше loading="eager".

Critical CSS

Стили, нужные для первого экрана, вставляются инлайн в <head>, остальные — подгружаются асинхронно. Убирает блокирующий CSS-запрос, LCP улучшается на 200–500 мс.

Шрифты с font-display: swap

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
}

Текст отрисовывается системным шрифтом, пока подгружается кастомный — не ждём шрифт, показываем контент сразу.

Как улучшить INP

INP — про отзывчивость. Чаще всего страдает из-за тяжёлого JS, который блокирует основной поток.

Уменьшить размер JS-бандла

Каждые 100 КБ JS — это ~300 мс парсинга на среднем мобильном. Убрать неиспользуемые зависимости, включить tree-shaking, разделить на чанки — INP улучшается пропорционально.

Разбить длинные задачи

Задача длиннее 50 мс блокирует основной поток. Используйте requestIdleCallback, setTimeout(fn, 0) или новое API scheduler.postTask для разбиения тяжёлой логики на куски. Браузер сможет отреагировать на клик между ними.

Event handlers не делают тяжёлую работу

Обработчик клика должен сделать минимум: обновить UI, отложить всё остальное. Валидация формы через 100 регулярных выражений при каждом нажатии клавиши — классическая ошибка, убивающая INP.

Гидратация React/Vue

Для SPA на React/Vue гидратация страницы (привязка обработчиков к уже отрендеренному HTML) — основной источник INP-проблем. Решения: серверный рендеринг + island-архитектура, lazy hydration, streaming SSR. Для WordPress и Bitrix это не актуально.

Как избежать CLS

CLS — это сдвиги элементов во время загрузки. Три главных виновника: картинки без размеров, шрифты, динамический контент.

Картинки с width и height

Браузер резервирует место под картинку до её загрузки, если указаны размеры атрибутами или CSS через aspect-ratio. Без этого — картинка появляется и толкает контент вниз. CLS-штраф.

<img src="photo.webp" width="800" height="600" alt="...">

Шрифты с font-display: swap

Если кастомный шрифт загружается дольше HTML, браузер показывает системный. Когда подгружается кастомный — происходит «перекладка» текста, возможен CLS. Смягчить можно комбинацией size-adjust, ascent-override в @font-face, подбирая метрики fallback-шрифта ближе к кастомному.

Рекламные блоки и embed

AdSense, YouTube embed, формы подписки — всё это элементы, которые появляются после загрузки остального контента и толкают страницу вниз. Решение — зарезервировать место:

<div style="aspect-ratio: 16/9; background: #eee;">
  <!-- сюда подставится iframe YouTube -->
</div>

Без изменения layout после клика

Аккордеоны и раскрывающиеся блоки, которые сдвигают контент вниз при раскрытии, — в CLS не входят (это реакция на пользовательское действие). Но если блок раскрывается сам через 500 мс после загрузки — это CLS.

Часто задаваемые вопросы