Core Web Vitals: Полное руководство по оптимизации для SEO (2026)

Core Web Vitals (CWV) — это набор из трёх конкретных метрик производительности страницы, которые Google использует в качестве подтверждённого сигнала ранжирования для оценки реального пользовательского опыта на вашем сайте. Представленные в 2020 году и обновлённые с заменой FID на INP в марте 2024, Core Web Vitals измеряют скорость загрузки основного контента страницы (LCP), быстроту реакции на действия пользователя (INP) и визуальную стабильность во время загрузки (CLS). Вместе эти три метрики определяют, обеспечивает ли ваша страница тот уровень опыта, который ожидают пользователи — и Google.

В 2026 году Core Web Vitals больше не являются опциональными. Они — подтверждённый компонент системы ранжирования Google по качеству страниц и напрямую влияют на то, обойдёте ли вы конкурентов с аналогичным качеством контента и авторитетностью. Более того, они влияют на опыт каждого посетителя вашего сайта. Страница, которая загружается медленно, вяло реагирует на клики или сдвигает контент во время загрузки, отталкивает пользователей — и Google это знает, потому что измеряет именно такое поведение у реальных пользователей Chrome по всему миру через Chrome User Experience Report (CrUX).

Это руководство охватывает всё, что вам нужно знать о Core Web Vitals в 2026 году: что измеряет каждая метрика, почему она важна для SEO и ИИ-поиска, как диагностировать проблемы и как именно их исправить. Независимо от того, являетесь ли вы разработчиком, SEO-специалистом или владельцем сайта, вы найдёте практические стратегии с реальными примерами кода, сравнениями до/после и чётким рабочим процессом оптимизации, который можно внедрить уже сегодня.

Что такое Core Web Vitals?

Core Web Vitals — это три ориентированные на пользователя метрики производительности, которые Google определил как наиболее важные показатели качества страницы. В отличие от традиционных метрик производительности, сфокусированных на технических измерениях (время DNS-запроса, время до первого байта), Core Web Vitals фокусируются на том, что реально ощущают пользователи: насколько быстро страница кажется загруженной? Как быстро она реагирует при нажатии? Прыгает ли макет, пока я пытаюсь читать или взаимодействовать?

Google представил Core Web Vitals в мае 2020 года как часть более широкой инициативы по стандартизации измерения качества страниц. Первоначальные три метрики были: LCP (Largest Contentful Paint), FID (First Input Delay) и CLS (Cumulative Layout Shift). В марте 2024 года Google заменил FID на INP (Interaction to Next Paint), потому что INP обеспечивает более комплексное измерение отзывчивости, фиксируя полный жизненный цикл взаимодействия, а не только начальную задержку ввода.

Ключевое, что нужно понимать о Core Web Vitals, — они измеряются с помощью реальных данных пользователей, а не лабораторных симуляций. Google собирает данные о производительности от миллионов пользователей Chrome, согласившихся на участие в Chrome User Experience Report (CrUX), и использует 75-й перцентиль этих полевых данных для оценки, проходит ли страница каждую метрику. Это означает, что вы не можете «обмануть» Core Web Vitals, оптимизируя только для лабораторных тестов — значение имеет реальный опыт ваших фактических посетителей.

Пороговые значения CWV на одном экране

*TTFB не является Core Web Vital, но это критически важная диагностическая метрика, напрямую влияющая на LCP. Медленный TTFB делает достижение хорошего показателя LCP практически невозможным.

LCP: Largest Contentful Paint

Largest Contentful Paint (LCP) измеряет время, необходимое для завершения рендеринга самого большого видимого элемента контента в области просмотра. Обычно это главное изображение (hero image), крупный текстовый блок, постер видео или фоновое изображение. LCP отвечает на фундаментальный вопрос пользователя: «Загрузился ли уже основной контент?» Хороший LCP составляет 2,5 секунды или менее.

LCP часто является самой сложной для оптимизации метрикой Core Web Vitals, потому что зависит от всей цепочки доставки: времени ответа сервера (TTFB), обнаружения ресурса, загрузки ресурса и рендеринга. Каждая добавленная миллисекунда в любой точке этой цепочки напрямую увеличивает ваш LCP. Поэтому оптимизация LCP требует комплексного подхода — исправление только одного узкого места редко бывает достаточным.

Типичные причины плохого LCP

• Медленное время ответа сервера (TTFB): Если ваш сервер отвечает за 2 секунды, ваш LCP не может быть ниже 2,5 секунд. Задержки серверного рендеринга, запросы к базе данных и отсутствие кэширования — типичные виновники.
• Блокирующие рендеринг ресурсы: CSS- и JavaScript-файлы в <head> блокируют рендеринг до полной загрузки и парсинга. Большие, неминифицированные CSS или синхронные JS-файлы могут задерживать LCP на секунды.
• Неоптимизированные изображения: Главные изображения в формате PNG вместо WebP/AVIF, изображения неправильного размера для области просмотра или изображения, загружаемые без preload-подсказок, заставляют браузер обнаруживать и загружать большие файлы поздно в процессе загрузки.
• Рендеринг на стороне клиента: Одностраничные приложения (React, Vue, Angular), которые рендерят контент полностью на JavaScript, требуют от браузера загрузки, парсинга и выполнения JS до появления любого контента. Это создаёт пустую страницу до инициализации фреймворка.
• Ленивая загрузка LCP-элемента: Неправильное применение loading="lazy" к главному изображению или контенту выше сгиба задерживает его загрузку, потому что браузер ждёт, пока элемент не окажется рядом с областью просмотра.

5 стратегий оптимизации LCP

1. Оптимизируйте время ответа сервера

Снизьте TTFB с помощью серверного кэширования, CDN, обновления хостинга или перехода на edge-рендеринг страниц. Каждое сокращение TTFB на 100 мс напрямую улучшает LCP.

# Nginx — включение gzip-сжатия и кэширования статики
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml;
gzip_min_length 256;

location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

2. Предварительно загрузите LCP-изображение

Сообщите браузеру о LCP-изображении заранее, используя тег <link rel="preload"> в head документа. Это позволяет браузеру начать загрузку изображения до его обнаружения в DOM.

<!-- Предзагрузка hero-изображения для ускорения LCP -->
<link rel="preload" as="image" href="/images/hero.webp"
      type="image/webp" fetchpriority="high">

<!-- Отметьте LCP-изображение fetchpriority -->
<img src="/images/hero.webp" alt="Описание hero"
     width="1200" height="630" fetchpriority="high">

3. Используйте современные форматы изображений

Конвертируйте изображения в формат WebP или AVIF. WebP обычно обеспечивает файлы на 25-35% меньше, чем JPEG при эквивалентном качестве, а AVIF может сократить размер файла до 50%. Используйте элемент <picture> для прогрессивного улучшения.

<picture>
  <source srcset="/images/hero.avif" type="image/avif">
  <source srcset="/images/hero.webp" type="image/webp">
  <img src="/images/hero.jpg" alt="Витрина продукта"
       width="1200" height="630" fetchpriority="high">
</picture>

4. Устраните блокирующие рендеринг ресурсы

Встройте критический CSS непосредственно в <head> и отложите некритические стили. Загружайте JavaScript с атрибутами defer или async для предотвращения блокировки парсера.

<!-- Встроенный критический CSS выше сгиба -->
<style>
  /* Критические стили для шапки, hero, навигации */
  .header { display:flex; height:60px; }
  .hero { min-height:400px; }
</style>

<!-- Отложенная загрузка некритического CSS -->
<link rel="preload" href="/style.css" as="style"
      onload="this.onload=null;this.rel='stylesheet'">

<!-- Отложенная загрузка JavaScript -->
<script src="/app.js" defer></script>

5. Используйте CDN для статических ресурсов

Раздавайте изображения, CSS, JavaScript и шрифты через сеть доставки контента (CDN) с точками присутствия вблизи ваших пользователей. CDN может сократить время загрузки ресурсов на 50-80% для пользователей, находящихся далеко от вашего сервера. Cloudflare, Fastly и AWS CloudFront предлагают бесплатные или доступные тарифы, подходящие для большинства сайтов.

INP: Interaction to Next Paint

Interaction to Next Paint (INP) измеряет наихудшую отзывчивость вашей страницы, отслеживая задержку между взаимодействием пользователя (клик, тап или нажатие клавиши) и следующим визуальным обновлением на экране. INP заменил First Input Delay (FID) в качестве Core Web Vital в марте 2024 года. Хороший INP составляет 200 миллисекунд или менее.

Критическое различие между INP и его предшественником FID — в охвате. FID измерял только задержку до того, как браузер начал обработку самого первого взаимодействия пользователя. INP измеряет полную задержку каждого взаимодействия на протяжении жизненного цикла страницы и сообщает о наихудшем (или почти наихудшем, на 98-м перцентиле). Это означает, что страница, быстро реагирующая на первый клик, но зависающая на 800 мс при открытии выпадающего меню, не пройдёт INP, хотя прошла бы FID.

INP фиксирует три отдельные фазы задержки взаимодействия:

• Задержка ввода (Input delay): Время между взаимодействием пользователя и началом выполнения обработчиков событий браузером. Вызвана занятостью главного потока другими задачами (длинные задачи, тяжёлое выполнение JavaScript).
• Время обработки (Processing time): Время выполнения обработчиков событий. Сложные обработчики, выполняющие синхронную DOM-манипуляцию, тяжёлые вычисления или блокирующие API-вызовы, увеличивают время обработки.
• Задержка отображения (Presentation delay): Время между завершением обработчиков событий и отрисовкой следующего кадра браузером. Включает пересчёт стилей, компоновку и отрисовку, вызванные взаимодействием.

Стратегии оптимизации INP

1. Разбивайте длинные задачи

JavaScript-задачи, выполняющиеся более 50 мс, блокируют главный поток и не дают браузеру реагировать на действия пользователя. Разбивайте длинные задачи на более мелкие части с помощью requestIdleCallback, setTimeout или API scheduler.yield().

// Плохо: одна длинная синхронная задача (блокирует главный поток)
function processAllItems(items) {
  items.forEach(item => heavyProcessing(item)); // 500мс+
}

// Хорошо: разбивка на части с scheduler.yield()
async function processAllItems(items) {
  for (const item of items) {
    heavyProcessing(item);
    // Уступаем главному потоку между элементами
    if (navigator.scheduler?.yield) {
      await navigator.scheduler.yield();
    } else {
      await new Promise(r => setTimeout(r, 0));
    }
  }
}

2. Уменьшите размер JavaScript-бандла

Большие JavaScript-бандлы дольше парсятся и выполняются, блокируя главный поток при загрузке страницы и после взаимодействий. Используйте разделение кода (code splitting) для загрузки только необходимого JavaScript для текущей страницы, tree-shaking для удаления неиспользуемого кода и откладывание некритических скриптов.

3. Используйте debounce для обработчиков ввода

Обработчики событий scroll, resize, mousemove и input могут срабатывать сотни раз в секунду. Применяйте debounce или throttle к этим обработчикам, чтобы предотвратить перегрузку главного потока и ухудшение INP для последующих взаимодействий.

4. Избегайте принудительных синхронных компоновок

Чтение свойств компоновки (таких как offsetHeight или getBoundingClientRect()) сразу после модификации DOM вынуждает браузер выполнять синхронный расчёт компоновки, который блокирует главный поток. Группируйте операции чтения и записи отдельно.

CLS: Cumulative Layout Shift

Cumulative Layout Shift (CLS) измеряет, насколько видимый контент вашей страницы неожиданно перемещается в течение её жизненного цикла. Он количественно оценивает визуальную нестабильность — те раздражающие моменты, когда вы собираетесь нажать кнопку, а она вдруг смещается из-за загрузки рекламы над ней, или когда текст, который вы читаете, сдвигается вниз из-за загрузки веб-шрифта. Хороший показатель CLS — 0,1 или менее.

CLS рассчитывается путём умножения доли воздействия (какая часть области просмотра была затронута сдвигом) на долю расстояния (насколько далеко сместились элементы). Учитываются только неожиданные сдвиги — изменения макета, происходящие в течение 500 мс после взаимодействия пользователя (например, нажатия на раскрывающийся список), исключаются из CLS. Google использует подход «сессионного окна» для расчёта CLS, группируя сдвиги, происходящие в пределах 1 секунды друг от друга (с максимальным окном в 5 секунд), и сообщая о наибольшем сессионном окне.

Типичные причины плохого CLS

• Изображения и видео без указания размеров: Когда изображения загружаются без явных атрибутов width и height, браузер не может зарезервировать для них место. При загрузке они сдвигают весь контент ниже.
• Реклама, встраиваемые элементы и iframe без зарезервированного пространства: Сторонний контент, динамически внедряющийся на страницу без предопределённого контейнера, вызывает значительные сдвиги макета.
• Динамически внедряемый контент: Баннеры, уведомительные панели, модальные окна cookie-согласия или ленты «срочных новостей», сдвигающие контент вниз после первоначального рендеринга.
• Веб-шрифты, вызывающие FOUT (мигание нестилизованного текста): Когда веб-шрифт загружается и заменяет запасной шрифт, различия в метриках шрифтов (размер, высота строки, межбуквенный интервал) вызывают сдвиг текстовых блоков.
• CSS-анимации, запускающие перекомпоновку: Анимации, использующие свойства top, left, width или height вместо transform, вызывают пересчёты макета, которые засчитываются как сдвиги.

Стратегии исправления CLS

1. Всегда задавайте размеры изображений и видео

<!-- Всегда указывайте width и height для изображений -->
<img src="/product.webp" alt="Фото продукта"
     width="800" height="600" loading="lazy">

<!-- Для адаптивных изображений используйте CSS aspect-ratio -->
<style>
  .responsive-img {
    width: 100%;
    height: auto;
    aspect-ratio: 16 / 9;
    object-fit: cover;
  }
</style>

2. Резервируйте место для рекламы и встраиваемых элементов

<!-- Зарезервируйте место для рекламного блока 300x250 -->
<div style="min-height: 250px; width: 300px;">
  <!-- Скрипт рекламы загрузится здесь -->
</div>

<!-- Зарезервируйте место для iframe -->
<iframe src="https://embed.example.com"
        width="560" height="315"
        loading="lazy"></iframe>

3. Используйте font-display: swap с подстроенными запасными шрифтами

/* Предотвращение сдвига макета от веб-шрифтов */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  /* Подстроенный запасной шрифт для совпадения метрик */
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

/* Альтернатива: использование @font-face override */
@font-face {
  font-family: 'Inter Fallback';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
}

4. Используйте CSS transform для анимаций

/* Плохо: анимация свойств компоновки вызывает CLS */
.slide-in {
  animation: slideIn 0.3s ease;
}
@keyframes slideIn {
  from { left: -100%; }
  to { left: 0; }
}

/* Хорошо: используйте transform (без сдвига макета) */
.slide-in {
  animation: slideIn 0.3s ease;
}
@keyframes slideIn {
  from { transform: translateX(-100%); }
  to { transform: translateX(0); }
}

Как Core Web Vitals влияют на позиции

Google подтвердил Core Web Vitals как сигнал ранжирования в июне 2021 года в рамках масштабного обновления Page Experience. С тех пор многочисленные исследования от Searchmetrics, Semrush и независимых SEO-исследователей проанализировали корреляцию между оценками CWV и позициями в выдаче. Консенсус очевиден: Core Web Vitals являются реальным, но умеренным фактором ранжирования. Они не перевешивают качество контента или авторитетность ссылок, но служат значимым фактором выбора, когда конкурирующие страницы схожи по качеству и релевантности.

Данные показывают устойчивую закономерность: сайты с хорошими Core Web Vitals, как правило, демонстрируют измеримый рост трафика, тогда как сайты с плохими CWV испытывают недостатки в ранжировании, особенно в мобильной поисковой выдаче, где Google придаёт больший вес сигналам качества страниц.

Косвенное влияние Core Web Vitals, пожалуй, ещё важнее прямого воздействия на ранжирование. Страницы, которые загружаются быстро, мгновенно реагируют и остаются визуально стабильными, имеют более низкий показатель отказов, более высокую вовлечённость, более длительные сеансы и больше конверсий. Google измеряет сигналы пользовательской вовлечённости (время на сайте, пого-стикинг) в рамках своих алгоритмов ранжирования, поэтому улучшение поведения пользователей от хороших CWV создаёт положительную обратную связь, которая дополнительно укрепляет ваши позиции.

Рабочий процесс оптимизации Core Web Vitals

Оптимизация Core Web Vitals — это не разовая задача, а итеративный процесс. Следуйте этому пятишаговому рабочему процессу для систематического выявления, диагностики, исправления, проверки и поддержания производительности CWV с течением времени.

Шаг 1 — Измерение: Начните с проверки реальных (полевых) данных в отчёте Core Web Vitals в Google Search Console и PageSpeed Insights. Полевые данные из CrUX отражают реальный пользовательский опыт за последние 28 дней. Если у вас недостаточно трафика для данных CrUX, используйте лабораторные данные из Lighthouse как отправную точку, но помните, что лабораторные оценки — это приближения, а не гарантии полевой производительности.

Шаг 2 — Диагностика: Используйте панель Performance в Chrome DevTools для выявления конкретных узких мест. Для LCP посмотрите на сетевой водопад (Network waterfall), чтобы найти, что задерживает LCP-ресурс. Для INP используйте отслеживание взаимодействий в панели Performance, чтобы найти длинные задачи, блокирующие главный поток. Для CLS включите оверлей «Layout Shift Regions», чтобы увидеть, какие именно элементы сдвигаются и когда.

Шаг 3 — Оптимизация: Применяйте целевые исправления на основе вашей диагностики. Отдавайте приоритет метрике, наиболее далёкой от порога «хорошо». Используйте конкретные стратегии оптимизации, описанные в этом руководстве для каждой метрики.

Шаг 4 — Тестирование: После внедрения исправлений протестируйте на стейджинге с помощью Lighthouse и WebPageTest. Сравните оценки до и после. Убедитесь, что улучшения сохраняются на различных типах устройств и сетевых условиях. Используйте режим filmstrip в WebPageTest для визуального подтверждения, что контент загружается быстрее и не сдвигается.

Шаг 5 — Мониторинг: Разверните на продакшне и отслеживайте данные CrUX в Search Console. Полевым данным требуется 28 дней для полного обновления, поэтому будьте терпеливы. Настройте Real User Monitoring (RUM) с помощью JavaScript-библиотеки web-vitals для получения данных о производительности в реальном времени от ваших фактических посетителей. Установите пороги оповещений, чтобы получать уведомления при регрессии любой метрики.

// Установка: npm install web-vitals
import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics(metric) {
  // Отправка данных метрики на ваш аналитический эндпоинт
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good', 'needs-improvement' или 'poor'
    delta: metric.delta,
    id: metric.id,
    navigationType: metric.navigationType,
  });

  // Используем sendBeacon для надёжной доставки
  navigator.sendBeacon('/api/vitals', body);
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

До и после: реальные результаты оптимизации

6 ключевых методов оптимизации

Эти шесть методов охватывают наиболее значимые оптимизации для всех трёх Core Web Vitals. Реализация всех шести решит подавляющее большинство проблем CWV на большинстве сайтов.

Методы оптимизации по метрикам

Диагностические инструменты для Core Web Vitals

Эффективная оптимизация CWV требует правильных инструментов измерения. Вот исчерпывающее сравнение инструментов, доступных в 2026 году, организованных по их сильным сторонам и идеальным сценариям использования.

Рекомендация: Используйте комбинацию инструментов. Начните с Google Search Console для общей картины (какие страницы проходят, какие нет и какие тренды). Используйте PageSpeed Insights для диагностики отдельных страниц с реальными данными CrUX. Используйте Chrome DevTools для интерактивной отладки, когда нужно отследить конкретное узкое место. Используйте WebPageTest для конкурентного анализа и тестирования изменений перед развёртыванием. Используйте seoscore.tools, чтобы увидеть, как CWV вписывается в общую SEO-картину наряду с 136+ другими факторами ранжирования.

Приоритизация: быстрые победы vs долгосрочные исправления

Core Web Vitals и ИИ-поиск

Вы можете задаться вопросом, важны ли Core Web Vitals для видимости в ИИ-поиске — ведь ИИ-системы вроде ChatGPT, Perplexity и Google AI Overview обрабатывают контент программно, а не через браузер. Ответ нюансирован, но важен: Core Web Vitals влияют на видимость в ИИ-поиске косвенно, но существенно.

Вот как CWV связаны с ИИ-поиском:

Влияние через поисковый индекс: Google AI Overview берёт свои источники из поискового индекса Google, где CWV является фактором ранжирования. Страницы с хорошими CWV ранжируются выше в традиционном поиске, что повышает вероятность их попадания в пул кандидатов, из которого AI Overview выбирает источники. Если ваша страница на 15-й позиции из-за плохих CWV, её вероятность быть процитированной в AI Overview значительно ниже, чем у страницы на 3-й позиции с идентичным контентом, но лучшей производительностью.

Эффективность краулинга: ИИ-краулеры (включая краулеры Perplexity и режим просмотра ChatGPT) имеют ограниченный бюджет времени для загрузки и парсинга страниц. Медленно загружающаяся страница, которой нужно 6 секунд для рендеринга, может привести к таймауту или лишь частичному рендерингу при операциях ИИ-краулинга. Быстрые, чистые страницы более надёжно сканируются и индексируются ИИ-системами.

Доступность контента: Страницы со значительными сдвигами макета или рендерингом, зависящим от JavaScript, могут представлять ИИ-краулерам контент, отличающийся от того, что видят пользователи. Если ваш основной контент требует тяжёлого выполнения JavaScript для рендеринга (что плохо для INP и LCP), ИИ-краулеры могут пропустить его полностью. Контент, рендерящийся на сервере с хорошими CWV, наиболее надёжно парсится как традиционными, так и ИИ-поисковыми системами.

Пользовательский опыт как сигнал качества: Google всё активнее использует поведенческие сигналы (показатель отказов, вовлечённость, время на сайте) как косвенные факторы ранжирования. Страницы с плохими CWV генерируют худшие поведенческие сигналы, что ухудшает позиции, что снижает вероятность цитирования ИИ. Это цепная реакция, где плохая производительность на пользовательском уровне каскадно снижает видимость в ИИ.

Распространённые ошибки Core Web Vitals

Даже опытные разработчики и SEO-специалисты допускают эти ошибки при оптимизации Core Web Vitals. Избегая их, вы сэкономите часы отладки и предотвратите регрессии.

• Оптимизация только для лабораторных данных. Оценка Lighthouse 100 не гарантирует хорошие данные CrUX. Лабораторные тесты запускаются на фиксированном устройстве с фиксированной сетью; реальные пользователи имеют совершенно разные устройства, соединения и контексты просмотра. Всегда проверяйте лабораторные улучшения на полевых данных. Если ваша оценка Lighthouse 95, но CrUX INP составляет 450 мс, лабораторный тест вводит вас в заблуждение.
• Ленивая загрузка LCP-элемента. Добавление loading="lazy" к hero-изображениям, баннерам выше сгиба или основным изображениям контента — одна из самых распространённых и вредных ошибок LCP. Ленивая загрузка задерживает эти критические ресурсы, поскольку браузер ждёт, пока элемент не окажется рядом с областью просмотра. LCP-элемент всегда должен загружаться немедленно с fetchpriority="high".
• Игнорирование сторонних скриптов. Аналитика, чат-виджеты, встраиваемые социальные элементы, рекламные скрипты и инструменты A/B-тестирования часто вносят больший вклад в плохие CWV, чем ваш собственный код. Один неоптимизированный чат-виджет может добавить 500+ мс к INP, блокируя главный поток. Проведите аудит каждого стороннего скрипта, отложите некритические и используйте атрибут Partitioned для сторонних iframe.
• Исправление CLS в разработке, но не в продакшне. CLS часто ведёт себя по-разному в продакшне из-за рекламы, баннеров cookie-согласия, вариаций A/B-тестов и пользовательского контента, которые не существуют в среде разработки. Всегда измеряйте CLS в продакшне с реальными конфигурациями рекламы и реальными пользовательскими сценариями.
• Использование слишком большого количества веб-шрифтов. Загрузка 4-6 начертаний и стилей шрифтов из Google Fonts или самохостинга добавляет значительную задержку к LCP и вызывает CLS при смене шрифтов. Ограничьтесь максимум 2-3 файлами шрифтов. Используйте font-display: swap с подстроенными запасными шрифтами для предотвращения сдвигов макета и предзагружайте только самый критический файл шрифта.
• Отсутствие явных размеров у адаптивных изображений. HTML-атрибуты width и height прекрасно работают с адаптивным CSS (width: 100%; height: auto;). Браузер использует соотношение сторон из атрибутов для резервирования правильного пространства до загрузки изображения. Между адаптивными изображениями и явными размерами нет конфликта — их отсутствие всегда является ошибкой.
• Предположение, что быстрый сайт по WiFi означает быстрый сайт везде. Тестируйте свои страницы на симулированных 3G и 4G соединениях и на реальных Android-устройствах среднего класса. Данные CrUX Google преобладают за счёт мобильных пользователей с нестабильным соединением. Ваша страница может получить оценку «хорошо» на MacBook Pro с оптоволокном, но «плохо» для большинства ваших реальных пользователей на мобильных устройствах.
• Отсутствие мониторинга после развёртывания. Регрессии производительности происходят постоянно при добавлении новых функций, рекламы, сторонних скриптов и контента. Без непрерывного мониторинга один пул-реквест, добавляющий неоптимизированное hero-изображение или новый аналитический скрипт, может перечеркнуть месяцы работы по оптимизации. Настройте автоматические оповещения с помощью библиотеки web-vitals или RUM-сервиса.

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

Ключевые выводы

1. Core Web Vitals — подтверждённый фактор ранжирования Google. LCP, INP и CLS напрямую влияют на ваши позиции в поиске как часть сигнала качества страницы. Сайты, проходящие все три порога, имеют измеримое преимущество, особенно на мобильных устройствах.
2. INP заменил FID в марте 2024, и пройти его гораздо сложнее. В отличие от FID, который измерял только задержку ввода первого взаимодействия, INP измеряет полную задержку каждого взаимодействия на странице. Многие сайты, легко проходившие FID, проваливают INP. Проведите аудит INP целенаправленно — не предполагайте, что у вас всё в порядке.
3. Оптимизируйте для реальных пользователей, а не для лабораторных оценок. Google использует полевые данные из Chrome User Experience Report (CrUX), измеренные на 75-м перцентиле. Идеальная оценка Lighthouse ничего не значит, если ваши реальные пользователи на реальных устройствах имеют плохой опыт. Всегда проверяйте по полевым данным CrUX.
4. Быстрые победы существуют и должны быть сделаны первыми. Сжатие изображений, предзагрузка LCP-элемента, задание явных размеров изображений и включение кэширования могут кардинально улучшить CWV с минимальными усилиями. Начните с этого, прежде чем инвестировать в сложные архитектурные изменения.
5. CWV влияет на ИИ-поиск косвенно, но существенно. Более быстрые и стабильные страницы ранжируются выше в традиционном поиске (из которого ИИ-системы черпают информацию), более надёжно сканируются ИИ-краулерами и генерируют лучшие сигналы пользовательской вовлечённости. Оптимизация CWV повышает видимость как в традиционном, так и в ИИ-поиске.
6. Непрерывный мониторинг обязателен. Регрессии производительности из-за новых функций, рекламы и сторонних скриптов происходят постоянно. Используйте библиотеку web-vitals для отслеживания реальных пользовательских метрик и настройте оповещения, чтобы регрессии обнаруживались немедленно. Регулярно проверяйте seoscore.tools, чтобы видеть, как ваши CWV вписываются в общее состояние SEO.