Скорость сайта и Core Web Vitals: что мерить и что чинить

Три метрики: что видит посетитель и как считают оценку

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

Пустой экран. Вы открыли страницу, наверху серый прямоугольник, главная фотография догружается. Три секунды - и она на месте. Эти три секунды и есть время отрисовки основного содержимого (Largest Contentful Paint, LCP): сколько прошло от начала загрузки до появления самого крупного видимого элемента. Чаще всего это картинка в шапке или крупный заголовок. Хорошая оценка - до 2,5 секунды.

Кнопка не отвечает. Нажали «Отправить заявку», ничего не изменилось. Нажали второй раз - форма ушла дважды. Задержку между нажатием и первой видимой реакцией меряет отклик на действие (Interaction to Next Paint, INP). Хорошая оценка - до 200 миллисекунд. INP заменил старую метрику FID в марте 2024 года, поэтому любая инструкция, где упоминается FID, отстала от текущей методики.

Страница дернулась. Вы целитесь в ссылку, сверху догружается баннер, содержимое уезжает вниз, палец попадает в рекламу. Это сдвиг макета (Cumulative Layout Shift, CLS). Величина безразмерная: считается, какая часть экрана сдвинулась и как далеко. Хорошая оценка - до 0,1.

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

Дальше жестче. Страница проходит проверку, только когда все три метрики уложились в пороги. Одной желтой хватает, чтобы вся страница считалась непрошедшей.

Между зеленой и красной зонами есть промежуточная. Для LCP она тянется от 2,5 до 4 секунд, для INP - от 200 до 500 миллисекунд, для CLS - от 0,1 до 0,25. Это зона «Требует улучшения»: катастрофы нет, зачета тоже.

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

Лабораторные и полевые данные: почему цифры разные

Владелец сайта открывает PageSpeed Insights, видит два блока с разными числами и не понимает, какому верить. Верить нужно обоим, потому что они отвечают на разные вопросы.

Полевые данные собираются с браузеров тех, кто заходил на сайт. Chrome отправляет замеры, они копятся 28 дней и показываются, если посещений набралось достаточно для выводов. У молодого сайта или редко посещаемой внутренней страницы полевых данных может не быть вовсе. Оценка Core Web Vitals считается по этому блоку и ни по какому другому.

Лабораторный замер - разовый тест на эмуляции среднего телефона и медленного канала. Он воспроизводим: прогнали дважды, получили близкие числа. Нужен, чтобы найти причину.

Балл от нуля до ста, тот самый крупный цветной круг наверху отчета, взят из лабораторного теста. Это взвешенная сумма нескольких технических показателей, среди которых есть и лабораторный LCP. Оценкой по Core Web Vitals балл не считается никогда.

На созвоне это превращается в спор. Подрядчик показывает 96 баллов и просит подписать акт, а в Google Search Console у клиента группа адресов висит в зоне «Требует улучшения». Правы оба. Подрядчик замерил страницу на эмуляции, поиск посмотрел на посетителей, которые заходят с телефонов в метро.

Полевые данные показывают два инструмента. Проверка одной страницы в PageSpeed Insights показывает верхний блок с оценкой за 28 дней. Search Console дает ту же информацию по всему сайту сразу и с историей. Если у конкретной страницы посещений мало, инструмент подставит данные по домену целиком. Это видно по подписи над блоком. Путать одно с другим не стоит: домен может быть зеленым за счет главной, пока половина внутренних страниц тонет.

Когда полевых данных нет вовсе, остается лабораторный тест. Он покажет, где узкое место, но вердикт по нему выносить нельзя. Сайт компании с двумя сотнями посещений в месяц не наберет статистики никогда, и гнаться за зеленой оценкой владельцу бессмысленно - там работают другие рычаги.

Правки не отражаются в полевых данных сразу. Окно скользящее, старые замеры вымываются постепенно. Полностью новая картина складывается примерно за 28-30 дней. Если через три дня после переезда на новый хостинг цифры в отчете Search Console не изменились, это нормальный ход событий.

Что чинить в первую очередь под каждую метрику

Начинать надо с того, что попадает на первый экран. Остальное - потом. Элемент, который посетитель не видит в первые секунды, на оценку почти не влияет.

LCP. Причины от частых к редким:

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

INP. Здесь чужой код виноват чаще, чем свой:

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

CLS. Список короткий и от сайта к сайту одинаковый:

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

Раскрытая диагностика в PageSpeed Insights показывает список с экономией в секундах. В работу берите верхние три пункта, дальше выигрыш становится мелким.

CLS суммирует все сдвиги за время жизни страницы, а не только те, что попали на первый экран.

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

Задачу разработчику формулируйте через метрику и элемент, а не через балл. «Поднять PageSpeed до 90» - плохая постановка, под нее можно отключить половину функциональности сайта. «Уложить LCP главной в 2,5 секунды на мобильных, элемент LCP - баннер в шапке» - постановка, которую можно принять по факту.

На картинки и сторонние скрипты приходится большая часть провала. Частая картина: красный LCP держит одна фотография в слайдере на первом экране. Сжали, задали приоритет - метрика ушла в зеленую зону без единой строчки нового кода. До минификации CSS и разбора длинных задач дело доходит редко, и это уже работа для разработчика.

Мобильная версия: где теряется больше всего

Полевые данные считаются раздельно для телефонов и компьютеров. Почти всегда проседают телефоны, и верстка тут ни при чем. Дело в устройстве и канале: замер идет по среднему аппарату посетителя, а не по флагману на столе у директора.

Сильнее всего это видно там, где рынок мобильный. Посетитель из Узбекистана или Юго-Восточной Азии открывает сайт с бюджетного андроида по мобильной сети - его замер и попадает в ваш 75-й перцентиль. Проверка на своем айфоне в офисном Wi-Fi не покажет ничего.

Что смотреть на мобильной версии:

• вес первого экрана. Видео в шапке на телефоне редко оправдано, постер с кнопкой работает не хуже
• всплывающие элементы: уведомление о cookie, подписка, чат. На узком экране они закрывают половину содержимого и портят CLS
• размер области нажатия. Мелкие кнопки рядом друг с другом дают промахи, а каждый из них оборачивается повторным нажатием и лишней работой для основного потока
• поведение при слабом сигнале. В браузере есть режим замедления сети - десяти минут хватит, чтобы увидеть свой сайт глазами посетителя в дороге

Смотреть при этом надо сначала мобильные данные. Индексация давно идет по мобильной версии: вкладка с телефонами говорит о вашем положении в выдаче больше, чем вкладка с компьютерами. Обратный порядок - привычка из времен, когда основным был компьютер.

Правка, которая улучшает мобильную версию, почти всегда окупается быстрее. Если выбирать между переделкой шапки на компьютере и выкидыванием видео из мобильного первого экрана, второе даст больше и обойдется дешевле.

Где предел влияния скорости на позиции

Ожидания здесь завышены почти у всех, кто приходит с задачей «ускорьте сайт, хотим в топ».

Google в справке формулирует осторожно: хорошие Core Web Vitals совпадают с тем, что поощряют основные системы ранжирования. Формулировка про решающий довод при прочих равных ходит по отрасли в пересказе, цитаты из документации за ней нет. Практика подтверждает мягкую версию: скорость работает как довесок при сопоставимом содержании, а не как рычаг роста.

Разрыв между «плохо» и «нормально» заметен. Между «нормально» и «идеально» разрыва почти нет. Бюджет на последний отрезок к баллу - от 80 к 100 - тратится с околонулевой отдачей в выдаче. Полгода на то, чтобы догнать сотню на всех страницах, дают 98 баллов и ноль сдвига в поиске, пока конкуренты выигрывают содержанием карточек.

Сайт с идеальными показателями и слабыми текстами не обгонит медленного конкурента с сильными. Скорость не выводит в топ - она перестает мешать.

Исключение из этого правила одно, и оно про масштаб. На сайте с десятками тысяч адресов медленный ответ сервера бьет уже не по оценке страницы, а по обходу: робот успевает забрать меньше страниц за визит, новые разделы попадают в индекс на недели позже. Для магазина с большим каталогом это уже не вопрос удобства, а вопрос того, увидит ли поиск товар до конца сезона.

Про Яндекс отдельно. Аналога Core Web Vitals у Яндекса нет. Пороги он не публикует и связь скорости с позициями не комментирует. Ориентиры тут свои: раздел скорости сайта в Вебмастере и отчет «Время загрузки страниц» в Метрике, где данные разбиты по квантилям. Зеленые Core Web Vitals в Google не переносятся на ранжирование в Яндексе автоматически, хотя техническая работа под них полезна в обеих системах - файл легче, сервер отвечает быстрее.

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

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

На защите отчета это редко проговаривают. Когда после работ по скорости растет трафик, у роста минимум два источника: поисковик стал чуть лояльнее, а посетители перестали уходить с полпути. Разделить их вклады без отдельного эксперимента нельзя, поэтому обещание «плюс 30% позиций за ускорение» подкрепить нечем.

Скорость на конструкторе: что можно и чего нельзя

Владелец сайта на конструкторе управляет не всем. Часть рычагов у него в руках, часть закрыта архитектурой платформы. Разговор о переезде имеет смысл только после того, как первая часть отработана.

Что в руках у владельца:

• картинки: сжать до загрузки, отдавать в современном формате, не грузить снимок шириной 4000 пикселей в блок на 600
• отложенная загрузка для всего, что ниже первого экрана
• число шрифтов и начертаний. Три семейства по четыре начертания - это дюжина файлов, которые тормозят отрисовку текста
• лишние виджеты: чат, который открывали трижды за квартал, счетчик неработающей рекламной системы, карта, которая нужна на странице контактов, а грузится на всех
• видео на первом экране. Меняется на постер с кнопкой запуска

Что закрыто:

• время ответа сервера. Хостинг платформы общий, и настроить его нельзя
• порядок загрузки служебных скриптов самой платформы
• часть настроек кеширования и объединение чужого кода

Найти виновника можно без разработчика. Откройте диагностику своей страницы и посмотрите на два пункта: что указано как элемент LCP и какие сторонние домены съедают время. Если в списке чужих доменов сидят четыре системы аналитики и два чата, разговор о переезде можно отложить - сначала уберите то, чем не пользуетесь. Виджеты копятся годами: подключили сервис на тест, тест закончился, скрипт остался.

Зеленая зона по LCP и CLS на конструкторе достижима почти всегда. INP держат служебные скрипты платформы и сторонние виджеты. Если после чистки картинок, шрифтов и виджетов метрики уперлись в желтую зону, дальше идет решение не про скорость, а про платформу целиком.

Переезжать ради баллов не стоит. Переезд оправдан, когда к скорости добавились другие ограничения: растет каталог, не хватает функциональности или нужной интеграции. Тогда скорость идет бонусом к переезду.

Как следить за метриками постоянно

Главный инструмент здесь - отчет об основных интернет-показателях в Google Search Console. Он устроен иначе, чем разовая проверка: страницы объединены в группы по схожести, и оценка выставляется группе целиком. Одна карточка товара попадет в группу со всеми остальными карточками, чинить придется шаблон.

Что с ним делать:

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

Показатели телефонов и компьютеров разведены в отчете по разным вкладкам. Зеленая картина на компьютерах при красной на телефонах - обычное дело.

Порог тревоги стоит поставить заранее, до того как группа адресов свалится в красную зону. Рабочий ориентир - около 80% от порога: LCP 2 секунды, INP 160 миллисекунд, CLS 0,08. Если метрика подобралась к этой отметке, запаса нет: следующий тяжелый баннер выбьет страницу из зачета.

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

Три цифры, которые стоит знать про свой сайт

LCP, INP и CLS по полевым данным за последние 28 дней, отдельно для телефонов. Если вы знаете эти три числа и понимаете, какое из них в желтой или красной зоне, вопрос «нужно ли ускорять сайт» закрыт, а разговор с подрядчиком становится предметным.

Правило одно: чинить до состояния «не мешает». Дальше бюджет уходит в содержание, ссылки и работу с запросами - там отдача заметно выше.

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

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

Частые вопросы

Влияет ли скорость на позиции напрямую

Влияет, но слабее, чем принято думать. Core Web Vitals входят в оценку страницы и срабатывают при сопоставимом содержании: из двух похожих страниц выше окажется быстрая. Обогнать конкурента с более сильным материалом за счет скорости не выйдет. Сначала содержание, потом скорость.

Почему в одном инструменте сто баллов, а в Search Console красная зона

Это два разных замера. Сто баллов - результат лабораторного теста на эмулированном устройстве. Search Console показывает полевые данные: замеры с браузеров тех, кто заходил на сайт за 28 дней, с их телефонами и мобильным интернетом. Вердикт по Core Web Vitals дают полевые данные, лабораторный тест нужен для поиска причины.

Нужно ли добиваться ста баллов

Нет. Сотня в PageSpeed - лабораторный показатель, в зачет по Core Web Vitals он не идет. Достаточно, чтобы три метрики укладывались в пороги на полевых данных. Погоня за сотней - самая частая трата бюджета в этой теме: последние двадцать баллов стоят дороже первых пятидесяти и не дают ничего в выдаче.

Почему полевых данных нет вовсе

Их не хватает для выводов. Данные собираются с браузеров посетителей, и если трафика на страницу мало, показывать нечего. У молодого сайта такое положение нормально. Пока полевых данных нет, ориентируйтесь на лабораторный замер и на данные по домену целиком, если они есть.

Через сколько после правок изменятся показатели

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

Работают ли Core Web Vitals в Яндексе

Аналога у Яндекса нет, свои пороги он не публикует. Скорость там оценивается по собственным данным: раздел скорости сайта в Вебмастере и отчет «Время загрузки страниц» в Метрике. Техническая работа под метрики Google помогает и в Яндексе, потому что физика одна, но переносить зеленую оценку из одного поиска в другой нельзя.

Можно ли ускорить сайт на конструкторе или нужен переезд

Да, если сначала пройтись по тому, чем управляет владелец сайта. На картинки, шрифты, лишние виджеты и видео на первом экране приходится основная часть провала. Закрыты время ответа сервера и порядок загрузки служебных скриптов платформы. Ради баллов переезжать не стоит, а вот при ограничениях по функциональности переезд оправдан.