Core Web Vitals: как ускорить сайт и не сломать его

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

Что означают три метрики

LCP: почему главный блок появляется медленно

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

import Image from "next/image"

<Image
  src="/hero.jpg"
  alt="Производственный цех предприятия"
  width={1600}
  height={900}
  // priority отключает ленивую загрузку и добавляет
  // подсказку браузеру загрузить файл заранее
  priority
  // Размеры по контрольным точкам: браузер скачает
  // подходящий вариант, а не самый большой
  sizes="(max-width: 768px) 100vw, (max-width: 1280px) 90vw, 1200px"
  className="w-full h-auto"
/>

• Проверьте формат: современные форматы дают выигрыш в полтора-три раза без видимой потери качества.
• Не ставьте priority более чем на одно-два изображения: приоритет для всего означает отсутствие приоритета.
• Уберите ленивую загрузку с изображения первого экрана — она в этом случае замедляет, а не ускоряет.
• Шрифты подключайте средствами фреймворка с запасным вариантом: иначе текст ждёт загрузки файла шрифта.

INP: почему интерфейс не отвечает на нажатие

Отклик страдает, когда главный поток занят выполнением JavaScript. Типичные причины — большой объём скриптов сторонних сервисов и тяжёлые вычисления в обработчиках. Первое лечится отложенной загрузкой, второе — переносом работы с ввода на отдельный шаг.

import Script from "next/script"

// Аналитика не нужна до того, как страница стала интерактивной
<Script
  src="https://example-analytics.com/tag.js"
  strategy="lazyOnload"
/>

// Скрипт, необходимый для работы страницы, но не для первого экрана
<Script
  src="/widgets/calculator.js"
  strategy="afterInteractive"
/>

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

import { useDeferredValue, useMemo, useState } from "react"

export function ProductSearch({ items }: { items: Product[] }) {
  const [query, setQuery] = useState("")
  // Поле ввода реагирует сразу, фильтрация догоняет
  const deferredQuery = useDeferredValue(query)

  const filtered = useMemo(
    () => items.filter((item) => item.name.toLowerCase().includes(deferredQuery.toLowerCase())),
    [items, deferredQuery],
  )

  return (
    <>
      <input value={query} onChange={(event) => setQuery(event.target.value)} />
      <ProductList items={filtered} />
    </>
  )
}

CLS: почему содержимое прыгает

Смещение вёрстки — самая раздражающая проблема: посетитель нажимает на ссылку, а под курсором оказывается другой элемент. Причина всегда одна — место под элемент не зарезервировано заранее.

• Указывайте ширину и высоту всех изображений и видео, даже если размер задаётся через стили.
• Резервируйте место под баннеры и рекламные блоки контейнером фиксированной высоты.
• Не вставляйте блоки над уже отрисованным содержимым: уведомления показывайте наложением, а не вставкой в поток.
• Задавайте запасной шрифт с близкими метриками, чтобы подмена не меняла высоту строк.

Порядок работ

Оптимизацию имеет смысл делать в порядке отношения эффекта к трудозатратам. По нашему опыту первые три пункта дают восемьдесят процентов результата.

1. 01Изображения: форматы, размеры, приоритет первого экрана.
2. 02Скрипты сторонних сервисов: отложить всё, что не нужно для первого экрана.
3. 03Шрифты: подключение через фреймворк, запасной вариант с близкими метриками.
4. 04Резервирование места под всё, что подгружается позже.
5. 05Разделение бандла: подгружать тяжёлые компоненты только там, где они используются.
6. 06Кэширование ответов сервера для страниц, которые не меняются на каждом запросе.

Ускорение сайта почти никогда не требует переписывания. Обычно достаточно перестать отдавать изображения в исходном разрешении и загружать аналитику раньше содержимого.