Core Web Vitals

Что Такое Core Web Vitals? #

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

Для QA-инженера понимание этих метрик важно, потому что:

• Они влияют на SEO-рейтинги (видимость в поиске)
• Они коррелируют с вовлечённостью пользователей и конверсией
• Они предоставляют объективные, измеримые критерии для приёмочного тестирования производительности
• Они всё чаще включаются в бюджеты производительности и критерии релиза

Три Core Web Vitals #

LCP — Largest Contentful Paint #

Что измеряет: Время от начала загрузки страницы до рендеринга самого большого элемента контента во viewport.

Хороший порог: Менее 2.5 секунд

Что считается «самым большим элементом»:

• Изображения (<img>, <image> внутри SVG)
• Постеры видео
• Фоновые изображения, загруженные через url()
• Блочные текстовые элементы (<h1>, <p> и т.д.)

Типичные причины плохого LCP:

• Медленное время ответа сервера (высокий TTFB)
• JavaScript и CSS, блокирующие рендеринг
• Медленная загрузка ресурсов (большие изображения, неоптимизированные шрифты)
• Задержки рендеринга на стороне клиента (SPA-фреймворки)

INP — Interaction to Next Paint #

Что измеряет: Отзывчивость страницы на действия пользователя (клики, тапы, нажатия клавиш) на протяжении всего жизненного цикла. INP — это наихудшая задержка взаимодействия, исключая выбросы.

Хороший порог: Менее 200 миллисекунд

Как это работает:

1. Пользователь нажимает кнопку
2. Браузер обрабатывает event handler (JavaScript)
3. Браузер обновляет визуальное отображение
4. INP измеряет общее время от шага 1 до шага 3

Типичные причины плохого INP:

• Длительные JavaScript-задачи, блокирующие основной поток
• Избыточный размер DOM (>1500 элементов)
• Сложные event handlers без оптимизации
• Сторонние скрипты, конкурирующие за основной поток

CLS — Cumulative Layout Shift #

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

Хороший порог: Менее 0.1

Расчёт CLS:

Оценка Layout Shift = Доля воздействия × Доля расстояния

• Доля воздействия: Площадь viewport, затронутая сдвигом
• Доля расстояния: Насколько далеко сместился элемент относительно viewport

Типичные причины плохого CLS:

• Изображения и реклама без явных размеров width/height
• Динамически внедряемый контент выше существующего
• Веб-шрифты, вызывающие перерисовку текста (FOIT/FOUT)
• Поздно загружающиеся встраиваемые элементы третьих сторон

Измерение Core Web Vitals #

Лабораторные Данные (Разработка/Тестирование) #

Лабораторные данные собираются в контролируемой среде. Они воспроизводимы, но не отражают реальные условия пользователей.

Полевые Данные (Реальные Пользователи) #

Полевые данные поступают от реальных пользователей сайта. Они отражают реальные условия, но требуют объёма трафика.

Использование Вкладки Performance в DevTools #

1. Откройте DevTools > вкладка Performance
2. Нажмите на шестерёнку и включите Web Vitals
3. Нажмите Record и перезагрузите страницу
4. Остановите запись после полной загрузки страницы
5. Найдите дорожку Web Vitals с маркерами LCP, CLS
6. Панель Summary показывает детализацию по времени

Стратегии Тестирования Core Web Vitals #

Чек-лист Тестирования LCP #

• Измерьте LCP на лендинге, страницах продуктов и статьях блога
• Тестируйте с ограниченной сетью (Slow 3G, Fast 3G, 4G)
• Тестируйте с ограничением CPU (4x, 6x замедление)
• Проверьте, что LCP-элемент — это нужное hero-изображение/текст, а не случайный элемент
• Убедитесь, что LCP не деградирует после новых деплоев
• Тестируйте с пустым и прогретым кэшем

Чек-лист Тестирования INP #

• Кликните на каждый интерактивный элемент и отметьте, если какой-то ощущается медленным
• Протестируйте отправку форм, выпадающие меню и открытие модальных окон
• Тестируйте во время загрузки страницы (частично загруженное состояние)
• Используйте DevTools Performance для поиска длинных задач (>50 мс)
• Тестируйте с ограничением CPU для имитации слабых устройств

Чек-лист Тестирования CLS #

• Наблюдайте за загрузкой страницы от начала до конца — фиксируйте визуальные прыжки
• Прокрутите всю страницу, наблюдая за сдвигами
• Тестируйте с медленной сетью для выявления сдвигов при прогрессивной загрузке
• Проверьте, что у всех изображений есть явные атрибуты width и height
• Тестируйте с отключёнными блокировщиками рекламы (реклама — частая причина CLS)
• Проверьте загрузку шрифтов — перерисовывается ли текст при загрузке веб-шрифтов?

Упражнение: Аудит Core Web Vitals #

Проведите аудит Core Web Vitals на веб-сайте по вашему выбору (сайт вашей компании, личный проект или известный публичный сайт).

Шаг 1: Сбор Лабораторных Данных #

Откройте сайт в Chrome с DevTools:

1. Перейдите на вкладку Performance
2. Включите Web Vitals в настройках
3. Настройте throttling: CPU 4x замедление, сеть Fast 3G
4. Запишите свежую загрузку страницы (сначала очистите кэш через Ctrl+Shift+Delete)
5. Зафиксируйте следующие значения:

Шаг 2: Определение LCP-Элемента #

В записи Performance:

1. Найдите маркер LCP на дорожке Web Vitals
2. Кликните на него, чтобы увидеть, какой элемент вызвал LCP
3. Задокументируйте: Какой это элемент? Является ли он ожидаемым hero-контентом?

Шаг 3: Поиск Сдвигов Макета #

1. В записи найдите розовые полосы в строке Experience
2. Кликните на каждый layout shift, чтобы увидеть, какие элементы сдвинулись
3. Задокументируйте каждый сдвиг: Какой элемент? На сколько сдвинулся? Что стало причиной?

Шаг 4: Тестирование Взаимодействий #

1. Запишите новую сессию performance
2. Кликните на 5-10 интерактивных элементов (кнопки, ссылки, меню, поля формы)
3. Ищите длинные задачи (жёлтые блоки >50 мс), вызванные вашими взаимодействиями
4. Задокументируйте любое взаимодействие, которое занимает более 200 мс для визуального отклика

Автоматизированный Мониторинг Core Web Vitals #

Для непрерывного контроля качества интегрируйте Core Web Vitals в CI/CD pipeline:

# Используя Lighthouse CI
npm install -g @lhci/cli

# Запуск Lighthouse с assertions
lhci autorun --config=lighthouserc.json

Пример lighthouserc.json с порогами Core Web Vitals:

{
  "ci": {
    "assert": {
      "assertions": {
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}],
        "total-blocking-time": ["error", {"maxNumericValue": 200}]
      }
    }
  }
}

Это проваливает сборку при превышении порогов Core Web Vitals, предотвращая деградацию производительности в продакшене.

Ключевые Выводы #

• Core Web Vitals состоит из трёх метрик: LCP (загрузка), INP (интерактивность) и CLS (визуальная стабильность)
• INP заменил FID в марте 2024 года и измеряет отзывчивость на протяжении всего жизненного цикла страницы
• Используйте как лабораторные данные (DevTools, Lighthouse), так и полевые данные (CrUX, Search Console) для полной картины
• Каждая метрика требует специфических стратегий тестирования — не ограничивайтесь проверкой агрегированной оценки
• Интегрируйте пороги Core Web Vitals в CI/CD для предотвращения регрессий
• Плохие Core Web Vitals напрямую влияют на SEO-рейтинги и вовлечённость пользователей