Кто-то сбросил тебе ссылку на PageSpeed Insights, и ты увидел красные цифры? Не паникуй. Эти метрики простым языком говорят о трёх вещах, которые клиент чувствует на своём телефоне: загрузилась ли страница вообще, реагирует ли она на нажатия и не прыгает ли всё под пальцем. Google советует владельцам сайтов добиваться хороших Core Web Vitals для успеха в поиске и общего удобства пользователей. Это не приговор — это карта того, что чинить в первую очередь, чтобы сайт не отпугивал людей, которые уже на него зашли.
В этой статье ты найдёшь: точные пороги Google без жаргона, объяснение каждой метрики примером из твоей отрасли, схему как читать отчёт за пять минут и конкретный порядок действий. Также узнаешь, как разговаривать с подрядчиком, чтобы не тратить деньги на вещи, которые не имеют смысла.
Три метрики, три ощущения клиента
Что измеряет LCP и почему это важно
Каждая из трёх метрик Core Web Vitals измеряет что-то своё, но все они отвечают на простой вопрос: как клиент чувствует себя на твоём сайте?
LCP (Largest Contentful Paint) — время, за которое появляется самый большой элемент на экране. Для клиента это ответ на вопрос: «Страница вообще работает?». Если ты открываешь сайт стоматолога, а главное фото кабинета загружается четыре секунды — клиент думает, что что-то не так, и закрывает страницу. Хороший LCP — 2,5 секунды или меньше; порог оценивается на 75-м перцентиле загрузок страницы.
Что измеряет INP и почему клиент раздражается
INP (Interaction to Next Paint) — время реакции страницы на клик, касание или ввод текста. Для клиента это ответ на вопрос: «Страница меня слышит?». Когда ты нажимаешь кнопку «Записаться», а страница молчит полсекунды, прежде чем что-то происходит — это раздражает. Хороший INP — 200 миллисекунд или меньше; выше 500 мс считается плохим.
Что измеряет CLS и почему прыгает текст
CLS (Cumulative Layout Shift) — насколько всё смещается на экране во время чтения. Для клиента это ответ на вопрос: «Могу ли я спокойно читать?». Представь, что ты читаешь описание услуги, потом выскакивает баннер кукисов, текст уезжает вниз, и ты теряешь место. Страницы должны иметь CLS 0,1 или меньше, измеряется на 75-м перцентиле.
| Метрика | Что измеряет | Что чувствует клиент | Хороший порог |
|---|---|---|---|
| LCP | Время загрузки самого большого видимого элемента | «Страница вообще работает?» | ≤ 2,5 с |
| INP | Время отклика на любое взаимодействие | «Страница меня слышит?» | ≤ 200 мс |
| CLS | Общее смещение макета при использовании страницы | «Могу ли я спокойно читать?» | ≤ 0,1 |
Почему 75-й перцентиль, а не среднее
Когда ты видишь в отчёте «LCP 3,2 секунды», можешь задуматься, откуда эта цифра. Google не считает среднее из всех визитов. Вместо этого берётся 75-й перцентиль — что это значит на практике?
Вот пример на условных числах — подставь свои. Представь, что твой сайт посещает 100 человек в месяц. Время загрузки выглядит так: 70 человек загрузили страницу за 1,5 секунды, 10 — за 3 секунды, 20 — за 4 секунды. Среднее составило бы около 2,15 секунды и выглядело бы хорошо (меньше 2,5 секунды).
Именно это значение показывается в отчёте, потому что Google хочет знать, у большинства ли пользователей хорошее время, а не феноменальное ли у меньшинства.
Почему это важно для тебя?
Метрика на 75-м перцентиле говорит тебе, есть ли у как минимум трёх четвертей клиентов причина жаловаться.
Поле против лаборатории в PageSpeed Insights
Когда заходишь на pagespeed.web.dev и вводишь адрес своего сайта, видишь два типа данных: из поля и из лаборатории. Важно знать разницу и на какие ориентироваться.
Данные из поля (field data) приходят от реальных пользователей, которые посещали твой сайт за последние 28 дней. Chrome измерял их LCP, INP и CLS в фоне и отправлял эту информацию в Google. Это данные, которым можно действительно доверять, потому что они показывают, как сайт работает в реальном мире — на разных телефонах, в разных сетях, в разное время суток.
Лабораторные данные (lab data) приходят из симуляции Lighthouse. PageSpeed Insights запускает твой сайт в контролируемой среде: на среднем смартфоне, в средней сети 4G. Это инструмент для поиска проблем, не для оценки реальности. Lighthouse может показать красный LCP, но если данные из поля зелёные — не паникуй. Отчёт может также показывать зелёные значения, хотя пользователи жалуются — тогда данные из поля важнее.
Почему данных из поля иногда нет? Если у твоего сайта очень мало посещений, Google не имеет достаточно данных, чтобы показать надёжные значения. В таком случае приходится полагаться на лабораторные данные, но относиться к ним как к намёку на улучшение, не как к окончательному вердикту.
PageSpeed Insights показывает лабораторные данные и данные из поля; над распределением PSI выводит 75-й перцентиль метрик.
Правило: решение принимаешь по полю, проблемы ищешь в лаборатории.
Как читать отчёт PageSpeed Insights за пять минут
Тебе не нужно понимать каждую строку в отчёте. Достаточно пяти шагов:
- 01Адрес
- →02телефон
- →03поле
- →04красное
- →05диагностика
- →06подрядчик
Вот схема:
Введи адрес в PageSpeed Insights → открой результат на телефоне → прочитай данные из поля вверху → если метрика красная, прокрути до диагностики → запиши: «На странице услуг LCP 4,2 с — главная картинка».
Самые частые причины плохого CLS — картинки без размеров, реклама, встраивания и iframe без размеров и динамически вставляемый контент. Когда ты уже знаешь, что не так, можно заказать исправление конкретной вещи, а не говорить «сделай страницу быстрее».
Какие страницы на твоём сайте мерить
Не нужно проверять каждую страницу. Достаточно измерить четыре-шесть ключевых страниц, и ты будешь знать состояние всего сайта:
- Главная страница — твоя визитка, чаще всего первый контакт.
- Две-три самые важные услуги — те, из-за которых люди звонят чаще всего.
- Страница контактов — когда кто-то уже решил позвонить, у него не должно быть проблем с загрузкой номера.
В Search Console (search.google.com/search-console) есть раздел Core Web Vitals, который показывает, какие адреса имеют проблемы. Если десять разных страниц услуг имеют одну и ту же проблему — это вина шаблона, не одной страницы. В таком случае чинишь шаблон, и все страницы улучшаются одновременно.
Что чинить первым — матрица влияния и сложности
Не всё можно исправить сразу. Вот приоритеты, которые позволят тебе начать с того, что даёт больше всего за меньше всего усилий:
| Что чинить | Влияние на метрику | Сложность | Когда чинить |
|---|---|---|---|
| Картинки без размеров (width/height) | CLS, LCP | Низкая | Сразу |
| Тяжёлые графические баннеры на телефон | LCP | Низкая | Сразу |
| Сторонние скрипты (чат, карты, отзывы) | INP | Средняя | После картинок |
| Шрифты с внешних серверов | LCP | Средняя | После картинок |
| Плагины, которые грузят лишний JavaScript | INP | Средняя | После чата |
| Оптимизация сервера (CDN, сжатие) | LCP | Высокая | В конце |
Самые частые причины плохого CLS — картинки без размеров, реклама, встраивания и iframe без размеров и динамически вставляемый контент.
Чего не делать
Прежде чем тратить деньги на «ускорение сайта», запомни три правила:
Не гнаться за 100 баллами в Lighthouse. Результат 100 означает, что страница идеально оптимизирована под тест, не под твоих клиентов. Достижение 100 часто требует отказа от важных функций (карт, форм, галерей). Целься в зелёное поле, не в сотню.
Не ставить «плагины ускорения» без замера до и после. Большинство таких плагинов — это наборы готовых решений, которые иногда работают, а иногда ломают больше, чем чинят. Измерь страницу перед изменением, внеси одно изменение, измерь снова. Только тогда узнаешь, помогло ли.
Не удалять аналитику вслепую. Google Analytics, Meta Pixel и другие инструменты — это источники знания о том, что делают твои клиенты. Вместо удаления проверь, грузятся ли они асинхронно (не блокируют загрузку страницы). Обычно этого достаточно.
Скорость сайта — не всё
У тебя могут быть идеальные Core Web Vitals, но если на странице нет понятного предложения — клиент всё равно не позвонит. Страница может загружаться за секунду, но если непонятно, что ты предлагаешь, за сколько и как заказать, никакая скорость не поможет.
Прежде чем тратить деньги на техническую оптимизацию, проверь, есть ли на странице: заголовок с названием и основной услугой, прайс-лист или понятная кнопка действия, инструкция как заказать. Если этого нет, никакая скорость не заменит контент. Подробнее о том, почему клиенты не оставляют заявок, читай в статье Почему клиенты не оставляют запросов. А о том, как данные фирмы влияют на видимость, — в статье Данные фирмы в Google и на порталах.
Сделай сам за один вечер
Тебе не нужен программист, чтобы начать. Вот пять шагов, которые ты выполнишь сегодня вечером:
- Зайди на pagespeed.web.dev и введи адрес своей главной страницы.
- Сделай то же самое для двух самых важных услуг и страницы контактов.
- Запиши в таблицу (можно в Excel или на бумаге): адрес страницы, LCP, INP, CLS — с цветом: зелёный, янтарный или красный.
- Для каждой красной метрики прочитай одну строку в разделе «Диагностика» — это намёк на то, что не так.
- Отправь подрядчику сообщение: «На странице [адрес] у меня [метрика] [значение], результат предполагает [описание из диагностики]. Прошу оценить исправление этого конкретного элемента.»
Повтори замер после внесения изменений. Если подрядчик говорит, что что-то невозможно или дорого — вернись к этой статье, проверь, это действительно приоритет, и реши, стоит ли оно того.
Как это выглядит, когда за скорость сайта отвечает система
Ручная проверка PageSpeed Insights раз в квартал — хорошее начало, но легко забыть. Лучше превратить это в постоянный ритм: регулярно измерять ключевые страницы в поле (данные реальных пользователей), генерировать отчёт с метриками, превращать красные значения в конкретные задачи и повторять замер после внесения изменений. Результат — история изменений, которую ты видишь чётко: было плохо, сделали X, теперь лучше.
Когда заказываешь сайт, с первого дня получаешь мобильную версию как основную, базовую настройку SEO и аналитику. Самая частая ошибка — публикация без замера — поэтому стоит проверить результаты сразу после запуска. Узнай, как это работает, на странице услуг. Если интересно ещё конверсия на сайте, продвижение, проектирование интерфейсов или аналитика — можем сделать полный аудит твоего сайта. Больше о том, как измерять результаты, читай в статье Автоматизация отчётности. А о том, с чего начать автоматизацию в малом бизнесе — в статье Четыре порога вместо анализа.
Если хочешь узнать, какие звонки и заявки теряются у тебя — пройди оценку на портале.
Частые вопросы
Нужны ли зелёные Core Web Vitals, чтобы быть высоко в Google?
Google учитывает много факторов. Хорошие Core Web Vitals — один из сигналов, который может помочь, но сам по себе не гарантирует позиций. Страница с отличными метриками, но без контента и без ценности для пользователя не обгонит страницу с немного худшими метриками, но с лучшим ответом на вопрос клиента.
Что делать, если PageSpeed Insights показывает данные из поля, но у моего сайта мало посещений?
Если у тебя меньше нескольких сотен визитов в месяц, Google может не иметь достаточно данных. В таком случае полагайся на лабораторные данные (Lighthouse) как намёк, но относись к ним скептически — тестирует на искусственных условиях. В такой ситуации лучше просто позаботься об основах: оптимизированные картинки, никаких лишних скриптов, рабочий HTML-код.
Могу ли я сам починить CLS, если не знаю HTML?
Часто да. Самая частая причина плохого CLS — картинки без размеров. Если используешь WordPress или другую CMS, в большинстве случаев достаточно добавить атрибуты width и height к картинке в редакторе. В конструкторах (Wix, Webflow, GoDaddy) обычно система добавляет их автоматически — проверь в настройках галереи или в опциях картинки.
Сколько стоит исправление Core Web Vitals?
Это зависит от проблемы. Добавление размеров к картинкам — минута работы — даже бесплатно, если делаешь сам. Оптимизация сервера или переписывание кода под большой трафик — больший проект. Ключ — начать с замера и конкретной проблемы, не с общего «сделай сайт быстрее».
Удаление плагинов всегда помогает?
Не всегда. Иногда плагин необходим (например, форма контактов, карта Google). Вместо удаления проверь, есть ли более лёгкая альтернатива или у плагина есть опция асинхронной загрузки. Иногда один плагин замедляет сайт больше, чем десять других — стоит замерить, какой.
Как часто проверять Core Web Vitals?
После внесения изменений — в течение недели, чтобы подтвердить, что помогло. Потом достаточно раз в квартал, если не добавляешь новые функции (новые галереи, плагины, интеграции) — тогда проверяй после каждого изменения.