Как проверить Core Web Vitals при редизайне
При редизайне Core Web Vitals сравнивают с учётом версии страницы и окна наблюдений.
Регрессионный паспорт Core Web Vitals для редизайна
При редизайне Core Web Vitals проверяют как регрессию между совместимыми версиями, а не как одиночный балл новой страницы. Паспорт фиксирует старый и новый шаблон, URL-группу, период, устройство, покрытие данными реальных пользователей, лабораторную запись выполнения, функциональные контрольные ограничения и условие отката. Полевые данные новой версии появляются с задержкой и могут смешиваться со старой, поэтому раннее решение опирается на сопоставимую лабораторную проверку и RUM с идентификатором версии, а окончательное — на накопившийся срез данных реальных пользователей.
Матрица «до и после» и условия отката
Сравнение ведут по шаблонам и версиям, а не по случайным единичным адресам. Каждая строка содержит технический сигнал, функциональное ограничение и заранее согласованное действие при ухудшении.
| Объект сравнения | Совместимое доказательство | Условие отката |
|---|---|---|
| Шаблон первого экрана | Одинаковый профиль холодной загрузки, одна область просмотра, LCP-элемент и разложение его времени в старой и новой сборке | Вернуть предыдущий ресурс/разметку, если новая версия добавила неподтверждённую задержку обнаружения или отрисовки |
| Навигация и интерактив | Один сценарий клика/клавиатуры, запись выполнения длинных задач и визуальная обратная связь | Откатить компонент, если ухудшение INP или потеря фокуса мешает завершить ключевой переход |
| Динамические блоки | Сопоставимый набор баннеров, ошибок формы и загружаемых данных; названы источники CLS | Откатить позднюю вставку, если целевая кнопка или поле смещается в момент взаимодействия |
| Форма и атрибуция | Одинаковые обязательные поля, согласие на обработку данных, правила отправки формы и состояние серверной системы | Не выпускать редизайн, если успешная отправка, первый источник перехода или доступная ошибка отличаются от исходного состояния |
| Наблюдение реальных пользователей | RUM размечен версией; CrUX трактуется с учётом 28-дневного окна и покрытия | Не объявлять победу или поражение, пока версии смешаны и направление нельзя отделить |
Как вести регрессионный паспорт
- 1Заморозить исходное состояние: идентификатор исходного кода и сборки, список шаблонов, устройства, период наблюдения реальных пользователей и функциональные проверки до переключения.
- 2Разметить новую версию в системе наблюдения за реальными пользователями без персональных данных и подготовить одинаковые лабораторные профили для критических маршрутов.
- 3Сопоставить LCP-элемент, запись выполнения взаимодействия и источники CLS; изменение самого измеряемого элемента записать отдельно.
- 4Проверить форму, фокус с клавиатуры, согласие на обработку данных, атрибуцию и состояние серверной системы как контрольные ограничения, не подменяя их общей оценкой быстродействия.
- 5Переключать постепенно, держать старую сборку доступной для отката и назначить дату решения по данным реальных пользователей после достаточного покрытия.
Сценарий: новый первый экран красивее, но позднее обнаруживается
В редизайне статичное изображение заменили клиентской каруселью и новым веб-шрифтом. Визуально первый экран выглядит цельным, однако LCP-ресурс появляется только после выполнения JavaScript, а заголовок меняет размеры после загрузки шрифта. Паспорт сравнивает один и тот же сценарий холодной загрузки, фиксирует две независимые регрессии и оставляет форму/атрибуцию неизменными. Команда возвращает серверно доступный первый кадр, ограничивает подмену шрифта и повторяет развёртывание. Срез реальных пользователей оценивается позже, не смешиваясь с мгновенным лабораторным выводом.
Вывод. Без номера версии, исходного состояния и плана отката Core Web Vitals при редизайне превращаются в спор по скриншотам. Регрессионный паспорт сохраняет причинность и не позволяет улучшать метрику ценой работающего маршрута.
Вопросы по этому сценарию
Можно ли сравнить CrUX сразу после выкладки редизайна?
Полный сигнал реальных пользователей появляется не мгновенно и может содержать посещения обеих версий. Для раннего решения используйте сопоставимый лабораторный прогон и RUM с указанием версии, а CrUX трактуйте после достаточного окна и покрытия. В отчёте явно разделяйте эти источники.
Нужно ли откатывать весь редизайн из-за одной плохой метрики?
Не всегда. Если причина изолирована, безопаснее откатить конкретный ресурс или компонент и сохранить прошедшие части. Полный откат нужен, когда регрессия затрагивает общий шаблон, критический путь или не может быть отделена от других изменений.
Как не потерять поисковую видимость и аналитику при исправлении скорости?
Канонический адрес, URL, метаданные, видимые материалы и события проверяются как отдельные контрольные ограничения. Оптимизация быстродействия не должна менять их молча. Перед развёртыванием сохраните исходное состояние и повторите статическую проверку, проверку опубликованной версии и правил отправки формы.
Официальные источники
- Лабораторные данные и данные реальных пользователей: почему данные расходятся — Ограничения мгновенного сравнения после релиза и влияние среды реальных пользователей.
- Методология CrUX — Что представляет набор данных реальных пользователей и почему важны покрытие и область агрегации.
Сразу после релиза полевые отчёты могут содержать посещения прежнего интерфейса.
Разделите данные до и после
- 1Сохраните дату выпуска, список изменённых шаблонов и лабораторную базу прежней версии. Отдельно отметьте изменения содержания первого экрана.
- 2Проверьте новые LCP-элементы, ключевые взаимодействия и источники сдвига в воспроизводимых условиях.
- 3В полевом отчёте укажите период, устройство и уровень агрегирования. Не называйте смешанное окно чистым результатом редизайна.
- 4Если используется собственный сбор показателей, связывайте наблюдения с версией без передачи персональных данных. Проверьте корректность самого измерения.
Пример: два разных крупнейших элемента
Условный редизайн заменяет текстовый первый экран большой фотографией. Сравнение общего веса файлов не объясняет новый LCP: нужно проверить обнаружение и загрузку именно фотографии. Команда исправляет её загрузку, а затем повторяет проверку шрифта и формы, которые могли получить меньше ресурсов.
Решение по релизу
Отделите подтверждённую лабораторную регрессию от ещё не созревшего полевого результата. Сохраните проблемный элемент, исправление и повторный прогон. Карта приёмки должна содержать дату следующего анализа реальных посещений, а не неподтверждённое обещание немедленного улучшения всех отчётов.