Шаблон брифа по улучшению Core Web Vitals

Бриф по внедрению (для заполнения)

Когда использовать: Один бриф на каждую проблемную группу URL: полевая база, лабораторное воспроизведение, затронутый шаблон, исправление, ответственный и окно повторной проверки.

Бриф по внедрению улучшений Core Web Vitals

Пишите один бриф на каждую проблемную группу URL в Search Console, а не на каждый URL. У страниц группы общий шаблон, поэтому одно исправление обычно подтягивает всю группу.

1. Полевая база

2. Лабораторное воспроизведение

• Пример URL из группы: [URL]
• Инструмент и настройки: [Lighthouse / DevTools, устройство, замедление сети]
• Что воспроизводится: [например, элемент LCP - главное изображение, 3,9 с, задержка загрузки 1,6 с]
• Не удалось воспроизвести? [отметьте это; проблемы INP, видимые только в полевых данных, часто требуют данных реальных пользователей]

3. Затронутый шаблон и причина

• Шаблон / компонент: [страница товара, компонент главного баннера]
• Размер группы URL: [количество URL в группе Search Console]
• Корневая причина: [одно предложение]

4. Исправление и критерии приёмки

• Предлагаемое исправление: [предзагрузить главное изображение, задать fetchpriority, убрать lazy-load]
• Лабораторная приёмка: [LCP меньше 2,5 с на тестовом URL с теми же настройками]
• Полевая приёмка: [группа получает статус «хорошо» в Search Console после проверки]
• Риск: [что может сломаться, например вёрстка на маленьких экранах]

5. Ответственный и окно повторной проверки

• Ответственный: [имя, команда] · Проверяющий: [имя]
• Дата выкладки: [дата] · Проверка начата: [дата] · Проверить результат: [дата + 28 дней]

Критерий завершения: лабораторная приёмка пройдена, проверка в Search Console запущена, результат записан через 28 дней, а бриф закрыт или открыт заново с новой причиной.

База и полевые данные против лабораторных

Когда использовать: Зафиксируйте базовые значения каждой метрики Core Web Vitals до любых изменений и поймите, каким данным доверять для оценки, а каким для отладки.

Зафиксируйте базу

Прежде чем что-то оптимизировать, запишите, где сейчас находится каждая метрика для [URL страницы]. Search Console показывает полевые данные (реальные пользователи Chrome из набора CrUX, скользящее окно 28 дней), поэтому именно это число нужно отчитывать и проходить. Лабораторные данные (Lighthouse, одна симулированная загрузка) нужны для отладки: они воспроизводимы и дают трассировки, с которыми можно работать.

• Полевой источник: возьмите данные CrUX из PageSpeed Insights или отчёта «Основные интернет-показатели» (Core Web Vitals) в Search Console для [ресурса].
• Лабораторный источник: запустите Lighthouse (Chrome DevTools или PageSpeed Insights), чтобы воспроизвести и отследить проблемы.
• Запишите пороги: LCP хорошо <=2,5 с, требует улучшения <=4 с; INP хорошо <=200 мс, требует улучшения <=500 мс; CLS хорошо <=0,1, требует улучшения <=0,25. Для каждой метрики отметьте значение 75-го процентиля и статус.

Полевые и лабораторные данные будут расходиться, и это нормально. Лабораторный тест - это одно устройство и одна сеть, а полевые данные объединяют множество. Лабораторию используйте, чтобы найти причину, а поле, чтобы подтвердить исправление.

Результат: таблица базовых значений с каждой метрикой, её текущим полевым значением, лабораторным значением и статусом «пройдено/не пройдено» на [дату].

Исправления Largest Contentful Paint (LCP)

Когда использовать: Найдите и устраните причины медленного LCP, чтобы основной элемент контента отрисовывался за 2,5 секунды у большинства посетителей.

Пусть основной контент появляется быстро

LCP измеряет момент, когда самый крупный видимый элемент (обычно главное изображение, постер видео или блок заголовка) заканчивает отрисовку. Цель: <=2,5 с на 75-м процентиле. Найдите элемент LCP в Lighthouse или на панели Performance в DevTools, затем разложите его время на четыре части. Руководство Google на web.dev даёт примерные ориентиры для каждой.

1. Время до первого байта (около 40%): сократите время ответа сервера для [домена] с помощью кеширования, более быстрого хостинга или рендеринга на edge-серверах.
2. Задержка загрузки ресурса (менее 10%): сделайте изображение LCP видимым в HTML, предзагрузите его и задайте fetchpriority="high", чтобы браузер начал загрузку раньше.
3. Длительность загрузки ресурса (около 40%): отдавайте изображение в отображаемом размере, в современном формате и через CDN.
4. Задержка отрисовки элемента (менее 10%): уберите блокирующие отрисовку CSS и JavaScript и никогда не применяйте lazy-load к изображению LCP.

Не загружайте главное изображение через фон CSS или клиентский JavaScript: браузер обнаружит его слишком поздно. Проверьте исходный HTML с помощью Get Source Code of Webpage, чтобы убедиться, что тег изображения и предзагрузка действительно есть в ответе сервера.

Проверка: повторите лабораторный тест и убедитесь, что элемент LCP для [URL страницы] теперь загружается быстрее 2,5 с, и определите, какая из четырёх частей сократилась.

Исправления Interaction to Next Paint (INP)

Когда использовать: Улучшите отзывчивость, чтобы страница быстро реагировала на клики, касания и нажатия клавиш. INP заменил прежнюю метрику FID.

Пусть взаимодействия ощущаются мгновенными

INP заменил FID в составе Core Web Vitals в марте 2024 года. Он измеряет задержку взаимодействий за всё посещение страницы и показывает примерно самое медленное из них. Цель: <=200 мс. Плохой INP почти всегда связан с JavaScript, который занимает основной поток в момент действия пользователя.

• Найдите длинные задачи: на панели Performance в DevTools ищите задачи основного потока дольше 50 мс во время взаимодействия на [URL страницы].
• Разбейте JavaScript: делите длинные задачи на небольшие части и уступайте основной поток, чтобы ввод успевал обрабатываться.
• Сократите работу основного потока: удалите или отложите неиспользуемые скрипты, особенно тяжёлые сторонние теги вроде [название тега].
• Оптимизируйте обработчики событий: применяйте debounce к тяжёлой работе и откладывайте несрочные обновления до следующей отрисовки.
• Уменьшите размер DOM и стоимость вёрстки: большой или глубоко вложенный DOM делает каждое взаимодействие дороже.

Цель в том, чтобы основной поток был свободен, когда пользователь кликает и касается экрана, и браузер успевал отрисовать ответ в пределах бюджета 200 мс.

Проверка: протестируйте реальные взаимодействия и убедитесь, что полевой INP движется к статусу «хорошо» для [ресурса].

Исправления Cumulative Layout Shift (CLS)

Когда использовать: Остановите прыжки контента во время загрузки, чтобы вёрстка оставалась визуально стабильной и CLS был ниже 0,1.

Остановите прыжки вёрстки

CLS измеряет неожиданные сдвиги видимого контента за всё время жизни страницы. Цель: <=0,1. Сдвиги раздражают пользователей и приводят к случайным кликам, и почти всегда их вызывают элементы, которые загружаются без зарезервированного места.

• Задавайте размеры медиа: всегда указывайте атрибуты width и height (или CSS aspect-ratio) для изображений, видео и iframe, чтобы браузер резервировал место до их загрузки.
• Резервируйте место для встраиваний и рекламы: поместите слоты для [рекламы или встраивания] в контейнер с фиксированной min-height, чтобы они не сдвигали контент вниз.
• Никогда не вставляйте контент над существующим: не добавляйте баннеры, уведомления или cookie-плашки, которые сдвигают страницу вниз после отрисовки.
• Предотвращайте сдвиги при смене шрифта: предзагружайте ключевые шрифты и разумно используйте [font-display], чтобы ограничить перестроение.
• Резервируйте место для динамического интерфейса: оставляйте место для элементов, которые добавляет JavaScript, чтобы они раскрывались в заранее выделенное пространство.

Считайте любой "прыжок", заметный во время загрузки, дефектом, который нужно устранить.

Проверка: просмотрите покадровую ленту загрузки и убедитесь, что на [URL страницы] нет видимых сдвигов.

Оптимизация ресурсов и доставки

Когда использовать: Сократите и ускорьте ресурсы, которые отдаёт страница (изображения, JavaScript, CSS, кеширование и CDN), чтобы улучшить все метрики сразу.

Отдавайте меньше и доставляйте быстрее

Большинство проблем со скоростью страниц сводятся к тому, что отдаётся слишком много байтов или они передаются слишком медленно. Оптимизация доставки улучшает LCP, INP и CLS одновременно, потому что браузеру нужно меньше скачивать, разбирать и выполнять.

• Изображения: используйте современные форматы (например, WebP или AVIF), подгоняйте их под отображаемые размеры и сжимайте; применяйте lazy-load только к изображениям ниже первого экрана и никогда к изображению LCP.
• JavaScript: минифицируйте, применяйте tree-shaking и разделение кода, чтобы каждая страница загружала только нужное; используйте defer или async для некритичных скриптов.
• CSS: минифицируйте, удаляйте неиспользуемые правила и встраивайте критический CSS для контента первого экрана в [шаблоне].
• Кеширование: задавайте долгий срок кеширования для статических ресурсов и используйте имена файлов с хешем, чтобы обновления безопасно сбрасывали кеш.
• CDN: отдавайте ресурсы с edge-серверов рядом с пользователями и включите сжатие (Brotli или gzip) в [CDN-провайдере].

Безжалостно проверяйте сторонние скрипты: это частая и незаметная причина медленной загрузки и плохой отзывчивости.

Проверка: сравните общий объём передачи и число запросов до и после для [URL страницы].

Повторная проверка и мониторинг

Когда использовать: Подтвердите, что исправления сработали в полевых данных, и настройте постоянный мониторинг, чтобы вовремя замечать ухудшения.

Подтвердите результат и удержите его

Исправление не завершено, пока его не подтвердят полевые данные. CrUX использует скользящее окно 28 дней, поэтому улучшения у реальных пользователей проявляются постепенно. Проверяйте в два этапа: сначала лабораторный тест для мгновенной обратной связи, затем полевые данные в течение следующих недель.

1. Повторите лабораторные тесты: убедитесь в Lighthouse или PageSpeed Insights, что проблема на уровне трассировки на [URL страницы] исчезла.
2. Запустите проверку в Search Console: в отчёте «Основные интернет-показатели» (Core Web Vitals) откройте проблему и начните проверку. Search Console отслеживает группу URL 28 дней, и даже один оставшийся проблемный URL оставляет проблему открытой.
3. Держите целевые значения: LCP <=2,5 с, INP <=200 мс, CLS <=0,1 на 75-м процентиле. Статус группы URL определяется её худшей метрикой.
4. Мониторьте постоянно: добавьте мониторинг реальных пользователей или плановые проверки для [ресурса], чтобы ухудшения быстро становились заметны.
5. Защищайтесь от дрейфа: перепроверяйте после релизов, новых сторонних тегов или изменений шаблонов.

Результат: заметка «до и после» для каждого брифа с датой начала проверки [дата] и результатом.

Разобранный пример (вымышленный мебельный магазин)

Когда использовать: Заполненный бриф для вымышленного интернет-магазина мебели, у которого страницы товаров не проходили LCP на мобильных.

Разобранный пример: страницы товаров Oak & Ember

Только пример. Компания, люди, URL и цифры вымышлены, чтобы показать, как выглядит рабочая заполненная версия.

Почему этот бриф сработал

В нём названа одна причина для 1 900 URL. Разработчику не пришлось трогать каждую страницу, только компонент галереи. А дата через 28 дней была записана в брифе, поэтому никто не объявил победу после одного удачного прогона Lighthouse.

Следующий шаг

Запустите бесплатный аудит сайта, чтобы увидеть Core Web Vitals главной страницы и список исправлений простым языком. Проверяйте любой шаблон прямо во время просмотра с помощью seotools.pro SEO Extension, которое включает Core Web Vitals в проверки страницы. Если вашей команде нужно, чтобы исправления внедрили за вас, наша команда разработки сайтов может взять бриф в работу.