Коротко
- В CWV три метрики, LCP, INP и CLS. INP заменил FID в марте 2024 года.
- Хорошие значения считаются по 75-му перцентилю визитов, отдельно для мобильных и десктопа.
- Lighthouse не измеряет INP, потому что в лабораторном тесте нет действий пользователя. Вместо него он показывает TBT.
- Данные CrUX считаются скользящим окном за 28 дней, правка отражается в них постепенно.
- ИИ полезен в разборе трассировок, группировке URL по шаблонам и черновиках правок. Причину он подтверждать не умеет.
- Правку считают принятой, когда улучшились полевые данные шаблона. Удачный прогон PageSpeed Insights для этого мало что значит.
Какие метрики входят в CWV
Сейчас в Core Web Vitals три метрики. Пороги взяты из документации web.dev.
Страница проходит оценку, если все три метрики в зеленой зоне на 75-м перцентиле. Google в документации Search Central пишет, что CWV вместе с другими аспектами удобства страницы соответствуют тому, что поощряют основные системы ранжирования, и советует добиваться хороших значений. Прямого обещания роста позиций за зеленые метрики там нет.
Полевые и лабораторные данные
Полевые данные собраны у реальных пользователей Chrome. Лабораторные получены одним тестом на одном устройстве с заданной сетью. Расходятся они почти всегда, и web.dev объясняет почему.
Почему цифры не совпадают
- В лаборатории кэш пустой, а вернувшиеся посетители загружают часть ресурсов из кэша.
- В поле разные устройства и сети, в лаборатории одно устройство.
- Элемент LCP в тесте может отличаться от того, что видят пользователи. На это влияет размер экрана, вход в аккаунт, A/B-тесты.
- Сдвиги макета и задержки отклика при прокрутке и кликах попадают в поле и почти не попадают в лабораторию.
Что когда использовать
Web.dev советует расставлять приоритеты по полевым данным, а лабораторные брать для отладки. Есть оговорка про CrUX. В отчет попадают только публично доступные и достаточно посещаемые страницы, поэтому у части URL полевых данных не будет, и тогда смотрят данные по всему домену или собирают свои через web-vitals.
Что может автоматизировать ИИ
Нейросеть быстро читает длинные текстовые артефакты, на которые у человека уходит полдня. Замер после правки за нее никто не отменял.
Задачи, где модель помогает
- Разбор трассировки из вкладки Performance. Модель выделяет длинные задачи, сторонние скрипты, порядок загрузки ресурса LCP.
- Группировка URL из CrUX или RUM по шаблонам, чтобы искать проблему в шаблоне, а не в отдельной странице.
- Чтение отчета Lighthouse и перевод диагностики в задачи для разработчика.
- Черновик правки, например атрибуты fetchpriority и размеры изображений, перенос скрипта, резерв места под баннер.
- Скрипт для выгрузки данных из CrUX API или PageSpeed Insights API по списку URL.
Где автоматизация без ИИ надежнее
Сам сбор метрик надежнее отдать обычным инструментам. Lighthouse CI в сборке, web-vitals на сайте, регулярные запросы к CrUX API. Нейросеть здесь не нужна, а ошибка в ее выводе обойдется дороже, чем написать скрипт один раз.
Где модель ошибается
Модель не видит пользователей. Она получает то, что вы ей дали, обычно один отчет Lighthouse или кусок кода, и строит объяснение, которое звучит убедительно.
Типовые ошибки
- Причина по одному прогону. Lighthouse на мобильной эмуляции показал медленный LCP, модель предлагает переписать слайдер, а в поле LCP шаблона зеленый.
- INP по лабораторным данным. TBT подсказывает, что основной поток занят, но какое именно взаимодействие медленное у пользователей, видно только в поле.
- Совет убрать скрипт без знания бизнеса. Модель не знает, что этот скрипт отвечает за аналитику заказов или виджет оплаты.
- Устаревшие рекомендации. Модель может советовать оптимизировать FID, хотя эта метрика больше не входит в CWV.
- Связь по совпадению. Метрика улучшилась в ту же неделю, что вышла правка, и модель называет правку причиной, хотя изменился трафик или сезон.
Как проверять ответ модели
Передавайте модели полный контекст и требуйте ссылку на артефакт. Если она пишет, что LCP тормозит из-за шрифта, попросите показать строку трассировки или запрос в waterfall, где это видно. Если показать нечего, вывод в задачу разработчику не попадает.
Еще одна привычка, которая экономит время. Задавайте вопрос про конкретную часть метрики, а не про скорость вообще. На вопрос, почему задержка отрисовки LCP на карточке больше загрузки ресурса, модель отвечает по делу. На вопрос, как ускорить сайт, она выдает длинный общий список, и большая часть советов к вашему шаблону не относится.
Последнее правило касается кода. Правку, которую написала модель, проверяет разработчик, который знает проект, и только на тестовом стенде. Изменения в порядке загрузки скриптов легко ломают аналитику и оплату, а в лабораторном тесте это не видно.
Процесс диагностики
Порядок одинаковый для всех трех метрик. Сначала поле, потом лаборатория, потом гипотеза и ее проверка.
- Возьмите полевые данные по группам URL из Search Console и CrUX, отдельно мобильные и десктоп.
- Выберите шаблон с худшей метрикой и наибольшим трафиком.
- Найдите в поле, что именно медленное. Для LCP это элемент и его тип, для INP конкретное взаимодействие, для CLS элемент, который сдвигается.
- Воспроизведите проблему в лаборатории на типичном URL шаблона.
- Разложите метрику на части и найдите часть, которая выбивается.
- Сформулируйте гипотезу и правку. На этом шаге удобно подключать нейросеть.
- Проверьте правку в лаборатории, затем выкатите и ждите полевые данные.
Пример трассировки LCP
Web.dev делит LCP на четыре части и дает ориентир по долям. TTFB и загрузка ресурса примерно по 40%, задержка начала загрузки и задержка отрисовки меньше 10% каждая. Части имеет смысл сравнивать только между собой.
Запишите значения всех четырех частей до правки и после, на одном URL, устройстве и профиле сети. Без этой записи вывод "правка ускорила LCP" проверить нельзя.
INP и CLS
INP раскладывается на задержку ввода, обработку событий и задержку отрисовки следующего кадра. Атрибуция в библиотеке web-vitals показывает, какая часть медленная у пользователей. Для CLS частые причины перечислены на web.dev. Изображения и видео без width и height, реклама и встраивания без зарезервированного места, контент, который вставляется сверху после загрузки, шрифты, анимация через top и left вместо transform.
Комментарий Q2 AgencyМы просим нейросеть объяснить трассировку, но не спрашиваем ее, что ускорит сайт. Второй вопрос без полевых данных дает правдоподобный список, и команда неделю чинит то, что пользователи не замечали.
Приемка исправлений
Правку принимают в два этапа. Сначала лаборатория, потом поле.
В лаборатории сравните части метрики до и после на тех же условиях, несколько прогонов, а не один. В поле ждите, пока CrUX накопит данные после релиза. Данные обновляются ежедневно, но это скользящее среднее за 28 дней, поэтому полный эффект виден через четыре недели. Отчет CWV в Search Console строится на тех же данных CrUX и меняется не быстрее. После исправления в нем можно запустить проверку, и проблема считается решенной, если за 28 дней она не появилась ни на одном URL группы.
Если у сайта свой RUM на web-vitals, эффект виден раньше, по визитам после релиза. Сравнивайте одинаковые дни недели и учитывайте источник трафика, рекламная кампания с дешевых мобильных устройств может ухудшить метрики без всякой регрессии в коде.
Мониторинг
После приемки метрика должна оставаться в контуре контроля. Проверку скорости стоит встроить в общий мониторинг сайта, как описано в статье про автоматизацию технического SEO.
Минимальный набор такой.
- Lighthouse CI в сборке с порогами по шаблонам, чтобы ловить регрессии до релиза.
- Ежедневная выгрузка CrUX API по главным URL шаблонов и по домену.
- RUM на web-vitals с атрибуцией для INP.
- Еженедельный просмотр отчета CWV в Search Console по группам URL.
Скорость не единственная техническая проблема. Если страница медленная и при этом не в индексе, сначала разберитесь с индексацией по шагам из статьи о том, почему Google не индексирует сайт. Общий список проверок есть в материале про SEO-аудит сайта, а аудит производительности по полевым данным мы делаем в рамках услуги SEO-аудит.
Частые вопросы
Источники
- Web Vitals, web.dev
- Interaction to Next Paint becomes a Core Web Vital on March 12, web.dev
- Why lab and field data can be different, web.dev
- Optimize Largest Contentful Paint, web.dev
- Optimize Interaction to Next Paint, web.dev
- Optimize Cumulative Layout Shift, web.dev
- Understanding Core Web Vitals and Google search results, Google Search Central
- CrUX API, Chrome for Developers
- CrUX methodology, Chrome for Developers
- Core Web Vitals report, Search Console Help
Основатель Q2 Agency, бывший директор по маркетингу: работал в Яндексе, Xsolla, Cheelee и Allen Carr’s Easyway. Специализация - нейромаркетинг, воронки продаж и сквозная аналитика.
