Откуда берутся данные о скорости?

Инструмент использует Google PageSpeed Insights — тот же движок Lighthouse, что и официальный сервис Google. Показываются лабораторные метрики и, если их достаточно, реальные данные пользователей (CrUX).

Что такое Core Web Vitals?

Это три ключевые метрики Google: LCP (скорость загрузки основного контента), CLS (стабильность вёрстки) и INP (отзывчивость на действия). Они влияют на ранжирование.

Почему мобильная оценка ниже десктопной?

Мобильный тест эмулирует медленный процессор и сеть 4G. Это строже, но ближе к реальным условиям большинства пользователей.

PageSpeed показывает 95, а сайт ощущается медленным. Почему?

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

Как быстро эффект от оптимизации виден в Search Console?

Лабораторные метрики меняются сразу после выкладки. Полевые данные CrUX усредняются за 28 дней, поэтому отчёт Core Web Vitals догоняет реальность примерно месяц. Делать выводы раньше рано.

Проверка скорости сайта онлайн — Core Web Vitals и PageSpeed

Что показывает проверка

Запрос уходит в API Google PageSpeed Insights. Страницу открывает Lighthouse на серверах Google, замеряет метрики и возвращает оценку от 0 до 100. Тест идёт в двух режимах сразу, мобильном и десктопном, поэтому ответа приходится ждать 10–30 секунд. Оценка 90 и выше считается зелёной зоной, 50–89 требует работы, ниже 50 означает серьёзные проблемы.

Core Web Vitals по пунктам

LCP: время до основного контента

Largest Contentful Paint фиксирует момент, когда отрисовался самый крупный элемент первого экрана. Обычно это баннер, фотография товара или крупный заголовок. Пороги Google: до 2.5 секунды хорошо, от 2.5 до 4 нужно улучшать, свыше 4 плохо. Тормозят LCP чаще всего три вещи. Медленный ответ сервера. Тяжёлое изображение без сжатия. Шрифт, блокирующий отрисовку текста.

CLS: стабильность вёрстки

Cumulative Layout Shift считает, насколько сильно элементы прыгают во время загрузки. Норма до 0.1. Классический сценарий знаком каждому: вы тянетесь к кнопке, сверху догружается баннер, страница уезжает вниз и палец попадает не туда. Метрика безразмерная, она перемножает долю сдвинувшейся площади экрана на расстояние сдвига.

INP: отзывчивость интерфейса

Interaction to Next Paint заменил метрику FID в марте 2024 года. Он измеряет задержку между действием пользователя и видимым откликом, причём берёт не первое взаимодействие, а почти худшее за сессию. Хороший результат до 200 мс, приемлемый до 500 мс. Виновник почти всегда один: длинные задачи JavaScript занимают главный поток и не дают браузеру перерисовать кадр.

TBT и FCP

Эти две метрики идут в отчёте как вспомогательные. FCP отмечает первую отрисовку хоть чего-нибудь, норма до 1.8 секунды. TBT суммирует время задач длиннее 50 мс за период загрузки, до 200 мс приемлемо. Ценность TBT в том, что он измеряется в лаборатории, тогда как INP собирается только из реальных сессий. Высокий TBT почти гарантирует провал по INP.

Лабораторные данные и полевые

Lighthouse запускает страницу один раз на эмулируемом устройстве при фиксированных параметрах сети. Замер воспроизводимый и удобный для отладки, но искусственный. Полевые данные берутся из отчёта CrUX, куда Chrome собирает анонимную телеметрию реальных посетителей за 28 дней. В ранжировании учитывается именно CrUX.

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

Почему мобильная оценка ниже

Мобильный прогон эмулирует бюджетный смартфон с процессором примерно вчетверо медленнее десктопного и канал 4G с задержкой около 150 мс. Десктопный работает на быстром CPU и широком канале. Разрыв в 25–40 баллов между вкладками это норма, а не поломка инструмента. Оптимизировать надо мобильную версию: на неё приходится основная доля визитов в большинстве тематик, и именно её Google использует при индексации.

Что оценка не измеряет

Балл Lighthouse собирается из пяти лабораторных метрик с разными весами, и львиную долю дают TBT с LCP. Ни удобство интерфейса, ни качество вёрстки на планшете в него не входят. Сайт с сотней баллов может грузиться мгновенно и всё равно отталкивать посетителя. Скорость это гигиена, а не преимущество. Она снимает штраф за медлительность, но сама по себе трафика не приносит.

С чего начать ускорение

Сожмите изображения и отдавайте их в WebP. Картинка на 800 КБ после конвертации весит 60–90 КБ без видимой потери качества.
Проставьте width и height всем картинкам. Одна строка правки убирает большую часть CLS.
Ставьте loading="lazy" на всё ниже первого экрана, а на LCP-элемент наоборот fetchpriority="high".
Для шрифтов включите font-display: swap, а через preload подгружайте только те начертания, что видны сразу.
Уберите сторонние скрипты, которыми никто не пользуется. Виджет чата или счётчик легко съедают секунду.
Включите кэш браузера и сжатие на сервере. Заголовок Cache-Control на статику решает половину проблем при повторных визитах.
Отложите неиспользуемый CSS. Критические стили инлайном, остальное асинхронно.

После правок повторите проверку. Лабораторная оценка отреагирует сразу, а полевые метрики CrUX усредняются за 28 дней, поэтому в Search Console эффект проявится примерно через месяц.