Проверить скорость сайта умеет любой: открыл PageSpeed Insights, вставил адрес, получил цифру. Сложное начинается дальше — понять, что эта цифра значит и стоит ли из-за неё поднимать разработчика. Core Web Vitals как раз про это: три показателя, которые Google снимает с живых посетителей, и опубликованные пороги, по которым видно, всё в порядке или нет.
За двадцать лет я насмотрелся на обе крайности. Одни владельцы не открывали замер ни разу и удивляются, когда узнают, сколько на самом деле грузится их каталог на телефоне. Другие приносят скриншот с красной оценкой и требуют сотню баллов — хотя оценку эту Lighthouse нарисовал на эмуляции дешёвого смартфона в медленной сети, а у реальных посетителей сайт открывается сносно.
Ниже — как устроен замер, что означает каждая из трёх метрик, где проходят официальные пороги и в каком порядке разбирать проблемы. Отдельно про деньги: что чинится настройками хостинга и CMS, а что придётся заказывать разработчику.
Чем проверить скорость сайта
Ниже четыре инструмента для разных задач. Сравнивайте не их общие баллы, а одинаковые метрики, страницы, устройства и условия измерения.
PageSpeed Insights — бесплатный инструмент без регистрации: показывает полевые данные Chrome и лабораторный прогон. Мобильную и настольную версии проверяйте отдельно: условия загрузки и состав аудитории различаются.
Lighthouse во вкладке разработчика Chrome — тот же движок, что и в нижней половине PageSpeed Insights, но прогон идёт с вашей машины и по вашему каналу. Выручает, когда нужно проверить страницу, закрытую от посторонних: корзину, личный кабинет, тестовый сервер.
Search Console, отчёт Core Web Vitals — обзор групп похожих страниц, для которых Google располагает полевыми данными. Он помогает выбрать проблемные шаблоны, но не заменяет проверку конкретных адресов и не обязательно охватывает весь сайт.
Яндекс Метрика, отчёт «Время загрузки страниц» в разделе «Мониторинг». Помогает сравнивать загрузку у посетителей, от которых счётчик получил данные. Это другая выборка и методика: значения не следует напрямую приравнивать к Core Web Vitals.
Замерять только главную бессмысленно: она обычно самая вылизанная. Возьмите по одному адресу на каждый шаблон — главная, категория, карточка товара, страница услуги, статья блога, контакты. Шесть-восемь замеров, и станет видно, где именно провал. Часто он в одном шаблоне из шести, а не «на сайте».
Полевые данные и лабораторные: почему это два разных отчёта
Верх страницы PageSpeed Insights занимает блок с реальными данными. Google собирает их с посетителей Chrome, которые разрешили отправку статистики; окно — последние 28 дней, оценка берётся по 75-му перцентилю. Расшифрую: если у трёх четвертей визитов страница уложилась в порог, метрика зелёная. Не среднее, а именно «у большинства» — один медленный посетитель картину не портит, а четверть медленных портит.
Ниже идёт лабораторный прогон Lighthouse: одна загрузка, сделанная прямо сейчас, на эмуляции мобильного устройства с искусственно замедленным процессором и сетью. Ни одного вашего посетителя в этих цифрах нет.
Отсюда два практических вывода.
- Полевые данные описывают доступную выборку реальных посещений. Лабораторные позволяют воспроизвести условия и найти причины задержек; каждый тип замера отвечает на свой вопрос.
- Полевые данные в PageSpeed Insights обновляются ежедневно, но охватывают скользящие 28 дней. После внедрения в окне некоторое время остаются и старые, и новые посещения.
Если данных конкретного URL недостаточно, PageSpeed Insights может показать агрегат по origin — сочетанию протокола, хоста и порта. Это не среднее арифметическое баллов страниц. Если и этой выборки недостаточно, полевого отчёта не будет: остаются лабораторные проверки, без вывода о прохождении полевых порогов.
Почему оценка прыгает от запуска к запуску
Прогнали дважды подряд, а баллы разошлись на десяток. Ничего не сломалось, так и должно быть. Лабораторный замер зависит от вещей, которые меняются между прогонами:
- загрузка машины, на которой выполняется тест;
- сторонние скрипты — рекламная сеть, чат, коллтрекинг отвечают то мгновенно, то через пару секунд;
- состояние кэша на вашем сервере и на CDN;
- случайные показы: баннер, всплывающее окно, вариант A/B-теста;
- сама версия Lighthouse — она обновляется, и пересчёт после обновления выглядит как «сайт замедлился».
Единичный прогон поэтому ничего не доказывает. Гоняйте три-пять раз и берите середину, а окончательный вывод делайте по полевым данным.
Три метрики Core Web Vitals простыми словами
Core Web Vitals — набор из трёх показателей, которые Google считает базовыми для удобства страницы. Каждый описывает своё ощущение: «когда я наконец увижу», «когда я смогу нажать» и «перестанет ли всё это прыгать».
LCP — Largest Contentful Paint, когда появилось главное
Браузер смотрит, какой видимый элемент на первом экране самый крупный — обычно это фотография товара, баннер или большой заголовок, — и засекает момент, когда он отрисовался. Это и есть LCP.
Метрика отвечает на вопрос посетителя «сайт вообще грузится?». Пока главный элемент не появился, человек смотрит на белый экран или на скелет вёрстки и решает, ждать дальше или вернуться в выдачу.
Что чаще всего тянет LCP вниз: тяжёлая несжатая картинка на первом экране, медленный ответ сервера, шрифт или CSS, которые блокируют отрисовку, и — отдельная классика — ленивая загрузка, навешенная на главное изображение. Выглядит как забота о скорости, работает наоборот: браузер откладывает ровно ту картинку, по которой его и оценивают.
INP — Interaction to Next Paint, насколько живая страница
INP измеряет задержку между нажатием и видимым ответом. Нажали «в корзину» — через сколько на экране что-то изменилось? Раскрыли меню — оно открылось сразу или подумало?
В марте 2024 года INP заменил FID. FID учитывал задержку до начала обработки первого взаимодействия; INP оценивает отклик при взаимодействиях на протяжении посещения, включая обработку события и показ следующего кадра. Поэтому хорошее значение FID не означало хороший INP.
При плохом INP проверяйте занятость главного потока: обработчики JavaScript, сторонние скрипты, расчёт стилей и отрисовку. Найдите конкретное медленное взаимодействие, прежде чем удалять скрипты или менять фильтр каталога.
CLS — Cumulative Layout Shift, прыгает ли вёрстка
Знакомая история: вы целитесь в кнопку, сверху догружается баннер и содержимое сдвигается. CLS учитывает неожиданные сдвиги: выбирается наибольшая сумма в серии длительностью до пяти секунд, где паузы между сдвигами меньше секунды. Это не сумма всех сдвигов за весь визит.
Причины скучные и почти всегда одни и те же. У картинок не заданы ширина и высота, поэтому браузер сначала рисует пустоту нулевой высоты, а потом раздвигает вёрстку. Шрифт подгружается и меняет высоту строк. Блок «купили вместе с этим» вставляется в готовую страницу без зарезервированного места. Сверху въезжает плашка про cookie.
Пороги, которые опубликовал Google
| Метрика | Хорошо | Требует улучшения | Плохо |
|---|---|---|---|
| LCP | до 2,5 с | 2,5 – 4,0 с | больше 4,0 с |
| INP | до 200 мс | 200 – 500 мс | больше 500 мс |
| CLS | до 0,1 | 0,1 – 0,25 | больше 0,25 |
Два уточнения к таблице, без них она читается неправильно. Первое: оценка идёт по 75-му перцентилю реальных визитов, а не по вашему замеру с рабочего ноутбука на офисном интернете. Второе: мобильные и десктоп считаются раздельно, и зелёный десктоп при красном мобильном — самая обычная картина.
Почему сто баллов — плохая цель
Общая оценка PageSpeed Insights — величина производная. Её собирают из нескольких лабораторных метрик с разными весами, и самый тяжёлый вклад даёт время, на которое главный поток браузера оказался заблокирован. Как индикатор «сегодня хуже, чем вчера» оценка удобна. Как цель — почти бесполезна.
У каждой полевой метрики три категории: «хорошо», «требует улучшения», «плохо». Например, LCP 2,4 секунды относится к первой, а 2,6 — ко второй. Общий лабораторный балл рассчитывается отдельно: его рост сам по себе не доказывает улучшение полевого опыта или поисковых позиций.
Сто баллов в лаборатории при красных полевых данных — это красивый скриншот. Зелёные пороги при семидесяти баллах — это работающий сайт.
Из разговора, который повторяется у меня примерно раз в месяц
Для приёмки фиксируйте URL, устройство, метрику и условия. Лабораторную цель «поднять балл до 90» можно проверить при согласованной версии Lighthouse и настройках. Дополнительно проверяйте нужную полевую метрику по 75-му перцентилю: это другой замер, результат которого зависит от накопленной выборки.
Что чинить в первую очередь
Порядок почти всегда один и тот же, и он редко совпадает со списком рекомендаций внизу отчёта. Тот список отсортирован по расчётной экономии миллисекунд, а не по соотношению «эффект к трудозатратам».
Ответ сервера
Проверьте время до первого байта. Если ответ сервера задерживает получение HTML, это может ухудшать LCP. Однако хороший ответ сервера не исключает проблем скриптов или вёрстки: приоритет выбирайте по измерениям конкретной страницы.
Проверьте ресурсы хостинга, кэширование и медленные запросы к базе. Версию PHP имеет смысл обсуждать для сайта, который работает на PHP; перед обновлением нужна проверка совместимости. Часть настроек доступна в панели, для других потребуется разработчик — объём выясняется после диагностики.
Первый экран
Найдите в отчёте, какой элемент браузер считает главным, и займитесь конкретно им. Дальше по шагам: сжать картинку, отдать её в современном формате, задать размеры под мобильный экран, снять ленивую загрузку, при необходимости попросить браузер начать скачивание пораньше.
Одна эта работа часто вытаскивает LCP из красного в жёлтое, а иногда сразу в зелёное. И делается за день.
Сторонние скрипты
Откройте страницу и честно перечислите, что на ней живёт помимо вашего кода: два счётчика, чат, коллтрекинг, карта, пиксель рекламной сети, виджет отзывов, всплывающее окно с промокодом. Каждый тянет свои файлы с чужого домена, и на их скорость вы влиять уже не можете.
Вопрос к владельцу здесь ровно один: чем из этого вы пользовались за последние три месяца? Часть виджетов ставилась под акцию, которая закончилась год назад, а грузиться продолжает каждый день. Удалить их — самая быстрая правка из всех возможных, и стоит она ноль.
Остальное грузите отложенно, после отрисовки первого экрана. Живую карту почти всегда можно заменить картинкой со ссылкой: карта нужна тем, кто уже собрался ехать, а тормозит она всех подряд.
Шрифты
Одно-два начертания вместо шести, современный формат и обязательно — разрешение браузеру показать текст запасным шрифтом, пока фирменный качается. Иначе человек несколько секунд смотрит на пустое место там, где мог бы уже читать.
Резерв места под то, что подгружается
Против CLS работает скучная дисциплина: ширина и высота у каждой картинки и видео, заранее отведённое место под баннеры и подгружаемые блоки, плашка про cookie поверх содержимого, а не над ним. Ничего сложного, но эти правки почти всегда откладывают на потом: в баллах они видны не так ярко, как экономия на картинках.
Что решает хостинг и CMS, а что — разработчик
Многие задачи из отчёта закрываются без единой строчки кода. Это сильно меняет смету, поэтому таблица ниже — самая практичная часть статьи.
| Что делаем | Кто закрывает |
|---|---|
| Тариф, версия PHP, кэш страниц, HTTP/2 | Хостинг, через поддержку или панель |
| Сжатие картинок, WebP, миниатюры под экран | Настройка CMS или готовый модуль |
| Подключение CDN | Хостинг или разработчик, с проверкой кэша и ресурсов |
| Удаление ненужных виджетов и счётчиков | Владелец сайта, руками |
| Отложенная загрузка чата, карты, пикселей | Разработчик, с проверкой событий и интерфейса |
| Ленивая загрузка картинок ниже первого экрана | Модуль CMS или тема оформления |
| Ранняя загрузка главной картинки и шрифта | Разработчик, правка шаблона |
| Критический CSS, разбор JavaScript-бандла | Разработчик, оценка после диагностики |
| Размеры у картинок, резерв под баннеры | Разработчик, правка шаблонов |
| Переезд на другой шаблон или фреймворк | Отдельный проект и отдельный бюджет |
Верхнюю половину таблицы стоит пройти до того, как вы позовёте программиста. Иногда после неё звать уже некого: метрики зелёные, а счёт от студии не выставлен.
Если разбираться самому неохота, из этого набора и складывается техническая оптимизация — от 35 000 ₽, три-пять недель вместе со сверкой «до и после» на тех же страницах и тех же устройствах.
Скорость и поиск: где связь есть и где её переоценили
Google использует Core Web Vitals в системах ранжирования, но хорошие значения не гарантируют высоких позиций. Удобство страницы рассматривается вместе с другими сигналами; из сравнения скорости двух сайтов нельзя вывести порядок их мест в выдаче.
Где связь переоценивают:
- Разница между 85 и 95 баллами Lighthouse. Первая оценка относится к категории «требует улучшения», вторая — «хорошо». По этим баллам нельзя определить разницу поисковых позиций.
- Переписывание сайта ради метрик. Бюджет уходит целиком, органика прибавляется от других работ, а победа задним числом приписывается скорости.
- Ожидание роста позиций к заданной дате. Скользящее окно полевых данных не задаёт расписание пересчёта выдачи и не гарантирует рост после ускорения.
Где связь настоящая:
- Мобильный LCP в шесть-восемь секунд. Часть людей закрывает вкладку, не дождавшись картинки, и уходит обратно в выдачу. Это уже не про алгоритм, а про поведение живых людей.
- Медленные ответы и ошибки сервера могут ограничивать обход. Проверяйте это по логам и статистике сканирования; большой клиентский бандл и медленный ответ сервера — разные проблемы.
- Скорость проверяется вместе с остальной техникой. Наличие дублей, ошибок карты сайта или проблем индексации нужно подтверждать отдельно, а не выводить из медленного шаблона.
Ускорение не создаст недостающие страницы и не исправит канонические адреса само по себе. Отсутствие роста трафика за неделю также не доказывает, что скорость не имела значения. Проверяйте отдельно эффект внедрения на метрики и дальнейшую динамику поиска с учётом спроса и других изменений.
Порядок действий на ближайшую неделю
- Откройте отчёт Core Web Vitals в Search Console. Посмотрите, сколько групп адресов в красной зоне и каким шаблонам они соответствуют.
- Прогоните через PageSpeed Insights по одному адресу на шаблон, вкладка «Мобильные». Выпишите LCP, INP и CLS из верхнего, полевого блока. Баллы пока не трогайте вовсе.
- Сравните с порогами из таблицы выше. Красное — в работу, жёлтое — в очередь, зелёное — оставьте в покое, там уже всё хорошо.
- Проверьте время ответа сервера. Если оно большое, всё остальное подождёт: сначала хостинг и кэш.
- Составьте список сторонних скриптов и вычеркните то, чем не пользуетесь. Проверьте, что вычеркнутое действительно исчезло со страницы.
- Займитесь главной картинкой первого экрана на самом проблемном шаблоне.
- После внедрения повторите лабораторные прогоны, а затем следите за полевыми данными и датой их окна. Первые изменения могут появиться раньше месяца, но полное обновление 28-дневной выборки требует времени.
Первичные замеры можно начать самостоятельно. Перед отключением скриптов и изменением кэша зафиксируйте исходные показатели, проверьте назначение компонентов и предусмотрите откат. Время внедрения зависит от CMS, интеграций и найденных причин.
И последнее, про место скорости в общей картине. Это одна страница технического чек-листа, а не весь чек-лист. Если вы уже дошли до замеров, разумнее посмотреть заодно индексацию, дубли и карту сайта — SEO-аудит стоит от 15 000 ₽ и нередко показывает, что скорость у вас третья проблема по важности, а не первая. Или всё-таки первая: тогда вы хотя бы будете знать это точно, а не по красному кружку в отчёте.