Показатель Core Web Vitals, измеряющий, как быстро основной контент страницы становится видимым.
Определение
LCP (Largest Contentful Paint) — это метрика [Core Web Vitals](/glossary/core-web-vitals), которая измеряет время от начала загрузки страницы до завершения рендеринга самого большого видимого элемента контента в области просмотра. Этот элемент обычно представляет собой hero-изображение, большой текстовый блок, постер видео или фоновое изображение. Google определяет три диапазона производительности: **хорошо** (2,5 секунды или менее), **требует улучшения** (от 2,5 до 4,0 секунд) и **плохо** (более 4,0 секунд). LCP измеряется на 75-м перцентиле загрузок страниц, что означает, что показатель отражает опыт большинства реальных пользователей, а не только самых быстрых соединений.
Почему это важно
LCP — это самый важный показатель воспринимаемой скорости загрузки страницы. В то время как другие метрики измеряют техническую готовность или визуальную стабильность, LCP фиксирует момент, когда посетитель видит основной контент — момент, когда он решает, что страница «загрузилась». Медленный LCP заставляет посетителей смотреть на незавершённую страницу, увеличивая показатель отказов и снижая вовлечённость. Google использует LCP как сигнал ранжирования в своём поисковом алгоритме, а это значит, что плохой показатель не просто ухудшает пользовательский опыт — он напрямую снижает органическую видимость. Для издателей, зависящих от поискового трафика, оптимизация LCP может определять разницу между попаданием на первую страницу и полной невидимостью.
Как это работает в FlipLink
FlipLink оптимизирует LCP как для маркетингового сайта, так и для опубликованных флипбуков. Просмотрщик флипбуков приоритизирует рендеринг обложки и первого разворота, обеспечивая появление самого большого видимого элемента контента до загрузки тяжёлых ресурсов. [Пользовательский экран загрузки](/features/custom-loading-screen) обеспечивает мгновенную визуальную обратную связь — брендированный заполнитель, появляющийся менее чем за секунду — пока ресурсы рендеринга [Three.js](/glossary/three-js) инициализируются в фоне. Движок [опыта и макета страницы](/features/page-experience-and-layout) FlipLink применяет оптимизированное сжатие изображений, адаптивное масштабирование и прогрессивный рендеринг для удержания LCP в пределах рекомендованного Google порога 2,5 секунды на десктопе и мобильных устройствах. Когда флипбуки [встраиваются](/glossary/embed) на внешние сайты, ленивая загрузка гарантирует, что встройка не конкурирует с LCP-элементом хост-страницы.
Ключевые метрики
Понимание LCP требует контекста наряду с сопутствующими метриками производительности:
- **Хороший LCP**: 2,5 секунды или менее. Страница ощущается мгновенной. Большинство пользователей видят контент до того, как подумают об уходе.
- **Требует улучшения**: от 2,5 до 4,0 секунд. Пользователи замечают задержку. Показатель отказов начинает расти.
- **Плохой LCP**: более 4,0 секунд. Посетители с высокой вероятностью покинут страницу до появления основного контента.
LCP-элемент меняется в зависимости от страницы. На странице товара это обычно изображение товара. В блог-посте это может быть hero-баннер или первый абзац текста. На странице флипбука — изображение обложки. Определение элемента, составляющего LCP на каждой странице, — первый шаг к оптимизации.
Технические детали
Измерение LCP следует конкретным правилам, определённым Web Performance Working Group. Самый большой элемент определяется по его видимому размеру в области просмотра, а не по размеру файла. Элементы, учитываемые для LCP, включают элементы `<img>`, `<image>` внутри SVG, постер-изображения видео, элементы с `background-image`, загруженным через CSS, и блочные элементы, содержащие текст. Элементы, выходящие за пределы области просмотра, измеряются только по их видимой части.
Распространённые причины медленного LCP включают неоптимизированные изображения (доставка фото 4 МБ, когда WebP на 200 КБ было бы достаточно), CSS и JavaScript, блокирующие рендеринг, медленное время ответа сервера ([TTFB](/glossary/core-web-vitals) более 800 мс) и клиентский рендеринг, требующий выполнения JavaScript до появления контента.
Практические оптимизации включают: предзагрузку LCP-изображения с помощью `<link rel="preload">`, доставку изображений в современных форматах (WebP, AVIF), использование CDN для статических ресурсов, инлайн критического CSS, отложенную загрузку несущественного JavaScript и установку явных `width` и `height` для изображений для предотвращения сдвигов макета, которые могут задержать LCP.
LCP против FCP
LCP и [FCP](/glossary/core-web-vitals) (First Contentful Paint) — обе метрики времени, но измеряют разные моменты. FCP срабатывает, когда браузер рендерит первый фрагмент DOM-контента — даже если это лишь панель навигации, индикатор загрузки или одна строка текста. LCP срабатывает, когда рендерится самый большой элемент контента. На практике FCP часто срабатывает на одну-две секунды раньше LCP.
Страница может иметь быстрый FCP, но медленный LCP, если шапка и навигация загружаются быстро, а hero-изображение появляется через несколько секунд. Для пользовательского опыта LCP — более значимая метрика, потому что она отражает момент, когда страница ощущается завершённой для посетителя. FCP полезен для диагностики того, начал ли браузер рендеринг вообще, но именно LCP определяет, останется ли пользователь или уйдёт.
Ключевой вывод
LCP измеряет момент, когда ваша страница ощущается загруженной для реальных посетителей. Удерживайте его ниже 2,5 секунд, оптимизируя изображения, минимизируя ресурсы, блокирующие рендеринг, и приоритизируя контент выше линии сгиба — от этого зависят ваши позиции в поиске и вовлечённость пользователей.