LCP: когда появляется основное содержимое

Что становится LCP-элементом

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

LCP не измеряет завершение всех сетевых запросов, выполнение всех скриптов или готовность любого действия. Для отклика на действия существует INP, для стабильности расположения блоков CLS. Поэтому исправление LCP не закрывает автоматически остальные вопросы удобства.

Учебный пример: на странице услуги сначала виден заголовок, затем появляется большое фото. Если именно фото стало LCP-элементом, искать причину следует в пути до его отображения. На другой странице самым крупным может быть текст. Одинаковая рекомендация «сжать баннер» здесь не объясняет оба случая.

Как читать секунды и пороги

Для полевой оценки хорошим считается LCP до 2,5 секунды включительно. Значение свыше 2,5 до 4 секунд требует улучшения, выше 4 секунд считается плохим. Эти границы применяют к 75-му перцентилю посещений, отдельно для мобильных устройств и компьютеров. Полевой результат относится к совокупности наблюдений, а не к одной загрузке.

В PageSpeed Insights рядом могут находиться лабораторный результат Lighthouse и полевые данные CrUX. У них разные условия и период. Один тест нужен для воспроизводимой диагностики; полевой блок описывает опыт подходящих реальных посетителей. Если полевых данных нет, это ограничение выборки, а не нулевой LCP.

Четыре участка до появления элемента

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

Быстро скачанная картинка всё равно может появиться поздно, если браузер долго не получил ссылку на неё или не смог отрисовать содержимое. И наоборот, работа только с JavaScript не решит медленную передачу большого изображения. Начинайте с участка, который действительно занимает время в профиле, а не с привычного списка оптимизаций.

Например, в учебном разборе ресурс мог быть найден только после обработки скрипта. Здесь уменьшение размера файла улучшает лишь одну часть пути. Чтобы выбрать решение, нужно проверить момент обнаружения изображения и условия его показа. Числового результата этого примера нет: он иллюстрирует порядок исследования.

Порядок проверки

1. Выберите точный URL и режим устройства. Запишите дату, источник и состояние кеша. Не сравнивайте мобильную категорию с компьютерной карточкой товара как один эксперимент.
2. Откройте подробности LCP и определите элемент. Зафиксируйте его тип, адрес ресурса, если он есть, и положение на экране. Проверьте, что это ожидаемое основное содержимое.
3. Запишите локальный профиль загрузки в Performance. Сопоставьте документ, загрузку ресурса и момент отрисовки. Рассматривайте последовательность событий, а не только общий балл.
4. Сформулируйте одну проверяемую причину и ограниченное изменение. Например, браузер поздно узнаёт об изображении. После изменения повторите тот же сценарий и проверьте остальные функции страницы.
5. Сохраните условия и результаты всех сравниваемых запусков. При заметном разбросе не выбирайте только лучший. Сначала выясните, что изменилось между тестами.

Какие исправления связаны с причиной

При большом ожидании документа исследуют TTFB, серверный ответ и условия кеширования. Если нужный ресурс обнаруживается поздно, проверяют, как он связан с исходным HTML и не отложена ли его загрузка. Если долго передаётся изображение, рассматривают подходящий размер и формат. Это направления проверки, а не готовый диагноз любого медленного сайта.

Когда загрузка закончилась, но элемент ещё не появился, исследуйте отрисовку, стили и работу главного потока. Не переносите всё содержимое за отложенную загрузку ради одного показателя: главный элемент должен появляться вовремя. Любое изменение проверяйте на реальной странице и на нужных размерах экрана.

Как оценить результат в Seohonest

В проверке скорости Seohonest сопоставляйте один и тот же URL и режим. Дата рядом с кешированным результатом означает время исходного измерения. Повторное открытие отчёта не создаёт новый тест. Общий балл Performance и LCP показывают разные величины: балл не переводится напрямую в секунды.

Медиана нескольких сопоставимых запусков помогает описать конкретную серию, но не превращает её в статистику всех посетителей. После публикации исправления лабораторную проверку можно повторить сразу, а полевой результат будет зависеть от своего периода сбора. Сохраните оба источника с понятными подписями.

Как поставить задачу разработчику

Вместо «сделать LCP зелёным» передайте адрес, устройство, отмеченный элемент и наблюдавшийся участок задержки. Приложите профиль и ожидаемый результат изменения. Укажите, какие страницы с тем же шаблоном нужно проверить дополнительно. Так можно подтвердить технический эффект, не обещая заранее определённый балл, срок обновления CrUX или рост позиций.