Slow LCP: how to find the responsible element and fix the critical chain

Executive brief

Key takeaways

• The LCP element can change across devices and visits.
• Break down the time before choosing a fix.
• Discover the resource early and prioritize only the correct candidate.
• Do not lazy-load the above-the-fold element that determines LCP.

Largest Contentful Paint measures when the largest visible content element finishes rendering. Fixing it requires more than “optimizing images”: identify the measured element and determine where time is spent.

The recommended threshold is 2.5 seconds at the 75th percentile. Use field and lab data together: field confirms reach, and the lab exposes the critical chain.

Identify the LCP element

The candidate may be a hero image, carousel image, video poster, text block, supported background image or another large element in the initial viewport.

It can change between mobile and desktop because layout, cropping, text and resources differ. It can also change because of an experiment, consent state, personalization or loading failure.

Use Chrome Performance, PageSpeed Insights or web-vitals attribution to record the element and resource URL. Do not assume the visually dominant image was the measured candidate.

Break down LCP time

Time to First Byte

This includes navigation, connection, server processing and the start of the document response. If HTML arrives late, every resource discovered from it also starts late.

Investigate redirects, caching, slow server rendering, blocking data queries, geographic distance, cold starts and middleware overhead.

Resource discovery delay

This is the interval between receiving HTML and discovering the LCP resource. Delay grows when an image is inserted by JavaScript, depends on a hydrated carousel, appears in late CSS or waits for a client API call.

The best case places the main candidate directly in initial HTML.

Transfer duration

After discovery, the resource must download. File weight, format, dimensions, cache, CDN and connection affect this stage.

Render delay

The file can be available but remain invisible because CSS, fonts, JavaScript or main-thread work blocks paint. Further image compression solves only a small part in that case.

Improve the document before accelerating the resource

High TTFB moves the whole cascade. Before adding preloads, consider eliminating entry redirects, caching pages or data, serving static content when appropriate, using a CDN, parallelizing independent data work and deferring tasks not required for initial HTML.

Measure effects on freshness and personalization. Incorrect cache rules can serve stale or private information.

Help the browser discover the candidate early

Render the first hero image in HTML and use srcset and sizes:

<img
  src="/hero-1280.webp"
  srcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
  sizes="100vw"
  width="1280"
  height="720"
  alt="A prioritized website diagnosis"
  fetchpriority="high"
>

fetchpriority="high" can signal importance, but only use it on the likely candidate. Giving many images high priority removes the distinction.

For resources discovered through CSS or another late path, preload may help. Confirm in the waterfall that it starts the request earlier and does not cause a duplicate download.

Do not lazy-load above-the-fold LCP

loading="lazy" defers resources near or outside the viewport. On the visible LCP candidate, that delay is usually counterproductive.

Keep lazy-loading for below-the-fold media. Test responsive variations: an image below the fold on desktop may become the mobile LCP.

Serve the right file

Generate dimensions close to the rendered space, use modern formats supported by the project, compress with visual review, avoid downloading a desktop image on small screens, configure long-lived caching for versioned files and remove unnecessary metadata.

The goal is not the smallest possible file but an appropriate balance of quality, decoding cost and transfer.

Remove rendering blockers

When the candidate is text, fonts and CSS matter. Deliver critical styles early, avoid huge blocking stylesheets and review font strategy.

If JavaScript occupies the main thread when the resource is ready, reduce initial work: render content on the server, split non-critical components, defer third parties, avoid hydrating static areas and reduce startup effects that recalculate layout.

Treat carousels carefully

Carousels often hide the first image behind JavaScript and load every slide with similar priority. A more robust implementation renders the first slide in HTML, prioritizes only its image, reserves dimensions, loads later slides at lower priority, preserves accessible controls and does not automatically replace the candidate before loading stabilizes.

Consider whether the carousel is necessary. One clear primary message is often simpler for performance and communication.

Validate the fix

Repeat tests under comparable conditions and record the LCP element, resource URL, TTFB, request timing, render moment, transferred bytes and long tasks near paint.

Test multiple pages from the template, not only the best case. Then monitor field and business data without assuming immediate causation.

Observation: on mobile, the main product image is LCP and downloads only after carousel hydration. Action: render the first slide on the server with srcset, dimensions and high priority; load later slides on demand. Acceptance: the correct image appears without JavaScript, no duplicate download occurs and median lab LCP improves across five runs.

Slow LCP is a chain, not a file. Breaking the time down makes the recommendation target the component that actually dominates the experience.

Direct answers

Frequently asked questions

What is a good LCP?

The current Core Web Vitals recommendation is LCP of 2.5 seconds or less at the 75th percentile, separated between mobile and desktop.

Does preload always improve LCP?

No. It helps when the critical resource would otherwise be discovered late. Too many preloads compete for bandwidth and can harm other requests.

Does compressing an image solve LCP?

Only when transfer time is a meaningful part of the delay. High TTFB, late discovery, blocking CSS or client rendering may still dominate.