Измерение Core/Dash: Urls
Изолируйте и устраните узкие места производительности Core Web Vitals по конкретным Urls
Trusted by market leaders
Измерение: Страница и Навигация: URLs (u)
Измерение Element Type (LCP) (lcpet) классифицирует узел Largest Contentful Paint по одному из четырех архитектурных классов: text, image, background-image или video.
В то время как измерение Attribution Element точно указывает на конкретный узел DOM, измерение Element Type определяет вашу высокоуровневую инженерную стратегию. LCP представляет собой сумму четырех временных интервалов: TTFB, Load Delay, Load Time и Render Delay. Element Type сообщает, какой из этих интервалов ухудшает вашу оценку, позволяя выбрать правильный протокол оптимизации без гадания.
Оптимизация Core Web Vitals по типу элемента LCP
После улучшения TTFB, который не зависит от типа элемента LCP, вам следует применить другой подход к оптимизации LCP, обратив внимание на различные элементы LCP.
1. Text
Когда CoreDash сообщает о типе элемента text, пропускная способность статических сетевых ресурсов редко является узким местом. Текст находится непосредственно в документе HTML, что означает доступность контента сразу после первоначального ответа сервера (TTFB). Если ваш LCP здесь медленный, проблема почти исключительно заключается в Render Delay.
Чтобы исправить это, полностью сосредоточьтесь на Critical Rendering Path. Браузер, вероятно, заблокирован от отрисовки текста тяжелыми вычислениями CSS или синхронным JavaScript в <head>. Кроме того, проверьте стратегию загрузки шрифтов; если вы не используете font-display: swap или optional, браузер искусственно скрывает текст (FOIT) в ожидании загрузки файла шрифта.
2. Image (<img>)
Этот тип запускает полный конвейер ресурсов: обнаружение, загрузку и декодирование. В отличие от текста, LCP изображения сильно зависит от Load Delay и Load Time. Здесь вы боретесь с физикой и задержкой сети, поэтому ваша цель — сделать ресурс легче и доступным для обнаружения как можно раньше.
Оптимизация здесь требует строгого управления ресурсами. Убедитесь, что тег <img> существует в исходном коде HTML (Server-Side Rendering), чтобы минимизировать Load Delay. Добавьте fetchpriority="high" и строго удалите любые атрибуты loading="lazy", так как они задерживают запрос браузера. Наконец, займитесь Load Time, предоставляя форматы следующего поколения (AVIF/WebP) и используя srcset, чтобы предотвратить загрузку файлов десктопного размера на мобильные устройства.
3. Background Image
Эта классификация сигнализирует об архитектурной неэффективности. Поскольку изображение определено в CSS (например, background-image: url(...)), браузер не может обнаружить URL до тех пор, пока полностью не загрузит и не проанализирует ваши таблицы стилей. Это создает огромный Load Delay, поскольку Preload Scanner фактически не видит этот ресурс.
Единственное надежное инженерное решение — рефакторинг. Переместите визуальный ресурс из CSS в стандартный тег HTML <img>, чтобы немедленно открыть URL браузеру. Если вы не можете рефакторить разметку, вы должны использовать <link rel="preload"> в заголовке документа, чтобы принудительно запустить раннее обнаружение, хотя это часто является бременем поддержки по сравнению с использованием нативного элемента изображения.
4. Video
Когда элементом LCP является видео, браузер измеряет время отрисовки изображения-постера или первого кадра (если включено автовоспроизведение). Это ведет себя аналогично типу Image, но часто тяжелее из-за размера файла видеоресурсов.
Рассматривайте это строго как задачу оптимизации изображения. Убедитесь, что в HTML присутствует легкий атрибут poster, чтобы браузеру не приходилось загружать сегменты видео для рендеринга первого пикселя. Сжимайте изображение-постер так же агрессивно, как и стандартное изображение LCP.
Рабочий процесс: поиск проблем LCP на основе типа элемента LCP
Тип элемента LCP не является статичным и одинаковым для каждого посетителя. Он часто меняется в зависимости от устройства пользователя, выявляя фундаментальные недостатки адаптивного дизайна.
Используйте фильтр CoreDash Device Form Factor для сравнения типов элементов между Mobile и Desktop. Вы часто обнаружите, что пользователи Desktop получают LCP типа image (например, Hero Banner), в то время как пользователи Mobile получают LCP типа text. Это подтверждает, что ваш мобильный макет CSS смещает Hero Banner ниже линии сгиба или уменьшает его настолько значительно, что абзац текста становится "Самым большим" ("Largest") элементом.
Если вы оптимизируете hero-изображение для улучшения мобильного LCP в этом сценарии, вы тратите усилия впустую. Браузер даже не учитывает это изображение. Вы должны либо скорректировать макет, чтобы вернуть изображение в основной вид, либо переключить внимание на оптимизацию рендеринга текста (шрифты/CSS) для мобильных пользователей.
