В конце мая Google объявил о будущем обновлении Page Experience, а вместе с ним в SEO-разговор вошли Core Web Vitals. В июне 2020 года это пока не «новый алгоритм, который уже уронил сайт», а предупреждение и понятный список метрик, на которые стоит посмотреть заранее.
Google отдельно сказал, что изменения в ранжировании не будут включены немедленно. Компании обещали не меньше шести месяцев предупреждения до запуска. Поэтому сейчас есть редкая роскошь: можно заняться пользовательским опытом до того, как он превратится в срочную задачу с пометкой «вчера».
Что входит в Core Web Vitals
На июнь 2020 года в набор входят три показателя:
- LCP, Largest Contentful Paint – когда основной крупный элемент страницы появился в видимой области. Хорошим ориентиром считается до 2,5 секунды.
- FID, First Input Delay – задержка перед обработкой первого взаимодействия пользователя. Хороший ориентир – до 100 миллисекунд.
- CLS, Cumulative Layout Shift – насколько неожиданно прыгает содержимое страницы. Хороший ориентир – не больше 0,1.
Метрики смотрят на разные раздражители. LCP отвечает на вопрос «страница уже появилась или я пока любуюсь пустым экраном». FID – «после клика сайт вообще услышал меня». CLS – «почему кнопка уехала именно в тот момент, когда я по ней нажал».
Почему одного Lighthouse мало
Лабораторный тест полезен для поиска причин, но он не знает всех ваших пользователей. У одного человека быстрый ноутбук и домашний Wi-Fi, у другого старый телефон и мобильная сеть в лифте. Реальное качество страницы видно в полевых данных, собранных у настоящих посетителей.
Google использует данные Chrome User Experience Report, а владельцу сайта доступны отчёты PageSpeed Insights и Search Console. Важно не смешивать результаты: лабораторный прогон показывает условия конкретного теста, а полевые данные отражают распределение опыта пользователей за период.
И ещё одна неприятная, но полезная деталь: оценивать нужно не только главную страницу. У статьи, каталога, карточки товара и страницы контактов могут быть разные самые большие элементы, скрипты и поведение интерфейса.
Откуда берутся плохие показатели
LCP
Плохой LCP часто начинается ещё до браузера: медленный сервер, длинная цепочка редиректов, тяжёлый CSS, блокирующие скрипты, крупный ресурс в первом экране. Сначала стоит понять, какой именно элемент стал LCP, а потом уже оптимизировать его. «Уменьшить всё на сайте» звучит энергично, но не является планом.
FID
FID страдает, когда главный поток браузера занят долгими задачами JavaScript. Большой бандл, десяток маркетинговых скриптов и тяжёлый обработчик клика легко превращают простую кнопку в упражнение на терпение. На практике помогает уменьшение JavaScript, разбиение длинных задач и перенос второстепенных функций за пределы первого взаимодействия.
CLS
CLS появляется, когда контент меняет место после начала загрузки. Классические виновники: изображения без зарезервированного размера, баннеры, рекламные блоки, поздно загружаемые шрифты и вставка уведомления прямо над текстом. Если место под элемент известно заранее, его нужно занять заранее. Это не магия, а обычная аккуратность в верстке.
Что делать владельцу сайта в 2020 году
- Собрать список важных шаблонов и страниц, а не тестировать только главную.
- Проверить Search Console и PageSpeed Insights, разделяя field data и lab data.
- Найти конкретный элемент, который ухудшает LCP или вызывает CLS.
- Сократить сторонние скрипты и проверить, что действительно нужно маркетингу.
- Проверить мобильные устройства отдельно. Десктопный результат не заменяет мобильный.
- После исправлений подождать накопления новых полевых данных, а не делать вывод по одному тесту.
Не стоит превращать Core Web Vitals в соревнование за зелёный кружок. Быстрая страница без понятного контента не станет полезной, а идеальный лабораторный балл не гарантирует, что реальному посетителю удобно. Метрики нужны, чтобы найти трение и убрать его, а не чтобы любоваться цифрой.
В 2020 году Google дал владельцам сайтов список будущих сигналов Page Experience: LCP, FID и CLS. Это хороший момент проверить скорость, отзывчивость и стабильность интерфейса до запуска изменений. Начинать нужно с реальных страниц и полевых данных, а не с бесконечного перебора настроек оптимизатора.
Сайт не обязан быть быстрым в лаборатории ради лаборатории. Он должен быстро показать смысл, принять действие пользователя и не подставить кнопку под палец, который уже нажимает. Остальное – техника измерения и немного дисциплины.