Раньше всё было просто: чем быстрее сайт загрузился, тем лучше. Сейчас Google стал умнее (и вреднее). Ему плевать, как быстро загрузился ваш «подвал». Ему важно, как быстро пользователь увидел контент и смог с ним взаимодействовать.
Собственно, набор метрик Core Web Vitals (CWV) — это попытка Google оцифровать раздражение пользователя. Если сайт тупит, скачет и не реагирует на клики — Google пессимизирует его в выдаче.
Давайте разберём этих трёх «всадников», чтобы вы понимали, что именно мы проверяем.
Что такое LCP, CLS и INP на человеческом языке
Забудьте сложные определения. Вот как это выглядит глазами живого человека.
LCP (Largest Contentful Paint) — «Когда я увижу суть?» Это время отрисовки самого большого куска контента на экране. Обычно это заголовок H1 или главная картинка товара. Хороший ориентир — до 2.5 секунд.
Жизнь: вы зашли на сайт, белый экран… белый экран… ОП! Появилась картинка и текст. Вот этот момент «ОП!» и есть LCP. Если человек ждёт 4 секунды — он просто уходит к конкуренту.
CLS (Cumulative Layout Shift) — «Почему всё прыгает?» Это про стабильность верстки.
Жизнь: вы читаете новость, и вдруг сверху подгружается рекламный баннер. Весь текст резко съезжает вниз, и вы теряете строчку. Или ещё веселее: хотели нажать «Отмена», а в момент клика кнопка сдвинулась — и вы нажали «Купить». Google ненавидит такие вещи. Если верстка «дышит» при загрузке — нормально ранжироваться не получится.
INP (Interaction to Next Paint) — «Ты вообще работаешь?» Эта метрика недавно заменила старую FID. Она про отзывчивость сайта.
Жизнь: вы нажимаете на кнопку «Меню» или фильтр в каталоге, а сайт молчит. Думает. Процессор занят тяжёлым скриптом. Только через полсекунды что-то происходит. Вот эта задержка — и есть INP. Нормальный сайт должен реагировать почти мгновенно, без «подвисаний».
Google PageSpeed Insights: как смотреть, чтобы не сойти с ума
Этот сервис знают все. Но 90% людей смотрят в нём не туда. Типичный сценарий: вбили домен, увидели большую цифру (например, 45), расстроились, закрыли вкладку.
Разберём, что реально важно.
Мобильные — всегда в приоритете По умолчанию PSI показывает вкладку «Мобильные» — и это правильно. Google давно перешёл на Mobile-First Indexing. Ему почти всё равно, как ваш сайт летает на мощном ноутбуке с оптоволокном. Важно, как он открывается на недорогом смартфоне в метро с 3G.
Если на десктопе у вас 90, а на мобильном 30 — проблемы именно в мобильной версии. Ориентируйтесь в первую очередь на мобильную оценку.
Реальные данные vs лабораторные В отчёте есть два важных блока:
— Оценка оптимизации (большой круг с цифрой). Это синтетика. Робот Lighthouse прямо сейчас зашёл на ваш сайт и смоделировал загрузку.
— Основные интернет-показатели (Core Web Vitals). Это реальные данные (CrUX) — статистика по настоящим пользователям Chrome за последние 28 дней.
Парадокс: у вас может быть оценка «30» (красная зона), но при этом блок с реальными данными будет зелёным и с пометкой «Пройдено». Это значит, что в теории код можно оптимизировать, но в реальной жизни пользователи и так ничего не замечают: у них нормальные телефоны и связь.
Совет: если реальные Core Web Vitals зелёные — выдыхайте. Вы прошли экзамен Google. Цифра в кружочке — рекомендация разработчику, а не приговор бизнесу.
Но есть нюанс: у нового сайта с маленьким трафиком реальных данных может не быть. Тогда придётся опираться на синтетику.
GTmetrix: «водопад», который всё расставляет по местам
Когда нужно показать программисту, что именно тормозит сайт, я почти всегда открываю GTmetrix. Раньше он был полностью бесплатным, сейчас часть функций урезали, но базовых возможностей достаточно.
Главная ценность — вкладка Waterfall (диаграмма-водопад). После проверки не зацикливайтесь на итоговых оценках. Прокрутите вниз до «водопада».
Вы увидите длинный список всех файлов, которые грузятся при открытии страницы, и полоски времени для каждого.
Что искать:
— Длинные полоски. Если один файл грузится 2–3 секунды, а остальные — миллисекунды, вот ваш враг. Часто это огромное фоновое видео, гигантская картинка или тяжёлый скрипт.
— Сторонние скрипты. Отдельно смотрите на все внешние подключаемые штуки: онлайн-чат, пиксели соцсетей, виджеты. Часто выясняется, что сам сайт быстрый, но один «перезвоните мне» тормозит загрузку на 3 секунды.
WebPageTest: кино про загрузку вашего сайта
Главное отличие — гибкость. Вы можете сами выбрать:
— конкретную модель телефона; — тип соединения (3G, 4G, медленный мобильный интернет); — локацию (как сайт открывается из Варшавы, Лондона или Амстердама).
Киллер-фича — Filmstrip (киноплёнка). Сервис делает скриншоты сайта каждые 0.1 секунды и показывает их лентой.
Пример:
0.5 сек — белый экран;
1.0 сек — появилось меню;
1.5 сек — появился текст;
2.0 сек — загрузился шрифт, и текст «прыгнул» (плохой знак для CLS).
После такого отчёта не нужно объяснять, почему пользователь нервничает — всё видно глазами.
5. Главные «убийцы» скорости и как их лечить
Google любит писать обобщённо: «Сократите размер CSS», «Минимизируйте JavaScript». На практике 90% проблем повторяются из проекта в проект. Начните с базовых вещей.
Убийца №1: тяжёлые картинки
Классика: дизайнер отдал макет в PNG, контент-менеджер залил на главную фото весом 5 Мб — и всё, LCP умер.
Что делать:
— Формат WebP. Для фото WebP почти всегда выигрывает у JPEG и PNG: вес меньше на 30–40% при сопоставимом качестве. Все современные браузеры его понимают.
— Lazy Loading (ленивая загрузка).
Картинки ниже первого экрана не должны грузиться сразу. Используйте стандартный атрибут loading="lazy", чтобы изображения подгружались только при прокрутке.
Убийца №2: сторонние виджеты и счётчики
Онлайн-чаты, виджеты обратного звонка, пиксели рекламы, карты — всё это тянет свои скрипты и блокирует загрузку.
Что делать:
— Отложенная загрузка (defer).
Скрипты аналитики и чатов не должны мешать отрисовке контента. Подключайте их с атрибутами defer или через тег <script> внизу страницы.
— Лайфхак с картой. Вместо «живой» карты на весь экран сначала ставьте обычную картинку с картой. Пользователь кликает — после клика подгружается настоящая карта. На первом экране сайт грузится гораздо быстрее.
Убийца №3: шрифты и «моргание» текста
Бывало такое: заходите на сайт — текст сначала один, через секунду другие буквы, всё немного сдвигается? Это как раз влияет на CLS.
Что делать:
— Предзагрузка только нужных шрифтов.
Через <link rel="preload"> подгружайте только те шрифты, которые используются на первом экране.
— Свойство font-display: swap. Оно говорит браузеру: «Покажи текст сразу системным шрифтом, а когда фирменный шрифт догрузится — аккуратно замени». Так пользователь видит текст мгновенно, без пустых мест.
Убийца №4: отсутствие кэширования
Если сервер каждый раз заново «собирает» страницу при каждом запросе — это почти всегда лишняя нагрузка и лишние секунды.
Что делать:
— Включить серверное и браузерное кэширование. Для WordPress это решается плагинами вроде WP Rocket, W3 Total Cache, WP Super Cache. Они создают статичную версию страницы (HTML) и отдают её пользователю сразу, без лишних расчётов на сервере.
Резюме здорового человека
Не играйте в гонку за 100/100 в PageSpeed Insights. Эта цифра больше про «идеальный мир разработчиков», чем про реальную пользу для бизнеса.
Ваша настоящая цель — зелёные Core Web Vitals по реальным данным и комфорт пользователя.
Если:
— вы сжали и перевели ключевые изображения в WebP; — настроили ленивую загрузку картинок и не критичных блоков; — убрали тяжёлые скрипты с верхней части страницы; — починили «прыгающую» верстку и снизили CLS;
то вы уже сделали 80% работы, которой достаточно, чтобы Google не душил ваш сайт, а пользователи спокойно читали, скроллили и нажимали кнопки без истерики.
Нужно ли добиваться 100/100 в Google PageSpeed Insights?
Нет. 100/100 — это скорее технический идеал, а не обязательное условие для хорошего ранжирования. Куда важнее, чтобы реальные Core Web Vitals были в зелёной зоне и чтобы пользователям было комфортно пользоваться сайтом. В большинстве ниш оценка 70–90 при зелёных CWV — уже отличный результат.
Как часто нужно проверять скорость сайта?
Оптимально — раз в месяц или после крупных изменений: редизайн, смена шаблона, установка новых виджетов, подключение чатов и скриптов. Для небольших сайтов без частых обновлений достаточно раз в квартал. Если активно дорабатываете функционал — проверяйте чаще, раз в 2–4 недели.
Какой показатель LCP считается нормальным?
Рекомендация Google — укладываться в 2.5 секунды для 75% пользователей. Но ориентируйтесь не только на цифру, а на реальное ощущение: появляется ли главное содержание достаточно быстро, чтобы человек не успел раздражаться и уходить с сайта.
Что важнее: скорость или дизайн?
Баланс. Красивый, но тяжёлый дизайн, который грузится 7 секунд, «убьёт» конверсию. Супербыстрый, но уродливый сайт — тоже. Ваша задача — сделать так, чтобы первый экран загружался быстро, а всё тяжёлое (анимации, видео, второстепенные блоки) подтягивалось потом, не мешая пользователю.
Если у меня мало трафика, как понять, всё ли нормально с CWV?
В этом случае у Google может не быть реальных данных. Тогда опирайтесь на лабораторные замеры: PageSpeed Insights, GTmetrix, WebPageTest. Проверьте несколько ключевых страниц (главная, категория, статья, карточка товара) и ориентируйтесь на рекомендации по LCP, CLS и INP именно в мобильной версии.