Оптимизация скорости сайта в 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.