Ищи то, что тормозит конкретного пользователя
Core Web Vitals видно в том, как открывается страница на телефоне, а не в зелёной карточке отчёта. Найди элемент, который ждёт пользователь, и скрипт, который мешает нажать.
Первое, что я бы убрал: Сжимать все изображения подряд, не проверяя, какое из них формирует LCP.
Что измерить до оптимизации
- LCP, INP и CLS на реальном шаблоне.
- Главный элемент первого экрана.
- Сторонние скрипты и тяжёлые ресурсы.
- Проверка на телефоне после каждого изменения.
Как улучшить LCP, INP и CLS
- Найди проблемный URL
Открой проблемный URL в Яндекс Браузере → «Дополнительно → Дополнительные инструменты → Инструменты разработчика» или нажми Ctrl+Shift+I. В Performance включи мобильный профиль и запиши LCP, INP и CLS. Яндекс Вебмастер используй отдельно для проверки индексации: «Индексирование → Проверка страницы».
Что увидишь: Понятно, что пользователь ждёт дольше всего.
Если не сработало: Сохрани HAR и проверь сеть, размер ресурсов и длинные задачи в инструментах разработчика Яндекс Браузера.
- Исправь первый экран
Сожми hero-изображение, задай размеры и не лениво загружай главный визуал. Откладывай второстепенные виджеты и сторонние скрипты.
<img src="/hero.webp" width="1200" height="700" fetchpriority="high" alt="Мастер ремонтирует кондиционер">Сверь: Главный визуал появляется без ожидания тяжёлого JS.
Если не сходится: Замени видео/анимацию на статичный первый кадр для теста.
- Убери скачки и долгие задачи
Задай width/height для изображений и iframe, зарезервируй место под баннеры, сократи тяжёлый JavaScript и разбей долгие задачи.
Что должно совпасть: На мобильном экране элементы не прыгают при загрузке.
Если ответ другой: Отключи сторонние виджеты по одному и найди виновника.
- Проверь реальный сценарий
В инструментах разработчика Яндекс Браузера включи слабый CPU и мобильную сеть, перезагрузи страницу и запиши Performance. Сравни результат до и после на одном URL.
Перед запуском: Исправление улучшило нужную метрику, а не только общий балл.
Если упёрлось: Верни последнее изменение и проверь его отдельно.
Чиню сначала тот элемент, который назвал LCP
Ориентиры Google для «good» (проверено 2026-08-08): LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1. Если LCP — hero, не ставь ему loading=lazy: задай размеры, современный формат и fetchpriority=high. Для CLS зарезервируй место под изображения, видео, iframe, чат и cookie-баннер. Для INP открой Performance и ищи длинные задачи: чаты, карты, слайдеры и несколько аналитических виджетов одновременно.
<img src="/assets/hero.avif" width="1440" height="900" fetchpriority="high" alt="Команда работает над процессом">Не путай лабораторию с реальными пользователями
Зафиксируй URL, устройство, источник данных, LCP, INP и CLS до изменения. После правки снова проверь инструменты разработчика Яндекс Браузера на одном URL. Для field-данных используй собственный RUM или отчёт на базе реальных пользователей (например CrUX / проверка скорости field data). Яндекс Вебмастер нужен для индексации, а не как отчёт Core Web Vitals. Если исправить только score, но оставить медленную форму или прыгающую кнопку, пользователь лучше не станет.
- Сначала отключай сторонние виджеты по одному.
- Не лениво загружай главный визуал.
- Не сравнивай мобильные и десктопные данные как одну метрику.
Один тест — один виновник
Сначала отключи один сторонний виджет, снова измерь и запиши результат. Потом верни его и проверь следующий. Не переписывай весь frontend одновременно: иначе причина останется неизвестной.
Для каждой группы URL храни `metric`, `device`, `source`, `before`, `after`, `change`, `owner` и `date`. Если основная проблема — тяжёлый hero, оптимизируй его; если INP — сокращай JavaScript. Не чини CLS заменой шрифта, если скачок создаёт рекламный слот.
Лабораторный тест и реальные данные
| Критерий | Вопрос | Хороший признак |
|---|---|---|
| Вход | Что нужно подготовить для проверки скорости и Core Web Vitals? | Открой проблемный URL в Яндекс Браузере, включи мобильный профиль Performance и запиши LCP, INP и CLS. Для индексации отдельно проверь URL в Яндекс Вебмастере → «Индексирование → Проверка страницы». |
| Действие | Что система может сделать сама? | Только заранее перечисленные действия, без доступа ко всему аккаунту |
| Проверка | Как понять, что результат можно принять? | Ориентиры «хорошо» по Google Core Web Vitals (web.dev, 2026): LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1 на 75-м перцентиле реальных пользователей. После правки повтори lab-запись; field-данные смотри в RUM / CrUX / доступной аналитике, а не в отчёте индексации. |
| Сбой | Куда уходит непонятный случай? | Сравни lab-метрики (инструменты разработчика Яндекс Браузера / Lighthouse / проверка скорости) и field-метрики реальных пользователей (RUM или CrUX). Чини один самый тяжёлый ресурс; не меняй CDN, шрифт и весь JavaScript одновременно. |
Что считать улучшением
Ты увидишь конкретный ресурс и действие, которое стало быстрее — не новый средний балл без объяснения.
Почему зелёный отчёт не равен быстрой странице
Лениво загружать hero-изображение.
Исправлять только лабораторный балл и игнорировать реальные данные.
Забывать размеры изображений и iframe.
Добавлять ещё один виджет, пока первый экран уже перегружен.
Когда проблема уже архитектурная
Если скорость зависит от CMS, сторонних виджетов и нескольких шаблонов, нужен план изменений с владельцами кода и контента.
С чего начать оптимизацию
Почему lab-проверка и реальные пользователи показывают разные цифры?
Lab (инструменты разработчика, Lighthouse, проверка скорости) — контролируемый прогон. Field — агрегация реальных визитов (RUM, CrUX и похожие отчёты). Они измеряют разное: одноразовый тест vs опыт аудитории за период. Яндекс Вебмастер — про индексацию, а не замена отчёта Core Web Vitals.
Нужно ли получить 100 баллов?
Нет. Важнее, чтобы LCP, INP и CLS на ключевых шаблонах стабильно попадали в «хорошо» для реальных пользователей, а не идеальный лабораторный score.
Что исправлять первым?
То, что влияет на главный контент и первый экран, затем скачки макета и долгие интерактивные задачи.
Когда полевые метрики обновятся после правки?
Lab-тест показывает изменение сразу. Field-данные (CrUX / RUM) накапливаются по мере новых визитов, часто за дни или недели. Не жди «отчёт индексации» как мгновенный CWV-дашборд.
