Войти Регистрация Проверить сайт
📚 Полный гайд

Скорость загрузки сайта и Core Web Vitals 2026: полный гайд

Полный гайд по скорости загрузки сайта и Core Web Vitals 2026: пороги LCP, INP, CLS, топ-10 причин медленного сайта, 10 техник ускорения с примерами кода.

· автор:

Core Web Vitals — три официальных метрики Google, по которым оценивается пользовательский опыт на сайте: LCP (скорость загрузки), INP (интерактивность), CLS (стабильность верстки). С 2021 года влияют на позиции. В марте 2024 Google заменил FID на INP — большинство RU-сайтов до сих пор оптимизируют устаревшую метрику.

В этом гайде: актуальные пороги 2026, где и как замерять, топ-10 причин медленного сайта и 10 техник ускорения с конкретными примерами. Для детального разбора каждой темы — ссылки на профильные материалы.

Проверьте скорость вашего сайта за 30 секунд: audit4seo.ru.

Оглавление

  1. Core Web Vitals — что это и как влияет на ранжирование 2026
  2. 3 метрики CWV: LCP, INP, CLS
  3. Скорость на mobile vs desktop — mobile-first 2026
  4. Топ-10 причин медленного сайта
  5. Как измерить скорость сайта
  6. 10 техник ускорения по приоритету
  7. HTTP/2 и HTTP/3 — когда переходить
  8. FAQ
  9. Чек-лист по скорости

Core Web Vitals — что это и как влияет на ранжирование 2026

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

Детальный разбор каждой метрики с форенсикой и фиксами — в статье «Core Web Vitals: как проверить и исправить».

Ключевые изменения 2024–2026

Март 2024: INP заменил FID в списке Core Web Vitals. FID измерял задержку первого взаимодействия — INP измеряет худшую задержку за всю сессию. Это принципиальная разница: сайт мог легко пройти FID, но провалить INP.

2025: Google добавил в CrUX сбор post-vitals UX сигналов: scroll depth, rage clicks, dead clicks, micro-interactions latency. Пороги непубличны, но включены в Page Experience score.

Как CWV влияет на позиции

CWV входят в сигнал Page Experience. Google при прочих равных условиях отдаёт предпочтение страницам с лучшим Page Experience. «При прочих равных» — важная оговорка: сильный контент и E-E-A-T важнее CWV. Но на конкурентных запросах, где топ-10 выровнен по контенту, CWV становится тай-брейкером.

Практические последствия плохих CWV: - LCP > 4 сек: документально подтверждённое снижение позиций - INP > 500 мс: высокий отказ пользователей → поведенческий сигнал → дополнительный негатив - CLS > 0,25: раздражение пользователей, случайные нажатия → тот же негативный поведенческий эффект

Яндекс и скорость

Яндекс не использует CWV как прямой ранжирующий фактор. Но: - Использует TTFB, время до первого экрана и полной загрузки - Учитывает поведенческие факторы (отказы), которые напрямую зависят от скорости - Турбо-страницы дают прямой буст в мобильной выдаче - Яндекс.Метрика фиксирует rage clicks и scroll depth — аналоги post-vitals сигналов

3 метрики CWV: LCP, INP, CLS

LCP (Largest Contentful Paint)

Что измеряет: время до отрисовки крупнейшего видимого элемента страницы (обычно hero-изображение или крупный заголовок).

Оценка Порог
Хорошо ≤ 2,5 сек
Нужно улучшить 2,5–4,0 сек
Плохо > 4,0 сек

Замеряется на 75-м перцентиле реальных пользователей (CrUX).

Типичные причины плохого LCP: 1. Большое hero-изображение без оптимизации 2. Render-blocking CSS или JS в <head> 3. Медленный TTFB (сервер отвечает > 600 мс) 4. Web Fonts без preload блокируют рендер 5. Hero-изображение с loading="lazy" — критическая ошибка

INP (Interaction to Next Paint)

Что измеряет: задержку от взаимодействия пользователя (клик, tap, keypress) до следующей перерисовки страницы. Берётся худшее значение из всей сессии с p98-фильтрацией.

Оценка Порог
Хорошо ≤ 200 мс
Нужно улучшить 200–500 мс
Плохо > 500 мс

Чем INP сложнее FID: - FID = задержка до начала обработки первого ввода - INP = полный путь: ввод → обработка event handler → следующая отрисовка - INP учитывает все взаимодействия за сессию, не только первое - INP включает время рендеринга после handler

Главные убийцы INP в 2026:

Причина Доля сайтов Типовой фикс
Тяжёлый JS bundle (> 500 KB gzip) ~40% Code splitting, dynamic imports
Сторонние виджеты (чаты, Метрика, реклама) ~35% Defer + load on interaction
Long tasks > 50 мс в main thread ~30% scheduler.yield(), requestIdleCallback
Тяжёлые event handlers ~25% Debounce/throttle, Web Worker
React/Vue hydration delay (SPA) ~20% Partial hydration, islands architecture
Большой DOM (> 1500 nodes) ~15% Виртуализация списков

Специфика для Яндекса: Яндекс.Метрика сама добавляет 50–150 мс на main thread. Jivo, Carrot Quest, LiveTex — главные INP-киллеры на RU-сайтах. Обязательно подключайте через defer или по user-interaction.

CLS (Cumulative Layout Shift)

Что измеряет: суммарный сдвиг видимого контента при загрузке без действий пользователя. Score = произведение impact fraction на distance fraction.

Оценка Порог
Хорошо ≤ 0,1
Нужно улучшить 0,1–0,25
Плохо > 0,25

Типичные причины высокого CLS: 1. Изображения без атрибутов width и height 2. Динамически инжектируемые баннеры или рекламные блоки 3. Web Fonts с font-display: swap меняют геометрию текста 4. Cookie-баннер, вставляемый вверху страницы (толкает контент вниз) 5. Lazy-loaded iframes (видео, карты) без зарезервированного места

Скорость на mobile vs desktop — mobile-first 2026

Google с 2019 года использует mobile-first индексацию: для ранжирования берётся мобильная версия сайта. Для Яндекса mobile-first с 2016 года.

Почему mobile CWV хуже desktop: - Мобильные процессоры в 5–10 раз медленнее desktop - Мобильный интернет в 3–5 раз медленнее WiFi - Touch-события обрабатываются дольше mouse-событий - Рекламные и аналитические скрипты одинаково тяжёлые для обеих версий

Средние показатели по РФ (CrUX, Q1 2026):

Метрика Mobile Desktop Доля сайтов «Хорошо» mobile
LCP ~4,2 сек (медиана) ~2,1 сек ~43%
INP ~280 мс (медиана) ~110 мс ~52%
CLS ~0,12 (медиана) ~0,05 ~64%

Практический вывод: большинство российских сайтов провалены по CWV именно на мобильных. Оптимизируйте в первую очередь под мобильный сценарий.

Турбо-страницы Яндекса: собственный AMP-аналог. Ускоряет мобильный опыт до < 1 сек загрузки. Подключается через RSS-feed или JSON. Даёт прямой буст позиций в Яндексе на мобильных запросах.

Топ-10 причин медленного сайта

Детальные решения для каждой проблемы — в статье «Как сделать сайт быстрее: 10 проверенных методов».

1. Неоптимизированные изображения (самая частая)

Изображения в формате PNG или JPEG без сжатия — причина №1 медленного LCP. Типичная ошибка: 5–10 Мб hero-изображение на главной.

Влияние на LCP: +1,5–3 сек при отсутствии оптимизации.

2. Render-blocking ресурсы

JS и CSS в <head> без defer/async блокируют рендеринг страницы до их полной загрузки.

Влияние на LCP: +0,5–2 сек.

3. Медленный TTFB (> 600 мс)

Если сервер долго отвечает, ничего остальное не имеет значения: рендеринг не начнётся раньше первого байта ответа.

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

4. Тяжёлые сторонние скрипты

Яндекс.Метрика, JivoSite, онлайн-чаты, пиксели рекламных сетей — каждый добавляет HTTP-запрос и выполнение JavaScript в main thread.

Влияние на INP: +50–300 мс на каждый тяжёлый виджет.

5. Большой начальный DOM

DOM с > 1500 узлами замедляет рендеринг, увеличивает время парсинга и ухудшает INP.

Типичные виновники: сложные CMS-шаблоны (Bitrix, некоторые WordPress-темы), скрытые блоки, модальные окна.

6. Отсутствие HTTP/2

HTTP/1.1 обрабатывает запросы последовательно. HTTP/2 позволяет мультиплексировать запросы — загружать CSS, JS и изображения параллельно. Переход с HTTP/1.1 на HTTP/2 даёт 15–30% прирост скорости без изменения кода.

7. Нет CDN

Запрос из Новосибирска к серверу в Москве добавляет 40–80 мс к каждому ресурсу. CDN (Content Delivery Network) хранит статику рядом с пользователем.

8. Изображения без lazy loading (ниже первого экрана)

Изображения вне viewport грузятся при открытии страницы, потребляя bandwidth и замедляя LCP. Исключение: hero-изображение — оно всегда loading="eager".

9. Web Fonts без оптимизации

font-display: block держит текст невидимым до загрузки шрифта (FOIT). font-display: swap показывает fallback и меняет на финальный — вызывает CLS.

10. Отсутствие сжатия и кэширования

Без Brotli/Gzip файлы передаются без сжатия: HTML страница 100 KB вместо 20 KB сжатой. Без Cache-Control браузер загружает ресурсы заново при каждом визите.

Как измерить скорость сайта

Детальное сравнение инструментов и методов измерения — в статье «Скорость загрузки сайта: как измерить».

Принципиальное различие: Lab vs Field данные

Lab (лабораторные, синтетические) — Lighthouse: - Запускается в контролируемых условиях - Воспроизводимый результат - Полезен для отладки фиксов - Не используется Google в ранжировании

Field (полевые, реальные) — CrUX: - Реальные данные от Chrome-пользователей - 28-дневное скользящее окно - Именно это влияет на позиции - Требует минимума трафика (иначе данных нет)

Правило: всегда смотрите Field Data в PageSpeed Insights, не только лабораторные показатели.

Инструменты измерения

Инструмент Тип данных Когда использовать
PageSpeed Insights Lab + Field (CrUX) Быстрый аудит конкретной страницы
GSC → Core Web Vitals Field (CrUX) Мониторинг всего сайта по группам URL
Lighthouse в Chrome DevTools Lab Локальная отладка перед деплоем
CrUX API Field Программный сбор для дашбордов
WebPageTest Lab (расширенный) Детальный анализ waterfall, filmstrip
web-vitals.js RUM (собственный сбор) Точечный мониторинг в production

Ссылки: - PageSpeed Insights - Google Search Console → Core Web Vitals - WebPageTest

10 техник ускорения по приоритету

Техники расставлены по соотношению «эффект / сложность внедрения». Начинайте с первых трёх — они дают максимальный прирост минимальными усилиями.

1. WebP/AVIF + размеры изображений

Эффект на LCP: -0,5–2,5 сек.

Конвертируйте все изображения в WebP (более широкая поддержка) или AVIF (лучшее сжатие). WebP на 25–34% легче JPEG при том же визуальном качестве.

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Описание" width="1200" height="630"
       loading="eager" fetchpriority="high">
</picture>

Атрибуты width и height обязательны — они резервируют место и предотвращают CLS.

2. Lazy loading для изображений ниже fold

Эффект на LCP: -0,3–1 сек (ускорение за счёт меньшего количества одновременных запросов).

<!-- Hero — всегда eager, не lazy -->
<img src="hero.webp" loading="eager" fetchpriority="high">

<!-- Изображения ниже первого экрана -->
<img src="product.webp" loading="lazy" width="400" height="300">

3. defer и async для скриптов

Эффект на LCP: -0,5–2 сек. Эффект на INP: -50–200 мс.

<!-- Аналитика — defer: выполняется после парсинга HTML -->
<script src="analytics.js" defer></script>

<!-- Независимые виджеты — async: не блокирует, но не гарантирует порядок -->
<script src="widget.js" async></script>

<!-- Тяжёлые чат-виджеты — загружать только при взаимодействии -->
<script>
  document.addEventListener('click', function loadChat() {
    var script = document.createElement('script');
    script.src = 'https://chat-widget.js';
    document.head.appendChild(script);
    document.removeEventListener('click', loadChat);
  }, {once: true});
</script>

4. Preload критических ресурсов

Эффект на LCP: -0,3–1,5 сек.

Preload сообщает браузеру загрузить ресурс как можно раньше:

<!-- Preload hero-изображения -->
<link rel="preload" as="image" href="hero.webp"
      imagesrcset="hero-320.webp 320w, hero-640.webp 640w, hero-1200.webp 1200w"
      imagesizes="100vw">

<!-- Preload критичного шрифта -->
<link rel="preload" as="font" type="font/woff2"
      href="/fonts/main.woff2" crossorigin>

5. Brotli сжатие + кэширование

Эффект на LCP: -0,2–0,8 сек.

Brotli на 15–25% лучше Gzip. Настройка в nginx:

brotli on;
brotli_comp_level 6;
brotli_types text/html text/css application/javascript application/json;

# Кэширование статики на 1 год
location ~* \.(css|js|jpg|webp|avif|woff2)$ {
  expires 1y;
  add_header Cache-Control "public, immutable";
}

6. prefetch и preconnect для сторонних ресурсов

Эффект на LCP и INP: -0,1–0,5 сек.

<!-- Установить соединение заранее с ключевыми CDN -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://mc.yandex.ru">

<!-- Предзагрузить страницы, на которые пользователь, вероятно, перейдёт -->
<link rel="prefetch" href="/blog/seo-audit-2026/">

7. HTTP/2 (и HTTP/3)

Эффект на LCP: -0,3–1 сек при большом числе ресурсов.

HTTP/2 включается в nginx:

listen 443 ssl http2;

HTTP/3 (QUIC) — следующий шаг, особенно эффективен при потере пакетов и нестабильном мобильном соединении. Поддерживается Cloudflare и большинством современных серверов.

8. font-display и оптимизация шрифтов

Эффект на LCP: -0,2–0,5 сек. Эффект на CLS: устраняет FOUT-CLS.

@font-face {
  font-family: 'MyFont';
  font-display: swap; /* fallback во время загрузки */
  src: url('/fonts/myfont.woff2') format('woff2');
}

Для устранения CLS от font-swap используйте size-adjust, ascent-override, descent-override для подбора метрик fallback-шрифта.

9. Минификация CSS и JS

Эффект на LCP: -0,1–0,4 сек.

В production-сборках: удалить пробелы, комментарии, сократить имена переменных. В webpack/vite:

// vite.config.js
export default {
  build: {
    minify: 'terser', // JS
    cssMinify: true   // CSS
  }
}

Для WordPress: плагины LiteSpeed Cache, WP Rocket, NitroPack.

10. Image dimensions (width/height в HTML)

Эффект на CLS: устраняет layout shift от изображений.

Простейший фикс CLS, который часто игнорируют:

<!-- Без размеров — вызывает CLS -->
<img src="product.webp" alt="...">

<!-- С размерами — браузер резервирует место -->
<img src="product.webp" alt="..." width="400" height="300">

В CSS:

img {
  max-width: 100%;
  height: auto; /* сохраняет aspect ratio при изменении ширины */
}

HTTP/2 и HTTP/3 — когда переходить

HTTP/1.1 vs HTTP/2

Параметр HTTP/1.1 HTTP/2
Параллельные запросы 6 на домен Неограниченно (мультиплексирование)
Сжатие заголовков Нет HPACK
Server Push Нет Есть (но не рекомендуется)
Настройка Базовая Требует HTTPS

Когда переходить: прямо сейчас, если не перешли. HTTP/2 поддерживается 96%+ браузеров и всеми современными серверами. Включается одной строкой в nginx.

HTTP/3 (QUIC)

HTTP/3 работает поверх QUIC — UDP-протокола вместо TCP. Преимущества: - 0-RTT установка соединения при повторных визитах - Устойчивость к потере пакетов (критично для мобильного интернета) - Устраняет Head-of-Line Blocking

Когда переходить: если ваш CDN (Cloudflare, Fastly, BunnyCDN) уже поддерживает — включите. Для bare-metal серверов: nginx 1.25+ с модулем ngx_http_v3_module.

RU-специфика: Cloudflare в 2025 году — рекомендованный CDN для RU-рынка после ухода части западных провайдеров. Поддерживает HTTP/3 «из коробки».

FAQ

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

Core Web Vitals — три метрики пользовательского опыта: LCP (скорость загрузки), INP (задержка взаимодействия), CLS (стабильность контента). Google использует их как ранжирующий фактор с 2021 года в рамках Page Experience сигнала.

Какие пороги Core Web Vitals в 2026 году?

LCP: хорошо ≤ 2,5 сек. INP: хорошо ≤ 200 мс. CLS: хорошо ≤ 0,1. Все измеряются на 75-м перцентиле реальных пользователей через CrUX.

Чем INP отличается от FID?

FID измерял задержку только первого взаимодействия. INP измеряет худшую задержку за всю сессию и включает весь путь: ввод → обработка → перерисовка. INP заменил FID в марте 2024.

Как быстро проверить Core Web Vitals своего сайта?

PageSpeed Insights (pagespeed.web.dev) — вводите URL и видите реальные данные пользователей. Для мониторинга всего сайта: Google Search Console → Core Web Vitals.

Влияет ли скорость сайта на Яндекс?

Яндекс не использует CWV напрямую, но учитывает скорость через поведенческие факторы и собственные метрики (TTFB, время до первого экрана). Турбо-страницы дают прямой буст в мобильной выдаче.

Что быстрее всего ускорит сайт?

Три быстрые победы: 1) конвертировать изображения в WebP/AVIF + добавить size-атрибуты; 2) перенести сторонние скрипты на defer/async; 3) включить Brotli и кэширование. Обычно дают LCP -1–1,5 сек.

Сколько стоит ускорение сайта?

Базовая оптимизация (изображения, скрипты, кэш) — силами разработчика 10–20 часов работы. Профессиональная оптимизация под CWV хорошего сайта: 30–80 тыс. ₽. CDN Cloudflare Pro: $20/мес. Для WordPress-сайтов плагины автоматизации (WP Rocket, LiteSpeed): 3–15 тыс. ₽/год.

Чек-лист по скорости

Технический аудит скорости автоматически: audit4seo.ru.

Core Web Vitals — диагностика

  • [ ] Открыт PageSpeed Insights, проверены Field Data по мобильным
  • [ ] LCP ≤ 2,5 сек (поле, мобильные)
  • [ ] INP ≤ 200 мс (поле)
  • [ ] CLS ≤ 0,1 (поле)
  • [ ] GSC → Core Web Vitals — нет страниц в категории «Плохо»
  • [ ] TTFB ≤ 600 мс

Изображения

  • [ ] Hero-изображение в WebP или AVIF
  • [ ] Все изображения имеют атрибуты width и height
  • [ ] Hero — loading="eager" fetchpriority="high"
  • [ ] Изображения ниже fold — loading="lazy"
  • [ ] <link rel="preload"> для hero-изображения
  • [ ] Изображения < 200 KB после сжатия (кроме Hero)

Скрипты и ресурсы

  • [ ] Сторонние скрипты подключены с defer или async
  • [ ] Чат-виджеты загружаются по user-interaction
  • [ ] <link rel="preconnect"> для ключевых внешних доменов
  • [ ] Render-blocking CSS вынесен в critical inline CSS или подключён через preload

Шрифты

  • [ ] font-display: swap или optional
  • [ ] Критичные шрифты предзагружены через preload
  • [ ] Используется woff2 формат

Серверная конфигурация

  • [ ] HTTP/2 включён (проверить: securityheaders.com или Chrome DevTools → Network)
  • [ ] Brotli или Gzip сжатие включено
  • [ ] Cache-Control настроен для статики (1 год для immutable ресурсов)
  • [ ] CDN подключён для статических ресурсов

Дополнительно (WordPress / Bitrix)

  • [ ] Плагин кэширования (WP Rocket, LiteSpeed, W3 Total Cache)
  • [ ] Database queries оптимизированы (Query Monitor)
  • [ ] Деактивированы неиспользуемые плагины

Проверьте Core Web Vitals вашего сайта: audit4seo.ru — бесплатно, 50+ параметров включая скорость.

Источники

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "headline": "Скорость загрузки сайта и Core Web Vitals 2026: полный гайд",
      "description": "Полный гайд по скорости загрузки и Core Web Vitals 2026: пороги LCP, INP, CLS, топ-10 причин медленного сайта, 10 техник ускорения.",
      "author": {
        "@type": "Person",
        "name": "Олег Шалыгин",
        "url": "https://audit4seo.ru/about"
      },
      "publisher": {
        "@type": "Organization",
        "name": "audit4seo.ru",
        "url": "https://audit4seo.ru",
        "logo": {"@type": "ImageObject", "url": "https://audit4seo.ru/logo.png"}
      },
      "datePublished": "2026-05-02",
      "dateModified": "2026-05-02",
      "mainEntityOfPage": "https://audit4seo.ru/guides/performance-2026"
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        {"@type": "ListItem", "position": 1, "name": "Главная", "item": "https://audit4seo.ru/"},
        {"@type": "ListItem", "position": 2, "name": "Гайды", "item": "https://audit4seo.ru/guides/"},
        {"@type": "ListItem", "position": 3, "name": "Core Web Vitals 2026"}
      ]
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Что такое Core Web Vitals и влияют ли они на позиции?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Core Web Vitals — три метрики: LCP (скорость загрузки), INP (задержка взаимодействия), CLS (стабильность контента). Google использует их как ранжирующий фактор с 2021 года."
          }
        },
        {
          "@type": "Question",
          "name": "Какие пороги Core Web Vitals в 2026 году?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "LCP: хорошо ≤ 2,5 сек. INP: хорошо ≤ 200 мс (заменил FID в марте 2024). CLS: хорошо ≤ 0,1. Все измеряются на 75-м перцентиле реальных пользователей через CrUX."
          }
        },
        {
          "@type": "Question",
          "name": "Чем INP отличается от FID?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "FID измерял задержку только первого взаимодействия. INP измеряет худшую задержку за всю сессию, включая весь путь от ввода до перерисовки. INP заменил FID в марте 2024."
          }
        },
        {
          "@type": "Question",
          "name": "Что быстрее всего ускорит сайт?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Три быстрые победы: 1) конвертировать изображения в WebP/AVIF + добавить size-атрибуты; 2) перенести сторонние скрипты на defer/async; 3) включить Brotli и кэширование. Обычно дают LCP -1–1,5 сек."
          }
        }
      ]
    }
  ]
}

Подробные разделы гайда

Каждый блок — отдельный детальный материал по теме.

01

Скорость загрузки сайта

Читать → 02

Core Web Vitals

Читать → 03

Как сделать сайт быстрее

Читать →

Полезные инструменты