Web Vitals ломают не дизайн, а конверсию: где искать узкие места

Web Vitals ломают не дизайн, а конверсию: где искать узкие места

В Next.js и Vercel Web Vitals лучше смотреть не как «оценку сайта», а как карту риска: где пользователь видит пустой экран, где интерфейс дергается, а где страница отвечает слишком поздно. Для edge_compute и ssr это особенно важно: быстрый серверный ответ не спасает, если клиент потом долго дорисовывает DOM.

— LCP: проверь, что попадает в первый крупный элемент. Часто это hero-картинка, тяжелый шрифт или блок из нескольких запросов.
— INP: ищи лишний JavaScript на клиенте, долгие обработчики и цепочки setState.
— CLS: фиксируй размеры медиа, не вставляй баннеры и виджеты без reserved space.
— TTFB: смотри на SSR, кеш и путь до данных; иногда медленный API убивает весь выигрыш от edge.

На практике лучший порядок такой: сначала убираешь лишний JS, потом стабилизируешь layout, потом оптимизируешь запросы и только после этого полируешь картинки и шрифты. Иначе можно получить «зелёные» метрики в лаборатории и плохой реальный UX на мобилках.

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