Короткий ответ
Скорость сайта влияет на позиции в Google, но косвенно и слабее, чем принято думать. Google подтверждает, что Core Web Vitals входят в сигналы ранжирования, но как фактор небольшого веса, который проявляется в основном при прочих равных. Быстрый сайт с посредственным контентом не обгонит медленный сайт с исчерпывающим ответом на запрос.
Практический вывод простой: скорость не выводит в топ, но откровенно медленный сайт мешает всему остальному: люди возвращаются в выдачу, конверсия падает, а на больших сайтах ещё и снижается частота сканирования Googlebot. Поэтому скорость стоит доводить до «нормально» и на этом останавливаться.
Что именно измеряет Google
С 2021 года набор метрик называется Core Web Vitals, и с 2024 года в него входит INP вместо устаревшего FID.
| Метрика | Что показывает | Порог «хорошо» |
|---|---|---|
| LCP (Largest Contentful Paint) | Когда отрисовался основной элемент экрана, обычно баннер или заголовок | до 2,5 с |
| INP (Interaction to Next Paint) | Насколько быстро страница откликается на клики и тапы | до 200 мс |
| CLS (Cumulative Layout Shift) | Насколько сильно вёрстка «прыгает» при загрузке | до 0,1 |
Два момента, которые чаще всего понимают неправильно.
Первое: считается 75-й перцентиль, а не среднее. Метрика зачтена, если в порог укладываются три четверти реальных визитов за 28-дневное окно. Один медленный визит картину не портит, но стабильно медленная четверть аудитории — портит.
Второе: в ранжировании используются полевые данные, а не лабораторные. Полевые — это CrUX, агрегированные измерения у настоящих пользователей Chrome. Лабораторные — это Lighthouse, симуляция на эмулируемом устройстве. Балл PageSpeed Insights, за которым все гонятся, относится к лабораторным.
Поэтому начинать стоит с отчёта «Основные интернет-показатели» в Search Console: там лежат те же полевые данные, сгруппированные по типам страниц.
Почему скорость всё-таки заметна в выдаче
Прямое влияние скорости на ранжирование небольшое, и Google это не скрывает. Но у неё есть три косвенных канала, и они сильнее.
- Поведение пользователей. Если страница не отрисовалась за пару секунд на мобильном, часть людей уходит обратно в выдачу и открывает конкурента. Google не обязан считать это «поведенческим фактором», чтобы результат был тем же: конкурент получает визит, вы — нет.
- Конверсия. Тормозящая форма или карточка товара убивает заявки независимо от позиций. Это отдельная задача: я разбираю её в контексте роста конверсии сайта, но начинается она часто именно с технической части. Скорость остаётся лишь одним из блоков в общем списке того, что такое техническая оптимизация сайта, и далеко не первый по приоритету.
- Сканирование. Google заявляет, что при медленных ответах сервера Googlebot снижает частоту обхода. Для сайта услуг на 150 страниц это неважно. Для магазина с 40 000 URL медленный сервер означает, что часть страниц просто реже переобходится, а иногда это и есть ответ на вопрос, почему страницы не индексируются в Google.
Если вам обещают рост позиций «за счёт оптимизации скорости» — это красный флаг. Скорость чинят, потому что она мешает пользователям и деньгам, а не потому, что Google поднимет сайт на пять позиций.
Что я вижу на своих проектах
Основной мой доход — собственные сайты в конкурентных финансовых нишах, и там я проверял это на себе: доведение LCP из красной зоны в зелёную ни разу не давало у меня скачка позиций само по себе. Что оно давало стабильно — меньше отказов на мобильных и более предсказуемое поведение аналитики.
Обратное тоже верно и куда болезненнее. Когда сайт уходит в красную зону Core Web Vitals, обычно после установки нового плагина, чата поддержки или очередного пикселя, просадка видна быстро и по трафику, и по заявкам. Ломать скорость получается гораздо эффективнее, чем её улучшать.
Честные границы применимости: у меня нет данных по действительно крупным проектам на сотни тысяч URL, где влияние на краулинговый бюджет становится главным аргументом. Всё написанное выше относится к сайтам услуг, небольшим магазинам и контентным проектам, то есть к типичному эстонскому малому бизнесу.
Ещё одно наблюдение, специфичное для местного рынка: на многоязычных эстонских сайтах я чаще встречаю не проблему скорости, а проблему структуры: неправильные hreflang, дубли между языковыми версиями, размытый интент, из-за которого Google сам выбирает, какую версию показывать. На фоне этого спор о десятых долях секунды выглядит не главным. Про выбор языков я писал отдельно: на каком языке продвигать сайт в Эстонии.
Что чинить в первую очередь
Порядок именно такой: от самого дешёвого к самому дорогому.
- Изображения. Современный формат (WebP или AVIF), реальные размеры вместо гигантских исходников,
widthиheightв разметке против сдвигов вёрстки, ленивая загрузка всего, что ниже первого экрана. На сайтах, где никто этим не занимался, это чаще всего и есть основная проблема LCP. - Сторонние скрипты. Чаты, виджеты отзывов, три системы аналитики, тепловые карты, пиксели рекламных кабинетов. Откройте вкладку Network и посмотрите, что грузится помимо вашего сайта. Обычно половину можно убрать без потерь, а остальное отложить.
- Ответ сервера. Медленный TTFB не лечится оптимизацией фронтенда. Здесь помогает кеширование, нормальный тариф хостинга и CDN. Самого переезда бояться не нужно: смена хостинга не ухудшает SEO, если миграция сделана корректно.
- Шрифты.
font-display: swapи предзагрузка основного начертания снимают долгую пустую страницу и часть сдвигов вёрстки. - Только потом — код. Разбиение бандла, удаление неиспользуемого CSS, оптимизация гидратации. Это самая дорогая часть, и на типовом сайте она даёт меньше всего относительно затраченного времени. Если дело дошло сюда, обычно речь уже о переработке самого сайта, а не о точечных правках.
Как понять, что проблема вообще есть
Пошагово, за пятнадцать минут:
- Откройте в Search Console отчёт «Основные интернет-показатели», отдельно мобильную вкладку: она почти всегда хуже десктопной.
- Посмотрите, есть ли группы URL в красной или жёлтой зоне и какие типы страниц туда попали. Часто это одна конкретная категория страниц, а не весь сайт.
- Возьмите один типовой URL из проблемной группы и прогоните в PageSpeed Insights. Смотрите не на балл, а на верхний блок с полевыми данными и на список диагностик.
- Если полевых данных нет, значит, трафика мало для выборки CrUX. Тогда скорость не ваша текущая проблема, займитесь содержанием.
- Повторите замер не раньше чем через 28 дней после правок: полевые данные обновляются скользящим окном и мгновенно не реагируют.
Пример того, что даёт результат на практике, есть в разборе SEO мебельного магазина в Эстонии: там рост дала работа со структурой и категориями, а техническая часть была условием, а не причиной.
