Largest Contentful Paint

Largest Contentful Paint (LCP) is the moment the biggest visible element on your page finishes rendering. It is not the time when everything is ready – that is the point I keep having to explain to clients. What matters is that users perceive a page as usable when the main content appears, not when every ad or footer script loads. Google chose LCP because it correlates with that perception. The official threshold is 2.5 seconds or less at the 75th percentile of page loads, segmented by device. That 75th percentile bit is crucial: a page that loads instantly nine times but takes five seconds one time still fails under field measurement.

Take a concrete example. I worked on a product page where the LCP element was a 1.2 MB hero image. The server response was fast (0.4 seconds), but the image was served as a JPEG without optimisation. After resizing, compressing, and switching to WebP, the same element rendered at 1.1 seconds. The other components – a heading and a text block – loaded at the same time, so the LCP improved by 1.2 seconds without touching anything else. That is the kind of win you get when you identify the right element first.

I am wary of people who treat LCP as a holistic loading score. It is a specific, measurable point. If your largest element is a late-loading video poster or a banner image below the fold (rare but possible), optimising elsewhere does nothing. You have to isolate the element and the reason for its delay: slow server, render-blocking CSS, or unoptimised assets.

LCP matters most on pages where the user expects to see the main content immediately. That includes [core web vitals](/core-web-vitals/) evaluation in Search Console, but real-world impact goes beyond rankings. For a news article, the headline and lead image are the LCP candidate. If those appear late, the user may bounce before reading a word. For an [e-commerce](/mobile-seo/) product page, the hero image is often the LCP element. A one-second delay there can drop conversion rates by measurable percentages – I have seen the data from A/B tests.

Mobile users punish slow LCP more aggressively. On a 3G connection, a page that passes lab tests with a 1.8 second LCP might field-test at 4.5 seconds because of network variation. That is why I always check the mobile field data first. If your site serves a heavy desktop-sized hero image to mobile devices, that is an immediate LCP killer.

There is a counter-argument that LCP does not matter for pages with no large images: a text-heavy blog post with a small header image might have an LCP element that is just a block of text. In that case, the bottleneck is often render-blocking CSS or JavaScript. I had a site where the LCP was a paragraph of body text. The issue was a custom web font that loaded late with a flash of invisible text. Changing to font-display: swap and preloading the font cut the LCP from 3.2 to 1.6 seconds.

Decision rule: if the LCP element is an image, optimise the image and its loading. If it is text, audit your font loading, CSS delivery, and server response. And if your page has both a big hero and heavy text, fix the image first – it is almost always the shorter path to improved LCP. Do not forget to check for third-party scripts that block rendering; I once found a slow analytics script that pushed LCP by 0.8 seconds on every page.

I used to assume LCP was just about the hero image. It is not. I have seen cases where the largest element is a video poster, a background image, or even a large heading rendered with a custom font. The first time I diagnosed a slow LCP and found it was a block of text, I felt stupid. Since then, I always inspect the actual LCP element in Lighthouse or PageSpeed Insights before proposing a fix.

Another mistake: I tested only on my fast home connection and declared the page good. Field data from CrUX told a different story. Users on slower networks saw LCP values twice as high. Now I rely on the 75th percentile of real-user data, not a single lab run. I also check across multiple URLs – one page passing does not mean the whole site is safe.

I also fell for the myth that reducing image file size alone fixes LCP. It helps, but server response time (TTFB) can be the dominant factor. I had a site where images were tiny and fast, yet LCP sat at 3.8 seconds. The problem was a slow database query that delayed the first byte by 1.5 seconds. Optimising the backend cut TTFB to 0.3 seconds and LCP dropped to 1.9 seconds. Now I always check TTFB before touching images.

Finally, I used to think improving LCP required a full redesign. Wrong. Sometimes it is as simple as removing a render-blocking script or adding loading="eager" to the hero image. The single most effective change I ever made was moving the hero image from a background CSS image to an inline <img> with explicit dimensions – it went from 4.1 to 2.0 seconds. That is the kind of tactical fix that makes me question every generic performance audit I see.

I keep [Technical SEO Audit Service](/technical-seo-audit-service/) and [Performance Optimisation](/performance-optimization/) open alongside this one.