Проверить скорость сайта умеет любой: открыл PageSpeed Insights, вставил адрес, получил цифру. Сложное начинается дальше — понять, что эта цифра значит и стоит ли из-за неё поднимать разработчика. Core Web Vitals как раз про это: три показателя, которые Google снимает с живых посетителей, и опубликованные пороги, по которым видно, всё в порядке или нет.
За двадцать лет я насмотрелся на обе крайности. Одни владельцы не открывали замер ни разу и удивляются, когда узнают, сколько на самом деле грузится их каталог на телефоне. Другие приносят скриншот с красной оценкой и требуют сотню баллов — хотя оценку эту Lighthouse нарисовал на эмуляции дешёвого смартфона в медленной сети, а у реальных посетителей сайт открывается сносно.
Ниже — как устроен замер, что означает каждая из трёх метрик, где проходят официальные пороги и в каком порядке разбирать проблемы. Отдельно про деньги: что чинится настройками хостинга и CMS, а что придётся заказывать разработчику.
Чем проверить скорость сайта
Инструментов много, рабочих — четыре. Остальные либо повторяют эти, либо считают что-то своё по неизвестной методике, и сверять их между собой бессмысленно.
PageSpeed Insights — главный. Бесплатный, без регистрации, показывает сразу два набора данных: замеры с реальных пользователей Chrome и свежий тестовый прогон. Вкладки для мобильных и для компьютеров разные, смотреть надо мобильную: там всё хуже, и там же обычно основная доля трафика.
Lighthouse во вкладке разработчика Chrome — тот же движок, что и в нижней половине PageSpeed Insights, но прогон идёт с вашей машины и по вашему каналу. Выручает, когда нужно проверить страницу, закрытую от посторонних: корзину, личный кабинет, тестовый сервер.
Search Console, отчёт Core Web Vitals — единственный, который показывает картину по сайту целиком. Google группирует похожие адреса и говорит, сколько групп в зелёной зоне, а сколько нет. Отсюда и надо начинать: одна проверенная страница ничего не сообщает о шаблоне категории, по которому построено три тысячи адресов.
Яндекс Метрика, отчёт «Время загрузки страниц» в разделе «Мониторинг». Считает по вашим посетителям, а не по пользователям Chrome, — то есть видит и тех, кто пришёл из Яндекс Браузера. Своих порогов вроде Core Web Vitals Яндекс не публиковал, зато динамика «стало быстрее или медленнее» здесь честнее всего: выборка ваша собственная.
Замерять только главную бессмысленно: она обычно самая вылизанная. Возьмите по одному адресу на каждый шаблон — главная, категория, карточка товара, страница услуги, статья блога, контакты. Шесть-восемь замеров, и станет видно, где именно провал. Часто он в одном шаблоне из шести, а не «на сайте».
Полевые данные и лабораторные: почему это два разных отчёта
Верх страницы PageSpeed Insights занимает блок с реальными данными. Google собирает их с посетителей Chrome, которые разрешили отправку статистики; окно — последние 28 дней, оценка берётся по 75-му перцентилю. Расшифрую: если у трёх четвертей визитов страница уложилась в порог, метрика зелёная. Не среднее, а именно «у большинства» — один медленный посетитель картину не портит, а четверть медленных портит.
Ниже идёт лабораторный прогон Lighthouse: одна загрузка, сделанная прямо сейчас, на эмуляции мобильного устройства с искусственно замедленным процессором и сетью. Ни одного вашего посетителя в этих цифрах нет.
Отсюда два практических вывода.
- Полевые данные — правда о том, что видят люди. Лабораторные — инструмент диагностики: они говорят, что чинить, но не говорят, насколько всё плохо.
- Полевые обновляются медленно. Выкатили правку — ждите: окно в 28 дней сдвигается постепенно, и первые недели вы будете видеть смесь старого и нового.
Бывает, что полевого блока нет вовсе, а вместо него надпись про нехватку данных. Это не поломка: у страницы просто мало посещений, чтобы набралась статистика. Тогда PageSpeed Insights показывает данные по домену целиком — их и смотрите, только держите в голове, что это среднее по всем страницам сразу, вместе с главной и вместе с забытым разделом «Вакансии».
Почему оценка прыгает от запуска к запуску
Прогнали дважды подряд, а баллы разошлись на десяток. Ничего не сломалось, так и должно быть. Лабораторный замер зависит от вещей, которые меняются между прогонами:
- загрузка машины, на которой выполняется тест;
- сторонние скрипты — рекламная сеть, чат, коллтрекинг отвечают то мгновенно, то через пару секунд;
- состояние кэша на вашем сервере и на 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 смотрит все нажатия за визит и берёт худшее из показательных, а долгие задержки случаются обычно не на первом клике, а на пятом, когда браузер уже занят чужими скриптами.
Виноват в плохом 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 — величина производная. Её собирают из нескольких лабораторных метрик с разными весами, и самый тяжёлый вклад даёт время, на которое главный поток браузера оказался заблокирован. Как индикатор «сегодня хуже, чем вчера» оценка удобна. Как цель — почти бесполезна.
Пороги устроены иначе, они бинарные: 2,4 секунды — зелёная зона, 2,6 — уже нет. Разница в две десятых, а статус страницы меняется. При этом дорога с 78 баллов на 95 может не поменять ровным счётом ничего: если все три метрики и так в зелёном, вы просто потратили бюджет разработки на цифру в отчёте.
Сто баллов в лаборатории при красных полевых данных — это красивый скриншот. Зелёные пороги при семидесяти баллах — это работающий сайт.
Из разговора, который повторяется у меня примерно раз в месяц
Отсюда простое правило для постановки задачи разработчику: формулируйте её через пороги и через полевые данные. «Увести мобильный LCP на карточке товара ниже 2,5 секунды» — такую задачу можно принять и проверить. «Поднять баллы до 90» проверить нельзя: выйдет новая версия Lighthouse, и баллы уедут сами, без единой правки на сайте.
Что чинить в первую очередь
Порядок почти всегда один и тот же, и он редко совпадает со списком рекомендаций внизу отчёта. Тот список отсортирован по расчётной экономии миллисекунд, а не по соотношению «эффект к трудозатратам».
Ответ сервера
Начинать надо здесь. Если сервер отдаёт первый байт долго, дальше можно оптимизировать что угодно: все остальные метрики уже сдвинуты вправо на это время. Ищите в лабораторном отчёте время до первого байта — оно там есть.
Помогает обычно набор скучных вещей: тариф хостинга, на котором вы не делите процессор с сотней соседей; свежая версия PHP; включённое кэширование страниц; база данных, которую хоть раз чистили от мусора, оставшегося после удалённых плагинов. Работы программиста здесь чаще всего нет вовсе — есть письмо в поддержку хостинга и полчаса в админке.
Первый экран
Найдите в отчёте, какой элемент браузер считает главным, и займитесь конкретно им. Дальше по шагам: сжать картинку, отдать её в современном формате, задать размеры под мобильный экран, снять ленивую загрузку, при необходимости попросить браузер начать скачивание пораньше.
Одна эта работа часто вытаскивает LCP из красного в жёлтое, а иногда сразу в зелёное. И делается за день.
Сторонние скрипты
Откройте страницу и честно перечислите, что на ней живёт помимо вашего кода: два счётчика, чат, коллтрекинг, карта, пиксель рекламной сети, виджет отзывов, всплывающее окно с промокодом. Каждый тянет свои файлы с чужого домена, и на их скорость вы влиять уже не можете.
Вопрос к владельцу здесь ровно один: чем из этого вы пользовались за последние три месяца? Часть виджетов ставилась под акцию, которая закончилась год назад, а грузиться продолжает каждый день. Удалить их — самая быстрая правка из всех возможных, и стоит она ноль.
Остальное грузите отложенно, после отрисовки первого экрана. Живую карту почти всегда можно заменить картинкой со ссылкой: карта нужна тем, кто уже собрался ехать, а тормозит она всех подряд.
Шрифты
Одно-два начертания вместо шести, современный формат и обязательно — разрешение браузеру показать текст запасным шрифтом, пока фирменный качается. Иначе человек несколько секунд смотрит на пустое место там, где мог бы уже читать.
Резерв места под то, что подгружается
Против CLS работает скучная дисциплина: ширина и высота у каждой картинки и видео, заранее отведённое место под баннеры и подгружаемые блоки, плашка про cookie поверх содержимого, а не над ним. Ничего сложного, но эти правки почти всегда откладывают на потом: в баллах они видны не так ярко, как экономия на картинках.
Что решает хостинг и CMS, а что — разработчик
Многие задачи из отчёта закрываются без единой строчки кода. Это сильно меняет смету, поэтому таблица ниже — самая практичная часть статьи.
| Что делаем | Кто закрывает |
|---|---|
| Тариф, версия PHP, кэш страниц, HTTP/2 | Хостинг, через поддержку или панель |
| Сжатие картинок, WebP, миниатюры под экран | Настройка CMS или готовый модуль |
| Подключение CDN | Панель хостинга, иногда полчаса настройки |
| Удаление ненужных виджетов и счётчиков | Владелец сайта, руками |
| Отложенная загрузка чата, карты, пикселей | Разработчик, работа на пару часов |
| Ленивая загрузка картинок ниже первого экрана | Модуль CMS или тема оформления |
| Ранняя загрузка главной картинки и шрифта | Разработчик, правка шаблона |
| Критический CSS, разбор JavaScript-бандла | Разработчик, работа на несколько дней |
| Размеры у картинок, резерв под баннеры | Разработчик, правка шаблонов |
| Переезд на другой шаблон или фреймворк | Отдельный проект и отдельный бюджет |
Верхнюю половину таблицы стоит пройти до того, как вы позовёте программиста. Иногда после неё звать уже некого: метрики зелёные, а счёт от студии не выставлен.
Если разбираться самому неохота, из этого набора и складывается техническая оптимизация — от 35 000 ₽, три-пять недель вместе со сверкой «до и после» на тех же страницах и тех же устройствах.
Скорость и поиск: где связь есть и где её переоценили
Google называет удобство страницы вспомогательным сигналом и прямо говорит, что оно не заменяет полезного содержимого. Следствие ровно одно: две одинаково полезные страницы скорость может развести по местам, а слабую страницу она в топ не вытащит.
Где связь переоценивают:
- Разница между 85 и 95 баллами. Обе точки внутри зелёной зоны, поиску они одинаковы.
- Переписывание сайта ради метрик. Бюджет уходит целиком, органика прибавляется от других работ, а победа задним числом приписывается скорости.
- Ожидание, что после ускорения позиции поедут вверх на следующей неделе. Полевые данные обновляются окном в 28 дней, быстрее физически не станет.
Где связь настоящая:
- Мобильный LCP в шесть-восемь секунд. Часть людей закрывает вкладку, не дождавшись картинки, и уходит обратно в выдачу. Это уже не про алгоритм, а про поведение живых людей.
- Тяжёлый сайт хуже обходится роботом: на тот же бюджет обхода приходится меньше страниц. На большом каталоге разница видна по логам сервера сразу.
- Скорость складывается с остальной техникой. Медленный шаблон обычно приходит в комплекте с дублями, кривой картой сайта и мусором в индексе, и разбирать это надо вместе, а не по очереди.
Ускорение не добавит на сайт страниц под запросы, которых у вас нет. Не сделает описания товаров осмысленными. Не уберёт из индекса восемь версий одной карточки. Если после недели работы над картинками и скриптами трафик не сдвинулся, дело было не в скорости — и это нормальный результат проверки гипотезы, а не провал. Плохо другое: когда за скорость берутся, вообще не посмотрев, что там с семантикой и структурой.
Порядок действий на ближайшую неделю
- Откройте отчёт Core Web Vitals в Search Console. Посмотрите, сколько групп адресов в красной зоне и каким шаблонам они соответствуют.
- Прогоните через PageSpeed Insights по одному адресу на шаблон, вкладка «Мобильные». Выпишите LCP, INP и CLS из верхнего, полевого блока. Баллы пока не трогайте вовсе.
- Сравните с порогами из таблицы выше. Красное — в работу, жёлтое — в очередь, зелёное — оставьте в покое, там уже всё хорошо.
- Проверьте время ответа сервера. Если оно большое, всё остальное подождёт: сначала хостинг и кэш.
- Составьте список сторонних скриптов и вычеркните то, чем не пользуетесь. Проверьте, что вычеркнутое действительно исчезло со страницы.
- Займитесь главной картинкой первого экрана на самом проблемном шаблоне.
- Через месяц вернитесь к полевым данным. Раньше смотреть незачем — окно не успеет обновиться.
Шаги с первого по пятый занимают вечер и не требуют ни разработчика, ни бюджета. Дальше начинается работа, которую стоит планировать заранее: часть правок трогает шаблоны, а шаблоны на живом сайте ломаются от невнимательности, и чинить это придётся в пятницу вечером.
И последнее, про место скорости в общей картине. Это одна страница технического чек-листа, а не весь чек-лист. Если вы уже дошли до замеров, разумнее посмотреть заодно индексацию, дубли и карту сайта — SEO-аудит стоит от 15 000 ₽ и нередко показывает, что скорость у вас третья проблема по важности, а не первая. Или всё-таки первая: тогда вы хотя бы будете знать это точно, а не по красному кружку в отчёте.