Guides

LCP, short for Largest Contentful Paint, is one of Google's Core Web Vitals, the metrics Google uses to score real-world page experience. It measures loading performance: the time from when the page starts loading to when the largest content element visible in the viewport is rendered. In plain terms, it is the moment your main content actually shows up on screen.

The element LCP looks at is whatever is largest in the initial viewport as the page loads. Most of the time that is the hero image, a large block of text, a video's poster frame, or a big background image. Google measures when that specific element finishes painting, because that is the point where the page feels loaded to a real person rather than blank or half-drawn.

Google's thresholds are clear. An LCP of 2.5 seconds or less is Good, between 2.5 and 4 seconds Needs improvement, and over 4 seconds is Poor. Like the other Core Web Vitals, LCP is judged on field data at the 75th percentile of real page loads, so it reflects what most of your visitors actually experience, not a single lab run on a fast connection.

LCP matters because it maps closely to how quickly a page feels usable. A slow LCP means visitors stare at an empty or incomplete screen while the main content crawls in, which drives people away. It is also part of the Core Web Vitals that feed into Google's page experience signals, so a poor LCP can hold back both users and rankings.

It helps to see LCP as four parts stacked end to end: time to first byte (how fast the server responds), resource load delay (how long before the browser even starts fetching the LCP element), resource load time (how long that element takes to download), and element render delay (how long before it is actually painted). A slow LCP is almost always one or two of these parts dominating, so fixing it starts with finding which part is the problem.

The first chunk, time to first byte, is about your server and delivery. A slow or distant host adds delay before anything can load, so a fast, well-located host and a CDN that serves content from near your visitors cut this part down directly. This is the least glamorous fix but often the most impactful, because every millisecond here delays everything after it.

The LCP element itself, usually an image, is the next big lever. Serve it in a modern format like WebP or AVIF, size it correctly for the layout instead of shipping a huge original, and tell the browser it is important with preload or a high fetch priority so it starts downloading early. One very common mistake is lazy-loading the hero image: lazy-loading is great for below-the-fold images, but applying it to the LCP element delays exactly the thing you are being measured on.

Render-blocking resources are the last common culprit. Large blocking CSS and JavaScript files make the browser wait before it can paint anything, including your largest element. Trimming unused CSS, deferring non-critical JavaScript, and inlining only the critical styles let the browser reach the paint sooner.

To improve an LCP score in practice: measure it with a field-data tool to see the real 75th-percentile number, identify which of the four parts is largest, then attack that part - a faster host or CDN for a slow server, image optimisation and preloading for a slow resource, and less render-blocking code for a slow paint. Re-measure with real data, since a lab score on a fast machine can look fine while real users on slower connections struggle.

The bottom line: Largest Contentful Paint measures when your main content becomes visible, and Google wants it at 2.5 seconds or less. Get there by serving fast from a good host and CDN, optimising and prioritising the largest element instead of lazy-loading it, and clearing render-blocking code out of the way. Do that and the page does not just score better - it genuinely feels faster to the people using it.