Core Web Vitals — фреймворк Google для измерения реального пользовательского опыта страницы, и это подтверждённый фактор ранжирования. Next.js даёт значительную фору по сравнению с большинством фреймворков, но плохо настроенный сайт на Next.js всё равно может проваливать эти метрики. Вот практический гайд по диагностике и исправлению каждой из них.
Шаг 1: Измерьте, Прежде Чем Исправлять
Прежде чем что-либо менять, получите точные базовые измерения. Есть два типа данных CWV:
Полевые данные (измерения реальных пользователей) — доступны в Google Search Console в разделе «Core Web Vitals» и в PageSpeed Insights как «Узнайте, что видят ваши реальные пользователи». Именно это использует Google для ранжирования. Требует достаточного трафика для статистической значимости.
Лабораторные данные — доступны в Lighthouse (Chrome DevTools → вкладка Lighthouse) и PageSpeed Insights. Полезны для разработки, но Google не использует их для решений о ранжировании.
Всегда исправляйте на основе полевых данных, где они доступны. Лабораторные показатели могут вводить в заблуждение — страница может получить 100 баллов в Lighthouse и всё равно иметь плохой полевой INP, если присутствует много клиентского JavaScript.
Шаг 2: Исправление LCP (Largest Contentful Paint)
LCP должен быть менее 2,5 секунды. Самые частые причины на сайтах Next.js:
Hero-изображения загружаются слишком поздно. Каждое hero-изображение должно использовать проп priority у next/image. Это указывает Next.js предзагрузить изображение и не применять ленивую загрузку:
<Image src="/hero.webp" alt="Hero" width={1200} height={600} priority />
Неправильный формат изображения. next/image автоматически отдаёт WebP и AVIF, но только если используется сам компонент. Если где-то есть теги <img> — проверьте рендереры Markdown и сторонние компоненты, — эти изображения не будут оптимизированы.
Медленный ответ сервера (TTFB). На Vercel TTFB должен быть менее 200 мс. Если выше, проверьте, не делаете ли вы медленные запросы к базе данных в generateStaticParams или компонентах layout. Предпочитайте статическую генерацию серверному рендерингу для страниц, контент которых меняется редко.
Шрифты, блокирующие рендеринг. Добавьте display: "swap" ко всем импортам Google Fonts в Next.js:
const inter = Inter({ subsets: ["latin"], display: "swap" });
Шаг 3: Исправление CLS (Cumulative Layout Shift)
CLS должен быть менее 0,1. Самые частые причины на сайтах Next.js:
Изображения без явных размеров. Всегда указывайте width и height у next/image. Компонент использует их, чтобы зарезервировать место до загрузки изображения, предотвращая сдвиг макета.
Веб-шрифты, вызывающие FOUT. Используйте font-display: swap (обрабатывается автоматически через next/font/google) и preconnect к источникам шрифтов. Избегайте загрузки шрифтов с CDN без preconnect.
Динамически добавляемые баннеры или уведомления о cookie. Если баннер cookie или уведомление появляется над контентом после загрузки страницы, оно сдвигает контент вниз и создаёт CLS. Зарезервируйте место в макете или используйте фиксированное позиционирование, чтобы оно накладывалось поверх, а не смещало контент.
Шаг 4: Исправление INP (Interaction to Next Paint)
INP должен быть менее 200 мс. Заменил FID в 2024 году и является самым сложным CWV для исправления, потому что измеряет интерактивность на протяжении всего жизненного цикла страницы, а не только при загрузке.
Тяжёлые клиентские компоненты. В Next.js App Router компоненты, не требующие интерактивности, должны быть серверными. "use client" должен появляться только тогда, когда реально нужны API браузера, обработчики событий или хуки. Ненужные клиентские компоненты увеличивают JavaScript-бандл, который нужно парсить и выполнять.
Блокировка основного потока. Большие JavaScript-бандлы, выполняющиеся синхронно, блокируют взаимодействие пользователя. Используйте динамические импорты для тяжёлых компонентов:
const HeavyComponent = dynamic(() => import("./HeavyComponent"), { ssr: false });
Сторонние скрипты. Аналитика, виджеты чата и рекламные скрипты — частый источник проблем с INP. Загружайте их через next/script со strategy="afterInteractive" или strategy="lazyOnload", чтобы отложить их выполнение до момента, когда страница станет интерактивной.
Шаг 5: Мониторинг После Исправления
Исправления не отражаются в полевых данных немедленно. Данные CrUX от Google (на которых основаны Search Console и полевые данные PageSpeed Insights) имеют скользящее окно в 28 дней. Ожидайте 4–6 недель после развёртывания исправлений, прежде чем полевые данные улучшатся.
В течение этого периода отслеживайте лабораторные показатели, чтобы подтвердить, что исправления работают. Настройте Vercel Analytics для непрерывного мониторинга Core Web Vitals реальных пользователей — он выявляет проблемы с INP, которые пропускают лабораторные инструменты.
Когда полевые данные догонят изменения, вы должны увидеть коррелирующие улучшения в органическом ранжировании, особенно у страниц, ранее находившихся в диапазоне «требует улучшения» или «плохо». Совместите эту работу с остальными пунктами нашего технического SEO чек-листа — Core Web Vitals — лишь один из 20 факторов, определяющих ранжирование.
Короткий Путь: Сразу Сделать Правильно
Каждый шаг этого гайда существует потому, что сайт не был построен с учётом этих факторов с самого начала. Самый экономически выгодный подход — строить на правильно настроенном фундаменте Next.js, который стартует с зелёными Core Web Vitals. Эти улучшения также напрямую влияют на бизнес помимо ранжирования — данные о скорости сайта и конверсии показывают, насколько это измеримо.
Наша услуга веб-дизайна и разработки по умолчанию включает техническое SEO и оптимизацию Core Web Vitals в каждом проекте. Если хотите узнать, где сейчас находится ваш сайт, бесплатный аудит точно покажет, какие метрики влияют на ваше ранжирование.
Готовы развивать свой бизнес онлайн? Получите бесплатный аудит →