Как улучшить LCP: найти задержку главного элемента

Чтобы улучшить LCP, сначала найдите элемент, который браузер учитывает в измерении, и участок ожидания перед его появлением. Сжатие всех картинок подряд может не помочь: задержка бывает до запроса изображения или после получения файла. Рабочий результат диагностики — запись конкретного прогона, причина ожидания, проверяемая правка и сравнение с исходным состоянием. Общий балл отчёта не заменяет эту цепочку.

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

Что измеряется и где искать исходное значение

LCP показывает время появления крупнейшего подходящего изображения, текстового блока или другого учитываемого элемента в видимой области. В документации web.dev хорошим ориентиром названо значение не более 2,5 секунды на 75-м процентиле, с разделением мобильных и настольных посещений. Это не срок полной загрузки всего сайта. Открытая панель администратора и установленный на телефоне браузер могут давать разные наблюдения.

Практически начните с одной проблемной страницы. Запишите адрес полностью, тип устройства, дату, режим проверки и источник показателя. Если отчёт показывает данные всего сайта вместо выбранного адреса, отразите это в задаче. Нельзя приписывать странице агрегированное значение без оговорки. Отсутствие полевых данных также не означает, что загрузка быстрая: нужного объёма наблюдений могло не оказаться.

Не соединяйте разные задачи в один показатель. Реакция кнопки после нажатия разбирается в материале об INP. Здесь проверяется появление основного содержимого при загрузке. Если посетитель жалуется, что форма зависает после ввода, сначала выясните этап проблемы. Работа над обложкой не должна закрывать обращение о неотправленной заявке только потому, что оба случая называют «тормозит».

Определите элемент, а не угадывайте по макету

Откройте запись производительности конкретного прогона и сохраните указание на LCP-элемент. Визуально крупный баннер не обязательно окажется выбранным кандидатом во всех условиях. На мобильной ширине и на большом экране может учитываться разное содержимое. Для проверки запишите наблюдавшийся элемент и его фактический ресурс, если это изображение. Одной ссылки на дизайн первого экрана недостаточно.

Сделайте снимок экрана того же запуска. Он поможет обнаружить, что в сравнение попала другая версия блока, уведомление изменило раскладку или изображение вообще не появилось. Если команда исправила один ресурс, а новый прогон учитывает другой элемент, это требует объяснения. Такой результат может быть полезным, но его нельзя объявлять прямым ускорением прежней картинки без дальнейшего разбора.

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

Разделите ожидание на части

Для LCP-изображения удобно разбирать четыре участка: ожидание первого ответа, задержку начала загрузки ресурса, передачу ресурса и задержку его отрисовки. Эту схему описывает руководство web.dev. Не переносите её механически на текстовый элемент как будто у него есть тот же отдельный файл картинки. Сначала установите тип элемента и только потом выбирайте способ разбора.

Учебный пример: общий результат составил 4 секунды. Из них 0,8 ушло до первого ответа, 1,6 — до начала запроса изображения, 0,6 — на получение и ещё 1 — до показа. Сумма равна четырём. Самый длинный участок здесь находится до запроса картинки. Это основание исследовать обнаружение ресурса, а не обещание, что любая настройка сократит результат ровно на 1,6 секунды.

Рассчитайте долю каждого участка: его длительность разделите на общую и умножьте на сто. Для примера задержка начала запроса занимает 40 процентов. Такая оценка помогает выбрать первую гипотезу, но не заменяет техническую проверку причины. Если после правки один участок уменьшился, а другой вырос, сравните весь результат. Перенос ожидания между частями сам по себе не улучшает опыт посетителя.

Согласуйте одну проверяемую гипотезу

Запишите задачу так, чтобы её можно было опровергнуть. Например: «В наблюдаемом мобильном варианте ресурс обложки становится доступен загрузчику поздно; проверяем изменение способа его обнаружения». Рядом укажите исходный прогон и ожидаемое изменение участка. Формулировка «ускорить сайт максимально» не помогает выбрать работу и даёт слишком много возможностей объявить успех без сопоставимого результата.

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

Если основное ожидание приходится на ответ документа, не начинайте с замены формата обложки как единственного исправления. Если долго передаётся сам файл, полезен разбор WebP и AVIF. Он отвечает за другой уровень задачи: выбор и доставку изображений. Здесь важно удержать связь между назначенной работой и измеренным участком, чтобы не оплатить случайный набор улучшений без проверяемой причины.

Сравните повторные запуски по одной карточке

Подготовьте таблицу с колонками «версия», «условия», «элемент», «участки», «общий результат», «наблюдение». Для исходной и исправленной версии используйте одинаковый сценарий. Отдельно фиксируйте состояние кеша, устройство и параметры замедления, если они применялись. Не выдавайте последовательность с прогретыми ресурсами за ускорение первого посещения. Назначение прогона должно оставаться понятным после передачи задачи другому сотруднику.

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

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

Проверьте то, что могло пострадать от ускорения

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

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

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

Что передать специалисту для начала работы

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

Результат диагностики оформляют как короткое заключение: что наблюдалось, какая гипотеза проверена, что изменили, чем подтвердили и что осталось неизвестным. Если измерение не подтвердило гипотезу, это тоже полезный итог. Он должен сузить дальнейший поиск, а не превратиться в неподтверждённое обещание ускорения. Следующая работа выбирается по записи загрузки и значению страницы для посетителей, а не по привычному списку настроек.