IT

Оптимизация скорости сайта в 2026 году — как достичь Core Web Vitals 90+

Практическое руководство по теме Оптимизация скорости сайта в 2026 году — как достичь Core Web Vitals 90+: ключевые проверки, риски и связанные инструменты для более точного решения.

> **Если коротко:** В 2026 году Google Core Web Vitals — это LCP (Largest Contentful Paint) < 2.5 сек, INP (Interaction to Next Paint) < 200 мс, CLS (Cumulative Layout Shift) < 0.1. Эти три показателя напрямую влияют на позиции в поиске. Из всего, что реально работает: ① конвертация изображений в WebP/AVIF ② предзагрузка шрифтов ③ разбивка JavaScript на чанки ④ размещение на edge-серверах CDN. Если вы на Next.js — при правильных настройках Lighthouse 90+ вполне достижим.

Что такое Core Web Vitals и почему они важны

Core Web Vitals — это три ключевых метрики пользовательского опыта, которые Google включил в сигналы ранжирования ещё в 2021 году. С тех пор они никуда не делись — скорее, стали важнее.

Три метрики — коротко

| Метрика | Полное название | Что это | Хорошо | Средне | Плохо |

|---|---|---|---|---|---|

| **LCP** | Largest Contentful Paint | Когда загрузился главный блок страницы | < 2.5 сек | 2.5–4 сек | > 4 сек |

| **INP** | Interaction to Next Paint | Как быстро страница реагирует на клик | < 200 мс | 200–500 мс | > 500 мс |

| **CLS** | Cumulative Layout Shift | Прыгают ли элементы при загрузке | < 0.1 | 0.1–0.25 | > 0.25 |

Кстати: FID (First Input Delay) ушёл в прошлое — его заменил INP в 2024 году.

Почему это не просто красивые цифры

**SEO**: Google прямо говорит, что при прочих равных выигрывает более быстрый сайт

**Отказы**: LCP больше 3 секунд — и 53% мобильных пользователей уходят (данные Google)

**Деньги**: AdSense RPM растёт вместе со временем на странице — быстрый сайт = выше доход

**Конверсия**: каждая лишняя секунда загрузки отнимает ~7% конверсий (Akamai)

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

LCP чаще всего упирается в загрузку hero-изображения или крупного текстового блока.

Изображения — здесь больше всего можно выиграть

**Сравнение форматов:**

| Формат | Выигрыш в размере | Поддержка браузеров |

|---|---|---|

| JPEG | Базовый | 100% |

| WebP | на 25–35% легче | 98%+ |

| AVIF | на 40–50% легче | 90%+ (2026) |

```html

<picture>

<source srcset="hero.avif" type="image/avif">

<source srcset="hero.webp" type="image/webp">

<img src="hero.jpg" alt="Hero image" width="1200" height="628" loading="eager">

</picture>

```

**Для Next.js:**

```typescript

import Image from 'next/image'

// LCP-изображение должно иметь priority!

<Image

src="/hero.jpg"

alt="Hero image"

width={1200}

height={628}

priority // убирает задержку LCP

quality={85}

/>

```

Предзагрузка ресурсов

```html

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

<link rel="preload" as="font" href="/fonts/main.woff2" type="font/woff2" crossorigin>

```

Время ответа сервера (TTFB)

| Метод | Эффект | Реализация |

|---|---|---|

| CDN | Edge-кэширование по всему миру | Cloudflare, Vercel Edge |

| Кэш-заголовки | Мгновенная загрузка для возвращающихся | Cache-Control: max-age=31536000 |

| SSG/ISR | Готовый HTML без ожидания | Next.js generateStaticParams |

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

INP — это время от любого действия пользователя (клик, касание, ввод) до момента, когда браузер отрисует следующий кадр.

Разгрузить главный поток

```javascript

// Плохо: тяжёлые вычисления блокируют реакцию на клик

button.addEventListener('click', () => {

const result = heavyComputation(data) // поток заморожен

updateUI(result)

})

// Хорошо: отправляем в Web Worker

const worker = new Worker('heavy-worker.js')

button.addEventListener('click', () => {

worker.postMessage(data) // работает в отдельном потоке

})

worker.onmessage = (e) => updateUI(e.data)

```

Разбивка кода (Next.js)

```typescript

import dynamic from 'next/dynamic'

// Откладываем компоненты, которые не нужны сразу

const HeavyChart = dynamic(() => import('./HeavyChart'), {

loading: () => <div>Загрузка графика...</div>,

ssr: false

})

```

Tree Shaking

```javascript

// Плохо: тащим весь lodash (70 КБ+)

import _ from 'lodash'

// Хорошо: берём только нужное (1 КБ)

import chunk from 'lodash/chunk'

```

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

CLS возникает, когда реклама, изображения или динамический контент сдвигают элементы во время загрузки.

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

```html

<img src="photo.jpg" width="800" height="600" alt="фото">

<img src="photo.jpg" alt="фото">

```

Резервируйте место под рекламу

```css

.ad-container {

min-height: 250px; /* место зарезервировано заранее */

display: flex;

align-items: center;

justify-content: center;

}

```

Загрузка шрифтов

```css

@font-face {

font-family: 'MyFont';

src: url('/fonts/myfont.woff2') format('woff2');

font-display: swap; /* сначала системный шрифт, потом замена */

}

```

Чек-лист Lighthouse 90+ (30 пунктов)

**LCP (10 пунктов)**

[ ] Найти LCP-элемент (DevTools → вкладка Performance)

[ ] Добавить priority или preload для LCP-изображения

[ ] Перевести hero-изображение в WebP/AVIF

[ ] Использовать next/image

[ ] Подключить srcset для адаптивных размеров

[ ] Использовать CDN (Cloudflare Pages, Vercel Edge)

[ ] TTFB < 600 мс

[ ] SSG/ISR там, где возможно

[ ] Убрать лишние редиректы

[ ] Отложить все сторонние скрипты

**INP (10 пунктов)**

[ ] Проверить INP в Lighthouse

[ ] Удалить Long Tasks (50 мс+) через DevTools Performance

[ ] Тяжёлые вычисления — в Web Worker

[ ] JS-бандл < 200 КБ (сжатый)

[ ] Убрать ненужные полифилы

[ ] useMemo/useCallback в React

[ ] debounce/throttle для обработчиков событий

[ ] CSS-переходы вместо JS-анимаций

[ ] async/defer для сторонних скриптов

[ ] Оптимизировать порядок загрузки JS для LCP

**CLS (10 пунктов)**

[ ] Задать width/height для всех изображений и видео

[ ] Резервировать min-height для рекламных блоков

[ ] Динамический контент — вниз страницы

[ ] font-display: swap в @font-face

[ ] Предзагрузка шрифтов через link rel="preload"

[ ] Анимировать только transform/opacity

[ ] Скелетоны для резервирования места

[ ] Sticky/fixed элементы не сдвигают контент

[ ] Сохранять позицию прокрутки при infinite scroll

[ ] Фиксировать высоту вкладок через overflow: hidden

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

| Инструмент | Для чего | Ссылка |

|---|---|---|

| PageSpeed Insights | Реальные данные пользователей LCP/INP/CLS | pagespeed.web.dev |

| Lighthouse | Лабораторный тест производительности | Chrome DevTools → Lighthouse |

| WebPageTest | Тест из разных регионов мира | webpagetest.org |

| Chrome DevTools | Детальное профилирование | F12 → Performance |

| Core Web Vitals Report | Полевые данные CrUX для SEO | Search Console |

FAQ

**Q1. Насколько CWV влияют на позиции в Google?**

Google описывает это как «сигнал при равенстве» — когда контент одинаков, выигрывает более быстрый сайт. Мобильный Page Experience учитывает CWV как один из факторов ранжирования. Точный вес не раскрывается, но на практике разница между сайтами с LCP > 4 сек и < 2 сек хорошо заметна.

**Q2. Lighthouse 90+ = прошедший CWV?**

Не обязательно. Lighthouse — лабораторный тест; CWV опирается на реальные данные пользователей (CrUX). Идеальные 100 баллов в Lighthouse не гарантируют хорошие полевые данные. Для реального SEO-ранжирования смотрите отчёт Core Web Vitals в Search Console.