Web Performance & Standards
What is LCP?
LCP, Largest Contentful Paint, is a Core Web Vitals metric that measures the time from when a page begins loading to when the largest content element visible in the viewport has fully rendered. LCP captures the moment at which a user perceives the main content of a page to have loaded, the point when the most visually significant piece of content becomes visible and the page feels substantially complete rather than still loading.
The name describes exactly what is measured, the paint, the rendering event, of the largest, the biggest in area, content element. When a user navigates to a page the browser progressively renders content as resources arrive, first the HTML structure, then text, then images as they download. LCP identifies which content element is the largest at any point during this progression and records when that element was fully rendered. If an image loads late and becomes the largest element its load time becomes the LCP, even if smaller elements loaded faster.
LCP is one of three Core Web Vitals, the group of metrics Google uses as direct SEO ranking signals through its Page Experience system. Of the three Core Web Vitals LCP is the most directly affected by server and network performance, and therefore the metric most impacted by redirect management decisions. Every redirect in the critical path adds TTFB overhead before the destination page begins loading, directly extending the time before the LCP element can render.
What LCP measures in detail
LCP is not simply the time until a specific element loads, it is a dynamic measurement that updates as the page loads and considers only specific types of elements as candidates.
LCP candidate elements, the browser considers four categories of elements as potential LCP candidates:
<img> elements, standalone images including responsive images using srcset and sizes attributes. The LCP time for an image element is when the image has been decoded and painted to the screen.
<image> elements inside SVG, SVG images that reference external image files.
<video> elements, using the poster image as the LCP candidate. The poster image represents the video before it begins playing, it is what the user sees while the video loads.
Elements with background images loaded via CSS url(), block-level elements where the background image from a CSS background-image property is the visually significant content.
Block-level elements containing text, paragraphs, headings, list items, divs, where the text content is the largest visual element. Text elements can be LCP candidates even without images, a page with a large heading and no images reports the heading’s render time as LCP.
Elements NOT considered for LCP:
Elements positioned outside the viewport, elements that exist in the DOM but are not visible within the initial viewport area do not count as LCP candidates.
Elements with zero opacity, invisible elements are excluded.
<svg> elements, SVG vector graphics other than those containing image references are not considered.
<video> element playback frames, only the poster image counts, not frames during video playback.
Dynamic LCP updates, LCP is reported as the time of the largest element that appeared during the page loading process, but this is determined dynamically. As loading progresses and larger elements render the LCP value updates. The browser continues tracking LCP candidates until the user interacts with the page, at which point the LCP is finalised. User interaction, scroll, click, key press, signals that the user perceives the page as loaded and finalises the LCP measurement.
A page that initially renders a large heading, making it the LCP, and then loads a hero image that is larger than the heading updates its LCP to the hero image’s render time. The final reported LCP is the largest element that rendered before the first user interaction.
LCP thresholds
Google defines three performance categories for LCP, each with specific millisecond thresholds that determine how a page is assessed in the Page Experience ranking system.
Good, under 2.5 seconds, pages with LCP under 2,500 milliseconds are considered to provide good loading performance. To achieve a good LCP assessment 75% of real user visits to the page, as measured by the Chrome User Experience Report, must have LCP under 2.5 seconds. Google recommends targeting a 2.5 second LCP as the performance goal for most pages.
Needs Improvement, 2.5 to 4.0 seconds, pages with LCP between 2,500 and 4,000 milliseconds need improvement. These pages are loading the main content slower than the good threshold, users experience a perceptible delay before seeing the primary content. Pages in this range should be prioritised for optimisation.
Poor, over 4.0 seconds, pages with LCP over 4,000 milliseconds provide poor loading performance. The main content takes so long to appear that many users abandon the page before it loads. Pages with poor LCP should be treated as high-priority performance issues.
LCP sub-parts, the loading waterfall
Google has defined four sub-parts of LCP that break down the LCP time into its contributing components, enabling targeted diagnosis of where LCP time is being spent.
Time to First Byte, TTFB, the time from navigation start to when the first byte of the HTML document arrives. TTFB is the foundational LCP component, nothing downstream can begin until the HTML arrives. TTFB encompasses DNS resolution, TCP connection, TLS handshake, server processing, and initial network transmission. A TTFB of 800ms means LCP cannot be better than 800ms regardless of how well the rest of the page is optimised.
For redirected pages TTFB includes the total time for all redirect hops plus the destination page’s own TTFB. A single redirect with 300ms TTFB followed by a destination page with 500ms TTFB results in 800ms combined TTFB, before any LCP element has even begun loading.
Resource load delay, the time between TTFB and when the browser begins loading the LCP resource, typically an image. This delay occurs when the LCP image is not discovered from the initial HTML, perhaps it is loaded as a CSS background image or defined in JavaScript, requiring the browser to parse CSS or execute JavaScript before knowing the image needs to be fetched. Minimising resource load delay means ensuring the LCP image is included in the initial HTML and discoverable immediately.
Resource load time, the time to download the LCP resource after the browser begins fetching it. For image LCP elements this is the image download time, affected by image file size and the bandwidth and latency of the connection to the image server. A 500KB JPEG image takes significantly longer to download than a 50KB WebP image at the same quality, aggressive image compression directly reduces resource load time.
Element render delay, the time between when the LCP resource has finished loading and when it is actually painted to the screen. Render delay occurs when the main thread is blocked by JavaScript execution, preventing the browser from rendering the LCP element even though the resource has arrived. Minimising long JavaScript tasks reduces render delay.
What causes poor LCP
Poor LCP stems from problems in any of the four sub-parts, diagnosing which sub-part is contributing most guides appropriate optimisation.
Slow server response, high TTFB, the most fundamental LCP problem. If TTFB is high all downstream metrics are delayed. Causes:
Slow origin server processing, inefficient database queries, heavy application logic, resource-intensive server-side operations. No CDN deployment, serving all users from a single origin location means distant users experience high network latency in TTFB. Redirect chains, multiple redirect hops before the destination page each adding their own TTFB.
Render-blocking resources, CSS and synchronous JavaScript that must be downloaded and processed before the browser can render any content. The browser cannot begin painting the LCP element until all render-blocking resources in the <head> have been processed. Render-blocking resources extend the time between HTML receipt and LCP element rendering.
Slow LCP resource, a large unoptimised image that takes several seconds to download. If the LCP element is a 2MB unoptimised JPEG hero image the image download time dominates LCP. Converting to WebP, typically 25-35% smaller at equivalent quality, reducing dimensions to match display requirements, and serving from a CDN edge location near the user all reduce LCP resource load time.
Late LCP resource discovery, the LCP image not being discoverable from the initial HTML, being loaded via JavaScript or CSS background images, means the browser must complete additional processing steps before it knows to fetch the LCP resource. The browser cannot prioritise fetching a resource it does not yet know about.
Main thread blocking JavaScript, heavy JavaScript execution that prevents the browser from rendering the LCP element even after its resource has arrived. JavaScript that runs long tasks on the main thread delays all rendering, including the LCP paint.
LCP and redirects
Redirects are one of the most direct and significant causes of LCP degradation, each redirect adds to the TTFB sub-part of LCP.
The redirect TTFB chain, when a user navigates to a URL that redirects the browser must:
Connect to the redirect source URL. Receive the redirect response, adding the redirect’s TTFB to the total. Connect to the redirect destination, potentially requiring new DNS, TCP, and TLS steps. Receive the destination page’s first byte, adding the destination’s TTFB.
The combined TTFB before any LCP element begins loading is the sum of all redirect TTFBs plus the destination TTFB. This sum must be under 800ms for LCP to have a realistic chance of achieving the 2.5 second good threshold, leaving only 1.7 seconds for resource loading, rendering, and everything else.
Cross-origin redirect TTFB costs, redirects that change the domain, common in brand protection domain redirects, affiliate redirect chains, and domain migration transitions, incur the full connection establishment overhead for each new domain. On a connection with 100ms round-trip time a cross-origin redirect adds approximately 350ms of TTFB, 50ms DNS + 150ms TCP + 100ms TLS 1.3 + 50ms server processing and first byte arrival. Two cross-origin redirects add 700ms, nearly the entire 800ms TTFB budget for good LCP.
Edge redirect execution for LCP preservation, redirect management platforms that execute redirect rules at edge nodes near users dramatically reduce redirect TTFB. An edge node 20ms from the user processes a redirect rule and returns a response in approximately 20-30ms total, compared to 300-400ms for an origin-executed redirect from the same user’s perspective. For pages with LCP near the 2.5 second threshold the difference between edge and origin redirect execution can determine whether the page achieves good or needs improvement status.
Eliminating unnecessary redirects, the most impactful LCP optimisation for redirected pages. A redirect that exists because internal links were not updated when URLs changed, adding a redirect hop that the browser navigates through unnecessarily, should be eliminated by updating internal links to point directly to canonical URLs. Each eliminated redirect hop removes its TTFB from the LCP calculation entirely.
Improving LCP
LCP improvement strategies address each sub-part, the appropriate strategy depends on which sub-part is contributing most to poor LCP.
Reduce TTFB, the highest-impact LCP improvement. Deploy CDN infrastructure, serving HTML from edge locations near users reduces TTFB from user-to-origin distance to user-to-edge distance. Eliminate unnecessary redirect chains, each eliminated redirect hop saves its TTFB from the LCP calculation. Implement server-side caching, cached responses have near-zero processing time. Use edge computing, dynamic logic executed at edge nodes achieves CDN-level TTFB.
Preload the LCP image, adding <link rel="preload"> for the LCP image in the HTML <head> instructs the browser to fetch the image as early as possible, before it is discovered through normal parsing:
The fetchpriority="high" attribute further signals to the browser that this resource should be fetched with maximum priority. Preloading the LCP image directly reduces resource load delay, the browser begins fetching the image immediately rather than waiting to discover it through parsing.
Optimise LCP image, compress the LCP image aggressively, targeting the smallest file size that maintains acceptable visual quality. Use WebP or AVIF format rather than JPEG or PNG, modern formats achieve better compression at equivalent quality. Serve the LCP image from a CDN edge location near the user, reducing the download time by minimising network distance.
Eliminate render-blocking resources, inline critical CSS needed for above-the-fold rendering, removing the need to download an external stylesheet before rendering begins. Defer non-critical CSS loading. Ensure JavaScript in the <head> uses async or defer attributes, preventing synchronous JavaScript from blocking HTML parsing and rendering.