LCP (Largest Contentful Paint)

The browser identifies the largest element rendered in the initial viewport — images, `<video>` poster frames, background images set via CSS on visible elements, and blocks of text are all eligible; elements that render off-screen or later than the initial viewport-relevant paint don't count.

LCP timing is measured from navigation start and includes everything that happens before that element can paint: DNS lookup, connection setup, server response time, resource download, and any render-blocking resources (unoptimised CSS, synchronous JavaScript) that delay the browser from getting to that paint at all.

As organic click volume becomes scarcer and more concentrated on high-intent commercial and local queries due to AI Overviews absorbing informational search, every click that does land carries more relative business value — and a slow first paint is one of the most reliable predictors of an immediate bounce before a visitor ever sees a page's actual content or offer.

Start with field data — Search Console's Core Web Vitals report or the CrUX dashboard — to confirm the failure and identify which URL groups are affected, since a single-page Lighthouse test can look fine while real users on slower connections or devices experience a genuine failure.

Use PageSpeed Insights or Chrome DevTools' Performance panel to break down the LCP timing into its sub-phases: Time to First Byte, resource load delay, resource load time, and render delay, which together identify exactly where the time is being lost.

Unoptimised hero images — oversized files, outdated formats like uncompressed JPEG or PNG instead of AVIF/WebP, and no responsive `srcset` — are the single most common cause on content-heavy and local service sites.

Slow server response time, often from shared or under-provisioned hosting, unoptimised database queries, or no server-side caching, adds directly to LCP before any client-side work even begins.

Render-blocking CSS and synchronous JavaScript loaded in the document head before the LCP element can paint are a frequent secondary cause, particularly on sites built on heavier CMS themes or page builders.

Compress and correctly size the hero image or LCP element, serve it in AVIF or WebP via a CDN, and add `fetchpriority="high"` plus a `<link rel="preload">` hint so the browser fetches it as early as possible.

Improve Time to First Byte: enable server-side caching, use a CDN for edge delivery, and audit slow database queries or unnecessary server-side rendering work on the critical path.

Eliminate or defer render-blocking CSS and JavaScript above the LCP element — inline critical CSS, defer non-critical stylesheets, and load non-essential scripts with `defer` or `async`.

Where the LCP element is rendered client-side (common in React-heavy sites), ensure it can render from server-side or statically-generated HTML rather than waiting on a full client-side hydration cycle.

Re-measure using field data over a 28-day CrUX window to confirm the fix moved the actual p75 figure, not just a single lab test.

Local service sites frequently lead with a large, unoptimised hero photo of a completed project or team — visually valuable but often the single biggest LCP cost on the homepage. Serving that image via a CDN in a modern format with proper sizing is usually the highest-leverage single fix available, ahead of any hosting migration or framework change.

LCP, INP, and CLS together form Core Web Vitals, each covering a distinct dimension of page experience, and a fix for one does not automatically fix the others. LCP is also the metric most sensitive to hosting and CDN choices specifically, since server response time is a direct, unavoidable component of its timing.