SEO · скорость
Заказчик как-то прислал скриншот из Google Search Console с подписью «у меня тут всё красное, это плохо?» — и оказался прав насчёт «плохо», только не понимал, что именно эти красные отметки значат для позиций сайта в поиске. Разберу по порядку, что стоит за термином Core Web Vitals и насколько сильно это реально двигает позиции — без завышенных ожиданий в обе стороны.
Идея простая: вместо одной общей оценки «сайт быстрый / сайт медленный» Google разложил ощущение скорости на три отдельных момента, которые человек реально замечает, сидя перед экраном.
Это называется LCP, и происходит он обычно из-за самой тяжёлой картинки или заголовка на первом экране: пока браузер её не подгрузит, страница выглядит пустой. Комфортным считается результат до 2,5 секунды — дальше человек уже начинает замечать паузу.
За этот показатель почти всегда отвечает одна и та же пара виновников: несжатая картинка на первом экране и куски кода, которые браузер обязан обработать раньше, чем нарисовать содержимое.
На одном проекте после сжатия изображений, переноса второстепенных скриптов подальше от начала загрузки и удаления лишнего кода из стилей итоговая оценка Google PageSpeed поднялась с 30–40 до 90+ баллов — не благодаря одной волшебной настройке, а именно за счёт связки из нескольких мелких правок сразу.
Метрика INP — про то, успевает ли страница отреагировать быстро (до 200 миллисекунд) на нажатие, или интерфейс на долю секунды «подвисает», потому что браузер в этот момент занят чем-то другим — например, разбирает тяжёлый скрипт. Обычно за это отвечает тяжёлый JavaScript, который занимает основной поток браузера ровно в тот момент, когда человек пытается на что-то нажать — классическая история для страниц с большим количеством сторонних виджетов, чатов и счётчиков одновременно.
Самый раздражающий на практике: уже начинаешь читать текст или тянешься к кнопке, а всё вдруг сдвигается вниз, потому что где-то выше долетела картинка без заранее заданного размера. Это и измеряет CLS — накопленный сдвиг макета. Хорошим считается значение ниже 0,1, и чем ближе к нулю, тем меньше страница «дёргается».
Обычно виноваты картинки и рекламные блоки, у которых заранее не указана высота — браузер узнаёт их настоящий размер только после подгрузки и «расталкивает» уже нарисованные элементы вокруг.
Проставить width и height у изображения заранее — едва ли не самое дешёвое исправление с одним из самых заметных результатов: макет перестаёт «прыгать», даже если сама картинка ещё не успела загрузиться.
Один сдвинутый элемент выше по странице — и вся конструкция ниже него уже «поехала», как накренившаяся башня.
Здесь важно не путать две вещи. Google официально называет Core Web Vitals фактором ранжирования с 2021 года, но некрупным — он скорее работает как небольшая гиря на весах между примерно равными по содержанию сайтами, а не как отдельный мощный рычаг, способный вытащить в топ страницу со слабым текстом. Сильнее на позиции почти всегда влияет то, насколько содержание страницы отвечает на сам запрос.
Но есть и второй эффект, менее очевидный — поведенческий, не прямой. Если страница дёргается или тормозит на клике, часть посетителей уходит раньше, чем успевает получить нужную информацию, либо промахивается мимо кнопки из-за внезапно съехавшей вёрстки. А поведение аудитории на сайте поисковики так или иначе учитывают — и на практике этот побочный эффект от плохой скорости порой ощутимее, чем прямой вес самой метрики.
В самой Google Search Console есть отдельный отчёт по Core Web Vitals — там цифры собраны по реальным визитам живых посетителей за последние недели (полевые данные). А PageSpeed Insights и вкладка Lighthouse в инструментах разработчика Chrome показывают результат одного конкретного замера прямо сейчас, на одном устройстве (лабораторные данные). Из-за этого бывает обидное расхождение: разовый тест показывает зелёный результат, а отчёт по реальным пользователям в Search Console — жёлтый, просто потому что часть аудитории заходит с не самого нового телефона и не самого быстрого мобильного интернета.
Разберу отчёт Core Web Vitals по вашему сайту и скажу, что конкретно чинить в первую очередь — без общих формулировок вроде «нужно ускорить сайт».
Стоит ли добиваться 100 баллов в PageSpeed Insights?
Смысла немного. Разница между 90 и 100 почти не заметна ни человеку, ни поисковику — это уже борьба за доли процента ради красивой цифры на скриншоте. Более разумная цель — стабильно комфортные значения по всем трём метрикам, а не идеальный балл.
Может ли идеальная скорость сама по себе вытащить сайт в топ?
Нет. Это скорее «гиря-довесок», а не замена содержательному тексту и остальной части SEO. Быстрая страница с бесполезным для запроса содержанием в топ всё равно не попадёт.
С чего начинать, если все три метрики в красной зоне?
С первой — обычно именно она сильнее всего формирует общее впечатление от загрузки, а правки для неё (сжатие картинок, вынос лишних скриптов) заодно чаще всего попутно улучшают и две остальные.
Веб-разработчик, Краснодар. Делаю сайты под ключ на Vue/Nuxt и React/Next, вёрстку по макетам из Figma и PSD, сайты на WordPress и SEO-продвижение — сам, без субподрядчиков.
Работаю с 2GIS, Яндекс.Бизнесом, самозанятость оформлена официально с 2024 года. С клиентами по всему Краснодарскому краю и удалённо по России.