Как подойти к задаче без лишней магии
Если Lighthouse показывает 95, а люди жалуются, что сайт тормозит, я не верю одной зелёной цифре. Сначала смотрю реальные группы URL в Search Console, затем нахожу виновника в PageSpeed и DevTools.
Ошибка, которую я бы сразу убрал: Лениво загружать hero-изображение.
Что подготовить и какой результат ждать
- На выходе: Вы понимаете, какой ресурс или скрипт тормозит страницу, и можете проверить исправление по полевым данным, а не только по лабораторному тесту.
- Откройте Search Console → Основные интернет-показатели и разделите Mobile/Desktop. Для проблемного URL запустите PageSpeed Insights.
- Сохраните исходные данные и права доступа отдельно от результата, чтобы можно было проверить, что сделал скорость и Core Web Vitals.
- Ориентиры хорошего результата: LCP до 2,5 с, INP до 200 мс и CLS до 0,1. После исправления нажмите начать проверку в Search Console.
Найдите главную проблему и исправьте её по одной
- Найдите проблемный URL
В Search Console откройте группу проблемы, а затем конкретный URL. Скопируйте его в PageSpeed Insights и посмотрите, что является LCP.
Проверьте: Понятно, что именно пользователь ждёт дольше всего.
Если не сработало: Проверьте страницу в Chrome DevTools Performance на мобильном профиле.
- Исправьте первый экран
Сожмите hero-изображение, задайте размеры и не лениво загружайте главный визуал. Откладывайте второстепенные виджеты и сторонние скрипты.
<img src="/hero.webp" width="1200" height="700" fetchpriority="high" alt="Мастер ремонтирует кондиционер">Проверьте: Главный визуал появляется без ожидания тяжёлого JS.
Если не сработало: Замените видео/анимацию на статичный первый кадр для теста.
- Уберите скачки и долгие задачи
Задайте width/height для изображений и iframe, зарезервируйте место под баннеры, сократите тяжёлый JavaScript и разбейте долгие задачи.
Проверьте: На мобильном экране элементы не прыгают при загрузке.
Если не сработало: Отключите сторонние виджеты по одному и найдите виновника.
- Проверьте реальный сценарий
В DevTools включите слабый CPU и мобильную сеть, перезагрузите страницу и запишите Performance. Сравните результат до и после на одном URL.
Проверьте: Исправление улучшило нужную метрику, а не только общий балл.
Если не сработало: Верните последнее изменение и проверьте его отдельно.
Чиню сначала тот элемент, который назвал LCP
Цели для хорошего результата: LCP ≤ 2,5 с, INP < 200 мс, CLS < 0,1. Если LCP — hero-изображение, не ставьте ему `loading=lazy`: задайте размеры, современный формат и `fetchpriority=high`. Изображения ниже первого экрана, наоборот, грузите лениво.
Для CLS резервируйте место под изображения, видео, iframe, чат и cookie-баннер. Для INP откройте DevTools → Performance и ищите длинные задачи: чаты, карты, слайдеры и несколько аналитических виджетов одновременно.
<img src="/assets/hero.avif" width="1440" height="900" fetchpriority="high" alt="Команда работает над процессом">Не путайте лабораторию с реальными пользователями
Зафиксируйте URL, устройство, источник данных, LCP, INP и CLS до изменения. После правки снова проверьте PageSpeed и DevTools на одном URL, а затем ждите обновления полевых данных Search Console. Если исправить только score, но оставить медленную форму или прыгающую кнопку, пользователь лучше не станет.
- Сначала отключайте сторонние виджеты по одному.
- Не лениво загружайте главный визуал.
- Не сравнивайте мобильные и десктопные данные как одну метрику.
Один тест — один виновник
Сначала отключите один сторонний виджет, снова измерьте и запишите результат. Потом верните его и проверьте следующий. Не переписывайте весь frontend одновременно: иначе вернёте старую версию, а причина останется неизвестной.
Для каждой группы URL храните `metric`, `device`, `source`, `before`, `after`, `change`, `owner` и `date`. Если основная проблема — тяжёлый hero, оптимизируйте его; если INP — сокращайте JavaScript. Не чините CLS заменой шрифта, если скачок создаёт рекламный слот.
Что должно измениться после настройки
Вы понимаете, какой ресурс или скрипт тормозит страницу, и можете проверить исправление по полевым данным, а не только по лабораторному тесту.
Какие ускорения случайно ухудшают первый экран
Лениво загружать hero-изображение.
Исправлять только лабораторный балл и игнорировать реальные данные.
Забывать размеры изображений и iframe.
Добавлять ещё один виджет, пока первый экран уже перегружен.
Когда скорость требует работы с архитектурой
Нужен специалист, если медленные места связаны с CMS, серверным рендерингом, большим JS-бандлом или несколькими внешними системами.
Что проверить после оптимизации
Почему PageSpeed и Search Console показывают разные цифры?
PageSpeed сочетает лабораторный тест и доступные полевые данные, а Search Console использует агрегированные реальные посещения за период.
Нужно ли получить 100 баллов?
Нет. Важнее стабильная работа ключевых страниц и хорошие реальные показатели на устройствах клиентов.
Что исправлять первым?
То, что влияет на главный контент и первый экран, затем скачки макета и долгие интерактивные задачи.
Когда результат появится в Search Console?
Полевые данные обновляются не мгновенно. Лабораторный тест проверяет изменение сразу, а реальный отчёт требует накопления новых посещений.
