Largest Contentful Paint What LCP measures, the four parts that make up the value and where large websites lose time
Largest Contentful Paint measures when the main content of a page is visible. It is the most common reason a page fails the Core Web Vitals: in Christian Schreiber's own survey, 55.9 percent of failing websites on Adobe Experience Manager miss exactly this metric. It is also the value that can be broken down most thoroughly, and that breakdown is the path to the cause.
Threshold: 2.5 seconds at the 75th percentileOwn data: as of August 2026
The LCP element: image, video poster or text block in the viewport
The browser continuously determines the largest element by area in the viewport and reports the time at which it was rendered. Candidates are images, video posters, background images and text blocks. The value is updated until the user's first input, and the element reported last is the one that counts.
In practice, it is usually the hero image on homepages, the first teaser on overview pages and the headline or lead image on article pages. In the survey, 1.9 percent of websites have a good First Contentful Paint but miss Largest Contentful Paint. On these websites, the page frame appears early and the main content arrives late.
The four parts of the LCP value determine the fix
Every value breaks down into four parts, and their distribution determines the measure.
- Server response time. The time until the first byte of the document. It is the lower bound for everything that follows and is covered on the Time to First Byte page.
- Resource load delay. The time between the arrival of the document and the moment the browser requests the decisive resource. It grows with render-blocking stylesheets, with images that are only set by a script and with lazy loading applied to the wrong element.
- Resource load duration. The pure transfer time of the resource, determined by file size, format and delivery path.
- Element render delay. The span between finished loading and visible rendering, usually caused by scripts that occupy the main thread or by fonts that hold up the rendering of text.
Lab tools provide this breakdown per page. For images as the LCP element, the Chrome User Experience Report has also provided it as field data per origin and URL since February 2025. Without it, optimization starts with the images, even when the bottleneck lies in the first part. The tools that show the breakdown are listed under Measuring Core Web Vitals.
Large platforms lose most LCP time before the first byte
For 80.3 percent of the slow AEM websites and 78.8 percent of the Magnolia websites, the server response time alone already exceeds the threshold. Frequent causes lie in the cache layer: misses caused by parameters, overly coarse invalidation, sessions for anonymous visitors. Redirects and connection setup add to this. As long as this share does not drop, frontend measures have little room.
If the response time is good and the value is still poor, the loading order is the cause. The three recurring patterns: the decisive image is lazy loaded, it is only inserted by a script, or a stylesheet blocks rendering until it has fully loaded. The first two and the stylesheet can usually be fixed without a major rebuild; an image inserted by a script often requires a change to rendering.
Improve LCP: measures in order of impact
- Reduce the server response time, that is, measure and raise the cache hit ratio per page type.
- Load the image in the visible area with high priority and never lazy load it.
- Resolve render-blocking stylesheets and deliver the part needed for the visible area first.
- Deliver image variants in suitable widths and modern formats instead of scaling an original image.
- Load fonts so that text is visible immediately instead of waiting for the font.
This order applies regardless of the system in use. The system-specific details are on the pages on Adobe Experience Manager Performance and Magnolia CMS Performance. How loading phases and rendering strategy determine the main content is shown in AEM Edge Delivery Services and Magnolia Headless.
LCP in the field: AEM and Magnolia websites in the DACH region
In the DACH region, 80.5 percent of AEM websites and 77.7 percent of Magnolia websites are in the green range on mobile, and 4.7 and 0.7 percent respectively are in the red range. The full distribution with datasets you can recalculate is in the AEM Core Web Vitals Benchmark and the Magnolia CMS Core Web Vitals Benchmark.
Book a free performance analysis
30 minutes via video call. You see which of the four parts is decisive for your pages.
Frequently asked questions about Largest Contentful Paint
What is the difference between First Contentful Paint and Largest Contentful Paint?
First Contentful Paint measures when any content appears, Largest Contentful Paint measures when the largest visible content is complete. Only the second value is one of the Core Web Vitals. Both are slowed down first by the same causes: a late server response and render-blocking stylesheets or fonts. Improving First Contentful Paint therefore usually improves Largest Contentful Paint as well.
What does Largest Contentful Paint measure?
The point in time at which the largest visible element in the viewport has finished rendering, counted from the start of the page load. Usually this is a hero image, a background image or a large text block. Good is 2.5 seconds at the 75th percentile, poor is anything above 4 seconds.
What parts does the value consist of?
Four parts: the server response time, the delay until the resource starts loading, its load duration and the time until rendering. Without this breakdown, every measure is guesswork. If the largest share lies in the first part, no image format in the world will help.
How high may the server response time be?
Google gives 800 milliseconds as a guideline for Time to First Byte. In Christian Schreiber's own survey, the median across all AEM websites is 666 milliseconds, while for the slow websites whose response time exceeds the threshold it is 1,565 milliseconds. The difference shows how much time passes there before the first byte.
Does lazy loading help against poor values?
For everything below the visible area, yes. For the image that determines the value, no. A lazy-loaded hero image worsens the main content load time, because the browser only learns after layout that it needs the image. This one image should be loaded with high priority, all others lazily.
Why is the value worse on mobile devices?
Because of slower connections, weaker devices and often larger images relative to the screen area. In Christian Schreiber's own survey, the mobile median is 1,874 milliseconds compared to 1,446 milliseconds on desktop.