Главная страница встречает посетителя первой, и именно на ней поисковая система замеряет самую показательную метрику скорости. Largest Contentful Paint отмечает момент, когда в окне браузера полностью прорисовался самый крупный элемент видимой области, чаще всего баннер или заголовок первого экрана. Если этот момент наступает позже 2.5 секунды, метрика выпадает из зелёной зоны, а живые посетители тем временем закрывают вкладку и возвращаются в выдачу. Утешает одно: проверка занимает минуты, сервис PageSpeed Insights показывает и опыт настоящих пользователей, и подробный лабораторный разбор, а за задержкой в девяти случаях из десяти стоит одно и то же звено, главная картинка первого экрана. Ниже путь от порогов метрики до конкретных строк кода, которые возвращают главную страницу в зелёную зону отчёта.
Что измеряет Largest Contentful Paint и где проходит порог в 2.5 секунды
Метрика следит не за всей страницей, а за самым большим блоком, который виден без прокрутки. Кандидатов четыре: изображение в теге img, постер видео, фоновая картинка из CSS и крупный текстовый фрагмент. Браузер фиксирует момент полной отрисовки самого большого из них, и этот момент становится значением метрики для конкретной загрузки. На типовой главной странице победителем почти всегда оказывается баннер, потому что он физически больше заголовка и логотипа.
Границы устоялись давно: до 2.5 секунды считается хорошим результатом, от 2.5 до 4.0 секунды требует улучшений, свыше 4.0 секунд фиксируется как плохой. PageSpeed Insights красит значения в зелёный, оранжевый и красный ровно по этим порогам. В полевых отчётах значение агрегируется по 75-му перцентилю, то есть отражает опыт человека, которому повезло меньше, чем трём четвертям остальных посетителей. Именно поэтому одна быстрая загрузка в офисе ничего не доказывает.
Зачем гнаться за 2.5 секундами? Метрика входит в тройку Core Web Vitals вместе с INP и CLS, и поисковая система учитывает эти показатели при ранжировании. В лабораторном отчёте Lighthouse вес LCP равен четверти итоговой оценки производительности, ещё больше отведено суммарным блокировкам от JavaScript. Проще говоря, медленный первый экран тянет вниз и оценку отчёта, и позиции, и конверсию, потому что заметная доля мобильных посетителей не ждёт дольше трёх секунд.
Чем лабораторный тест Lighthouse отличается от полевых данных CrUX
В отчёте PageSpeed Insights живут два разных исследования, и новички часто сваливают их в одну кучу. Верхний блок собирает полевые данные CrUX: реальные посетители сайта, браузер Chrome, статистика за 28 дней, значение по 75-му перцентилю с разбивкой на мобильные и настольные устройства. Нижний блок это лабораторный тест Lighthouse: одна синтетическая загрузка в эмулированной среде, медленная сеть с пропускной способностью около 1.6 Мбит/с, четырёхкратное замедление процессора, образ среднего мобильного устройства.
Отсюда классическая сцена, знакомая многим вебмастерам. В офисе, на быстром ноутбуке и оптическом канале, тест главной страницы показывает 1.8 секунды и зелёный цвет, вроде бы можно расслабиться. А полевой блок на той же странице выдаёт 3.6 секунды и оранжевый. Оба числа правдивы, просто отвечают на разные вопросы: лаборатория показывает, как страница ведёт себя в одинаковых повторяемых условиях, поле показывает, как живут настоящие люди.
Диагностировать проблемы удобнее в лаборатории, потому что результат воспроизводим: изменили атрибут, перезапустили тест, увидели разницу. Цель же задают полевые цифры, и сверять результат нужно по ним. Если верхний блок пуст и сообщает об отсутствии данных, значит у страницы не набирается достаточно посетителей с Chrome, и ориентироваться придётся на лабораторию.
Диагностика в PageSpeed Insights от полевых цифр до раздела Diagnostics
Сама проверка проста: вставить адрес главной страницы, запустить анализ и подождать меньше минуты. Дальше отчёт читают сверху вниз. Сначала блок опыта реальных пользователей: значение LCP на мобильных устройствах и на компьютерах, цвет по порогам, рядом оценки INP и CLS. Затем лабораторная часть: оценка производительности от 0 до 100 и время каждой метрики в секундах. Самое полезное начинается ниже, в разделе Diagnostics, в русском интерфейсе он подписан как "Диагностика", и именно он раскладывает медленную отрисовку на конкретные причины.
Для медленного первого экрана раздел выдаёт типовые пункты. "Largest Contentful Paint element" показывает, какой именно узел стал самым крупным и самым медленным. "Largest Contentful Paint priority" сигнализирует, что картинке не задан высокий приоритет загрузки. "Preload Largest Contentful Paint image" предлагает заранее уведомить браузер о файле. "Avoid multiple page redirects" указывает на лишние перенаправления. "Reduce initial server response time" говорит о медленном ответе сервера. "Eliminate render-blocking resources" перечисляет стили и скрипты, задерживающие первую отрисовку. Читая эти строки по очереди, специалист получает готовый план работ на вечер.
Лабораторный отчёт раскладывает метрику на четыре последовательные фазы и показывает полосой, какая из них съела время:
- время до первого байта, работа сервера, кэша и сети до отдачи HTML;
- задержка начала загрузки ресурса, когда HTML уже получен, а запрос картинки ещё не отправлен;
- время передачи самого файла по сети;
- задержка отрисовки, когда файл уже на месте, но элемент ждёт стилей или скриптов.
Если растянута первая фаза, виноват сервер, если вторая, разметка прячет картинку от браузера, если третья, файл слишком тяжёл, если четвёртая, что-то блокирует показ уже готового изображения. Диагноз ставится за пару минут, дальше остаётся лечение.
Как найти элемент Largest Contentful Paint в отчёте и в разметке страницы
Пункт "Largest Contentful Paint element" выводит миниатюру страницы с подсвеченной областью и фрагмент HTML, обычно это тег img баннера. Полезно свериться с браузером: в DevTools на панели Performance запись загрузки отмечает маркер LCP, а рядом в разборе фаз видно, что именно растянулось, сеть, ожидание запроса или отрисовка. Такой перекрёстный опрос отчёта и браузера обычно даёт ответ за пять минут.
Дальше элемент ищут прямо в коде страницы и проверяют три вещи. Первая: картинка вставлена через тег img или подгружается фоном из CSS. Фоновые изображения браузер обнаруживает поздно, только после разбора и загрузки стилей, а это лишняя фаза ожидания на ровном месте. Вторая: не висит ли на главной картинке атрибут loading="lazy". Ленивая загрузка прекрасно работает внизу страницы и вредит в первом экране, браузер откладывает запрос и сам создаёт задержку. Третья: куда ведёт прямой адрес файла. Если при открытии картинки в отдельной вкладке адрес успевает смениться, значит стоит перенаправление, и каждое звено цепочки это лишний визит туда и обратно по сети.
Отдельно проверяют, не перепрыгнула ли метрика на текст. Если первым экраном правит крупный заголовок, а не баннер, значит картинка либо маленькая, либо отдаётся мгновенно, и внимание переключается на шрифты: сторонние файлы шрифтов без правила font-display: swap добавляют секунды ожидания. Но у большинства обычных сайтов главным героем остаётся баннер, поэтому дальше разговор о нём.
Современные форматы и разумный вес главного изображения
Первый экран почти всегда держит hero-изображение, главную картинку страницы, и типовая история с ней выглядит так: дизайнер отдал баннер в максимальном разрешении, JPEG шириной 1920 пикселей и весом 1.8 МБ, вебмастер вставил файл как есть. На эмулированной медленной сети из теста чистая передача такого объёма занимает около девяти секунд при 1.6 Мбит/с. Арифметика безжалостна, и никакие атрибуты её не отменят, пока не занялись самим файлом.
Современные форматы закрывают большую часть проблемы. WebP при равном качестве примерно на треть легче JPEG, AVIF даёт экономию до половины относительно того же JPEG. Конвертация выполняется командой из пакета libwebp:
cwebp -q 80 -resize 1600 0 hero.jpg -o hero-1600.webpПараметр -q 80 задаёт качество, которого баннеру хватает без видимой разницы, а -resize уменьшает картинку до реальной ширины показа, ведь монитор редко просит больше 1600 пикселей. Те же операции умеет ImageMagick командой magick hero.jpg -resize 1600 -quality 80 hero-1600.webp. На практике 1.8 МБ превращаются в 260-300 КБ, вариант в AVIF укладывается в 180-200 КБ, и передача по той же сети сжимается с девяти секунд до полутора. Это ещё до всяких приоритетов.
Атрибут fetchpriority, тег preload и адаптивный srcset в коде страницы
Когда файл похудел, остаётся поднять его в очереди запросов. По умолчанию браузер качает изображения с невысоким приоритетом, потому что первые слоты заняты стилями и скриптами. Атрибут fetchpriority="high" прямо говорит, что баннер важнее остальных картинок:
<img src="/hero-1600.webp" srcset="/hero-480.webp 480w, /hero-800.webp 800w, /hero-1200.webp 1200w, /hero-1600.webp 1600w"
sizes="100vw"
width="1600" height="600"
fetchpriority="high"
alt="Главный баннер каталога">Атрибут srcset перечисляет варианты файла с их шириной в пикселях, а sizes подсказывает, какую долю экрана займёт картинка. Смартфон возьмёт hero-480.webp или hero-800.webp, монитор выберет тяжёлый вариант, и никто не потащит лишние килобайты. Атрибуты width и height заставят браузер зарезервировать место заранее и не двигать макет при загрузке, это попутно улучшает метрику CLS. Высокий приоритет ставят только одному изображению на страницу: если пометить им целую галерею, очередь перепутается и выигрыша не будет.
Тег link с rel="preload" решает другой сценарий, когда баннер задан фоном через CSS:
<link rel="preload" as="image" href="/hero-1600.webp" type="image/webp" fetchpriority="high">Так браузер узнаёт о файле из первой строки HTML и не ждёт разбора стилей. Атрибут type важен при использовании тега picture: без него возможен лишний запрос запасного варианта. Ставить preload поверх обычного тега img не нужно, пользы нет, а риск лишнего обращения появляется. Для страховки на старые браузеры собирают вложенную конструкцию:
<picture>
<source type="image/avif" srcset="/hero-1200.avif">
<source type="image/webp" srcset="/hero-1200.webp">
<img src="/hero-1200.jpg" width="1200" height="500" fetchpriority="high" alt="Главный баннер">
</picture>Браузер выберет AVIF, если умеет его читать, иначе WebP, иначе возьмёт запасной JPEG. Поддержка fetchpriority давно есть во всех актуальных браузерах, включая движки Firefox и Safari, поэтому атрибут спокойно ставят на рабочие сайты.
Устранение лишних перенаправлений и медленного ответа сервера
Последний пласт причин живёт вокруг картинки и до неё. Каждое перенаправление это дополнительный визит туда и обратно по сети, на мобильном интернете он стоит от 100 до 600 мс. Типовые цепочки знакомы многим: адрес без защиты прыгает на защищённый, затем на версию с префиксом, а иногда файл проходит через скрипт пересчёта размеров, отвечающий перенаправлением. PageSpeed Insights честно перечисляет такие цепочки в отдельном пункте, остаётся убрать лишние звенья и сразу указывать конечный адрес файла.
Медленный первый байт лечится серверной частью: кэш страниц, раздача через CDN поближе к посетителю, быстрая сборка главной страницы. Разумная цель, ответ сервера меньше 500 мс, Lighthouse начинает ругаться примерно после 800 мс. Влияет и блокирующая отрисовка CSS: большие файлы с массой неиспользуемых стилей задерживают первый показ, поэтому критичные стили инлайнят прямо в HTML, а остальное грузят с отложенным исполнением.
Типичная картина до и после выглядит так. До правок: баннер 1.8 МБ в JPEG, ленивая загрузка, отдача файла через перенаправление, в лаборатории LCP 4.6 секунды, полевые мобильные данные 3.8 секунды, оценка производительности 46. После правок: WebP на 290 КБ с четырьмя вариантами в srcset, fetchpriority="high", перенаправление убрано, критичные стили в HTML: в лаборатории LCP 1.9 секунды, через месяц полевое значение 2.2 секунды, зелёный цвет и оценка 92. Полвечера работы над одним файлом и несколькими строками разметки меняют оба отчёта, а вместе с ними и поведение посетителей на главной странице.
Проверка собственной страницы занимает минуту, и с этой минуты есть смысл начать уже сегодня. Метрика не улучшится сама, зато каждый исправленный пункт из раздела Diagnostics сразу сдвигает лабораторные цифры, а через месяц обновится и полевой отчёт. Зелёная зона в 2.5 секунды достижима даже на страницах с большими баннерами, если картинка лёгкая, приоритет высокий, а сервер не тянет время.