Поиск причины позднего Largest Contentful Paint
В предыдущем уроке мы разделили получение ресурса и показ кадра. Теперь применим эту модель к Largest Contentful Paint, или LCP. Метрика помогает исследовать появление крупного содержимого в видимой области, но не говорит сама по себе, какой файл нужно сжать. Сначала требуется найти элемент, затем объяснить его путь к экрану.
Работаем с той же статьёй speed-lab. У baseline изображение вставляется после искусственного таймера, у candidate находится в HTML. Ни один вариант не измерялся автором; все временные значения этого урока выдуманы. Читатель должен получить собственную запись, сохранив условия из первого урока и учитывая свой viewport.
Крупнейшее содержимое может меняться
LCP относится к подходящему содержимому в видимой области: например, изображению или блоку текста. Это не обязательно логотип, верхняя картинка или весь контейнер статьи. По мере появления содержимого кандидат может меняться. В узком окне заголовок и абзац способны оказаться важнее схемы ниже экрана. Определение LCP и кандидаты.
Не выбирайте элемент по внешнему впечатлению. Найдите отмеченный LCP в Performance и посмотрите, какой узел с ним связан. Зафиксируйте viewport и состояние загрузки. Если после изменения разметки кандидат стал другим, сравнение итогового времени уже относится к иной структуре показа. Это допустимое наблюдение, но его нужно назвать явно.
Порог хорошего LCP составляет не более 2,5 секунды на 75-м процентиле соответствующих посещений. Отдельная лабораторная трасса показывает одну ситуацию, а не оценку всей аудитории. Например, учебная запись с поздней схемой способна выявить зависимость, но не доказывает, что настоящие читатели всегда ждут эту схему столько же времени.
У исходных растровых схем стенда небольшой размер: они состоят из простых цветных областей. Такой ресурс нужен для воспроизводимого URL и размеров, но не представляет тяжёлую фотографию. Если браузер выбрал текст, не нужно искусственно увеличивать картинку ради желаемой метрики. Исследуйте обнаруженный элемент либо отдельно сформулируйте новый сценарий.
Разложение пути изображения
Для изображения полезно различать ответ основного документа, задержку начала запроса ресурса, доставку ресурса и ожидание его отображения. Эти части помогают направить действие в нужную причину. Перенос URL в HTML влияет на обнаружение, уменьшение файла — на передачу, освобождение основного потока — на возможность показать результат. Оптимизация LCP.
Рассмотрим полностью выдуманную учебную декомпозицию:
| Участок учебного примера | Время |
|---|---|
| Получение первых данных документа | 700 мс |
| Ожидание начала запроса изображения | 900 мс |
| Доставка изображения | 400 мс |
| Ожидание показа | 1100 мс |
| Упрощённая сумма | 3100 мс |
Эти цифры не получены из speed-lab и не являются замерами ProfessorWeb. В реальной трассе необходимо внимательно сопоставлять границы и события. Таблица нужна для причинного рассуждения: даже полное устранение условных 400 миллисекунд передачи не убирает остальные задержки. Поэтому совет заменить формат картинки способен не решить основную проблему.
Если преобладает ответ документа, исследуйте доставку HTML и путь до сервера. Серия по деплойменту уже объясняет окружения и серверную часть; здесь не будем заново настраивать хостинг. Нам важно правильно отделить вопрос доставки документа от свойств самого LCP-изображения.
Раннее обнаружение ресурса
У baseline URL появляется в обработчике таймера. Для одного независимого изменения перенесём изображение в исходный HTML и удалим прежнюю вставку. Следующий фрагмент заменяет пустой контейнер #hero; другие части baseline пока сохраняются:
<div id="hero">
<img class="hero" src="../assets/delivery-1200.v1.png"
width="1200" height="640"
alt="Три стадии доставки: документ, ресурсы и отображение">
</div>Теперь браузер может обнаружить ресурс при обработке документа. Ожидаемый ручной результат — изменение инициатора и более ранний запрос по сравнению с искусственно задержанной вставкой. Фактический LCP зависит и от остальных фаз, поэтому его снижение не объявляем заранее. Размеры также задают отношение сторон; их влияние на устойчивость разберём отдельно.
Не используйте loading="lazy" для изображения, которое действительно необходимо на первом экране и установлено как LCP-кандидат. Ленивая доставка предназначена для ресурсов, нужных позднее; в нашем сценарии дополнительное ожидание противоречит задаче. Для картинки ниже экрана решение может быть другим. Выбор делается по месту ресурса в сценарии, а не одной настройкой для всего сайта.
Приоритет и его ограничения
У candidate главное изображение имеет fetchpriority="high". Это подсказка браузеру о важности конкретной доставки, а не приказ завершить её немедленно. Прежде чем добавлять такую настройку, убедитесь, что ресурс действительно нужен раньше других. Если повысить приоритет всем картинкам, полезное различие между ними исчезнет. Атрибуты img и fetchpriority.
<img src="../assets/delivery-800.v1.png"
width="1200" height="640" fetchpriority="high"
alt="Три стадии доставки: документ, ресурсы и отображение">Фрагмент показывает только подсказку приоритета; полный responsive-вариант будет в следующем уроке. Сравните его отдельно с тем же ранним img без подсказки. Если запрос уже получает нужный приоритет или ограничение находится после доставки, итоговый эффект может оказаться небольшим. Такой результат не делает механизм неправильным: он показывает его место в данном окружении.
Preload также требует оснований. Он может помочь ресурсу, который иначе обнаруживается поздно, но для обычного img в раннем HTML сначала исследуйте необходимость. Несовпадающий URL или параметры выбора responsive-изображения способны привести к лишней загрузке. Не добавляйте одновременно несколько подсказок, пока не можете объяснить каждую полученную полосу Network.
Проверка текстового кандидата
Если LCP относится к тексту, отдельной картинки в его цепочке может не быть. Тогда исследуйте получение документа, необходимые стили, выбранный шрифт и работу до показа. Перенос подсказки приоритета на случайное изображение не ускоряет текст автоматически. После каждого изменения смотрите, остался ли кандидат прежним: увеличение заголовка или перенос схемы на первый экран способны поменять сам объект оценки.
Не скрывайте крупное содержимое на время загрузки только ради выбора меньшего кандидата. Пользователь всё равно ждёт нужную часть статьи, а цифровой результат становится менее связанным с его задачей. Важен полезный показ: заголовок, абзац и схема должны появляться в соответствии с назначением документа. Если решили изменить композицию, назовите это отдельным решением дизайна и проверьте чтение.
Новое открытие документа по URL с фрагментом может показать другую видимую область длинного урока. Такой документный переход нужно рассматривать отдельно от открытия начала статьи. Клик по якорю внутри уже открытой страницы не запускает новый LCP: взаимодействие прекращает регистрацию новых кандидатов для текущей загрузки. Сначала зафиксируйте способ открытия, затем сравнивайте одноимённые наблюдения. Правила завершения регистрации описаны в руководстве по LCP.
Сохраните запись с LCP-элементом и одной предполагаемой задержанной фазой. Затем предложите изменение и ожидаемый механизм: ранний запрос, меньше байтов или более ранняя возможность показанного кадра. Такой результат позволит отличить улучшение причинной цепочки от случайного изменения числа. В следующем уроке займёмся изображениями, сохранив именно этот подход к проверке.