Открываю PageSpeed Insights для очередного клиента - и снова красное. LCP четыре секунды, картинки по мегабайту, CLS скачет. Человек искренне удивляется: «А это разве на позиции влияет?»
Влияет. Но не так, как думает большинство. HTTP Archive за 2025 год: всего 48% мобильных сайтов проходят все три Core Web Vitals. Больше половины интернета в красной или желтой зоне. За 10 лет я разобрал сотни медленных проектов. Расскажу, на чем теряют позиции 90% сайтов.
Скорость сама по себе не фактор ранжирования
Звучит странно? Но это так. Core Web Vitals - не прямой сигнал ранжирования в Google. Скорость работает как катализатор. Медленная загрузка портит пользовательский опыт, а уже поведение посетителей бьет по позициям.
Механизм такой: человек кликает по ссылке в выдаче, ждет три-четыре секунды - ничего не грузится. Закрывает вкладку, возвращается в поиск. Google фиксирует это как badClick через систему NavBoost. Накопил достаточно badClicks за 13 месяцев - просел в выдаче.
Еще один момент, который часто упускают. Медленные страницы расходуют crawl budget - бюджет сканирования, который Google выделяет каждому сайту. Тяжелые страницы (2 МБ и больше) скачиваются роботом втрое реже легких. А если Googlebot скачал страницу, но не смог ее прорендерить из-за тяжелого JavaScript - бюджет потрачен, индексации нет. «Zombie render» - так я это называю.
Три метрики, на которые смотрит Google
Google оценивает каждую страницу по трем порогам. Вот что они значат:
LCP (Largest Contentful Paint) - скорость появления основного контента на экране. Норма - до 2,5 секунд. По данным HTTP Archive, 62% сайтов на мобильных укладываются. Звучит терпимо, но если считать все три метрики вместе - только 48%.
INP (Interaction to Next Paint) - отзывчивость интерфейса при кликах и касаниях. Норма - до 200 мс. С марта 2024 года заменил устаревший FID. Если ваш инструмент до сих пор показывает FID - он устарел. INP отслеживает каждое действие на странице, а не только первый клик.
CLS (Cumulative Layout Shift) - визуальная стабильность. Норма - ниже 0,1. Если страница «прыгает» при загрузке - баннер подгрузился сверху и все сместилось - это CLS. В 9 случаях из 10 причина банальна: картинкам не задали width и height.
Lab Data и Field Data - почему PageSpeed врет
Вот где начинается путаница. Число в шапке PageSpeed Insights - это Lab Data, синтетический тест. Мощный виртуальный компьютер, стабильная сеть, идеальные условия.
А Google ранжирует по Field Data - статистике из браузеров реальных посетителей за 28 дней (Chrome User Experience Report). Порог считается по 75-му перцентилю: три четверти ваших посетителей должны получить «хороший» результат.
Показательный случай: маркетолог одного интернет-магазина потратил три месяца, выбивая 95 баллов в Lighthouse. Менял хостинг, нанимал фрилансеров. А Field Data все это время были зелеными - реальные покупатели проблем не испытывали. Ноль роста позиций. Боролись не с тем.
Правило простое: откройте PageSpeed Insights, найдите блок «Узнайте, как работает ваша страница в реальных условиях». Вот эти цифры определяют судьбу страницы в выдаче. Не баллы наверху.
Шесть действий, которые закрывают 80% проблем
Я собирал этот список на реальных проектах. Верхние пункты дают максимальный эффект:
- Конвертировать изображения в WebP. Сжатие на 25-35% лучше JPEG при том же качестве. Для адаптивной загрузки - srcset. Самый частый виновник плохого LCP - hero-картинка в 2-3 МБ в PNG. Дизайнер выгрузил, разработчик залил «как есть». Банально, но я вижу это на каждом втором проекте
- Включить lazy loading для медиа ниже первого экрана. Атрибут `loading="lazy"` для img и iframe. Без JavaScript. Но не ставьте его на LCP-изображение - иначе оно загрузится последним
- Встроить критический CSS в HTML. Стили для первого экрана - прямо в `<style>` внутри head. Остальное - асинхронно. Контент появляется раньше, экран не моргает
- Настроить кэширование. Шрифты, картинки, стили - кэш на год. HTML - короткий кэш с ревалидацией
- Раздать статику через CDN. Для российской географии это экономит от 200 до 800 мс. За Уралом разница особенно заметна
- Ускорить ответ сервера (TTFB). Если первый байт приходит дольше 800 мс - проблема на бэкенде. На одном проекте я убрал лишний JOIN из SQL-запроса - TTFB упал с 900 до 350 мс
Что показал реальный проект
В конце 2025 года пришел владелец интернет-магазина товаров для дома. PageSpeed на мобильных - 28 баллов. Field Data горели красным по LCP и CLS.
Сделали: WebP + srcset, lazy loading, критический CSS inline, Brotli-сжатие, CDN, задали размеры для img и video, сторонние скрипты - на defer. Результат:
- LCP - с 4,8 до 2,1 секунды
- INP - с 310 до 140 мс
- CLS - с 0,32 до 0,04
- PageSpeed - с 28 до 82 баллов
Field Data стабилизировались через 28 дней. Через два месяца органический трафик из Google вырос на 22%. Только ли из-за скорости? Нет. Но скорость убрала барьер, который мешал контенту работать.
Про Яндекс - отдельная история
Яндекс оценивает скорость по собственным метрикам через Яндекс.Браузер - не Chrome. Сайт может быть зеленым по Google и желтым по Яндексу. Проверяйте оба инструмента.
По моему опыту, для SEO-продвижения в Яндексе скорость менее заметна, чем в Google - Яндекс сильнее опирается на поведенческие факторы. Но красный индекс скорости - повод разобраться.
Не гонитесь за сотней баллов
Скорость загрузки - не самоцель. Сайт с идеальными CWV и пустым контентом в топ не выйдет. Но медленный сайт с хорошим контентом будет проигрывать: посетители уходят, NavBoost копит негатив, crawl budget утекает впустую.
Скорость - как фундамент. Без него стены не стоят. Но жить в одном фундаменте никто не будет.
Оперативные разборы обновлений алгоритмов и новых метрик - в моем Telegram-канале.
Полный гайд с чеклистом из 18 действий и разбором каждой метрики - в статье на seotop.biz. Если хотите, чтобы я посмотрел метрики вашего сайта - пишите в Telegram @fedotovbiz, разберем вашу ситуацию.