Скорость загрузки сайта и её влияние на позиции в поиске
Скорость сайта — это не отдельный ранжирующий фактор, а часть page experience: при прочих равных Google предпочтёт более быстрый сайт, но контент и релевантность весят кратно больше. Разбираем, что подтверждено документацией и как ускорить сайт без переписывания с нуля.
Что такое Core Web Vitals на самом деле
Google официально использует три метрики page experience: LCP (Largest Contentful Paint) — время отрисовки самого крупного видимого элемента, целевой порог до 2,5 секунды; INP (Interaction to Next Paint) — задержка отклика на действие пользователя, заменил устаревший FID в марте 2024 года, порог до 200 миллисекунд; CLS (Cumulative Layout Shift) — сумма неожиданных сдвигов вёрстки, порог до 0,1.
Данные берутся из двух источников: полевые данные CrUX (Chrome User Experience Report) — реальные посещения пользователей Chrome за последние 28 дней, и лабораторные данные Lighthouse — симуляция в контролируемых условиях. Отчёт в Google Search Console «Основные интернет-показатели» строится на CrUX, поэтому может расходиться с результатом PageSpeed Insights, если у сайта мало трафика для накопления полевых данных.
Для .uz-сайтов с невысоким трафиком CrUX часто просто не набирает данные по конкретным URL, тогда GSC группирует похожие страницы по шаблону. Это нормально и не значит, что метрика не считается.
Что реально влияет на позиции, а что миф
Подтверждено: page experience, куда входят Core Web Vitals, — один из сотен сигналов ранжирования, официально описанных Google как тай-брейкер между страницами с похожей релевантностью. Это не означает, что быстрый сайт с плохим контентом обгонит медленный сайт с отличным контентом — Google прямо говорит, что релевантность важнее.
Миф: «страница с плохим CLS вообще не попадёт в топ». На практике сайты с проваленными Core Web Vitals стабильно ранжируются в топ-10 по конкурентным запросам, если контент сильнее конкурентов. Проверить это легко — забить любой конкурентный запрос в PageSpeed Insights для топовых результатов и увидеть, что далеко не все проходят «зелёную зону».
Что реально страдает от медленной загрузки — это конверсия и поведенческие метрики: отказы, глубина просмотра, время на сайте. А они уже косвенно влияют на ранжирование через сигналы вовлечённости, которые Google не раскрывает подробно, но которые коррелируют с позициями в долгосрочной перспективе.
Диагностика: с чего начать
Первый шаг — открыть отчёт «Основные интернет-показатели» в Google Search Console и посмотреть, сколько URL в статусах «Требует улучшения» и «Плохо». Отчёт группирует по шаблонам страниц, поэтому проблема с карточкой товара сразу видна как системная, а не единичная.
Второй шаг — прогнать 3-5 ключевых URL (главная, категория, карточка товара, статья блога) через PageSpeed Insights отдельно для мобильной и десктопной версии. Мобильная версия почти всегда хуже — это ожидаемо и связано с mobile-first индексацией: Google в первую очередь оценивает именно мобильную скорость.
Третий шаг — вкладка Lighthouse в DevTools Chrome с throttling «Slow 4G» показывает диагностику по каждой метрике с указанием конкретных элементов, которые тормозят рендер — это практичнее общих рекомендаций из PageSpeed Insights.
Практические способы ускорения
Изображения — самая частая причина плохого LCP на .uz-сайтах: баннеры и фото товаров без сжатия, без формата WebP или AVIF, без атрибутов width/height. Конвертация в WebP снижает вес на 25-35% без потери видимого качества, а явные размеры предотвращают сдвиг вёрстки при догрузке.
Для INP главная причина — тяжёлый JavaScript, блокирующий основной поток: виджеты чатов, счётчики аналитики, карусели с лишними библиотеками. Отложенная загрузка (defer/async) и вынос некритичных скриптов после первой отрисовки снимает большую часть задержки.
Хостинг имеет значение больше, чем принято думать: shared-хостинг с серверами вне региона добавляет 200-400 мс к Time to First Byte только на сетевую задержку. Для аудитории в Узбекистане CDN с точкой присутствия в регионе или хотя бы в Европе/России ощутимо сокращает LCP.
Шрифты — недооценённый фактор CLS: кастомные шрифты без font-display: swap вызывают невидимый текст (FOIT) или сдвиг после подгрузки (FOUT с реflow). Предзагрузка (preload) критичных шрифтов через <link rel="preload"> решает проблему в большинстве случаев.
Как измерить эффект после оптимизации
Лабораторные метрики (PageSpeed Insights, Lighthouse) меняются сразу после деплоя. Полевые метрики (CrUX, отчёт в Search Console) обновляются с задержкой 28 дней — это скользящее окно, поэтому эффект оптимизации виден постепенно, а не мгновенно.
Не стоит гнаться за 100 баллами в Lighthouse — это лабораторная синтетика, слабо коррелирующая с реальным полевым опытом. Реалистичная цель — перевести URL из статуса «Требует улучшения» в «Хорошо» в отчёте Search Console, это прямая метрика, которую видит Google.