LCP Slow: How to Diagnose and Fix Largest Contentful Paint Issues

LCP is defined as the render time of the largest image or text block visible in the viewport, relative to when the page first starts loading. The metric captures perceived load speed. A score is 'good' if < 2.5s, 'needs improvement' between 2.5s and 4.0s, and 'poor' above 4.0s. But the raw number hides the breakdown: TTFB, resource load delay, and render delay.

The LCP element can change during load—a new larger element may appear. Chrome DevTools now highlights the final LCP element with a green rectangle in the Performance tab. You can also run `performance.getEntriesByType('largest-contentful-paint')` in the console to see the element and its time. The key sub-phases: TTFB (time to first byte), resource load (if the LCP is an image), and element render delay (time from resource finish to paint). The element render delay is often where main-thread blocking happens.

The most common hidden cause is third-party scripts. Even `async` scripts can delay LCP if they execute during the critical path and cause layout or paint work. Use the Performance tab's 'Long Tasks' view: any task > 50ms that overlaps with the LCP timeline is suspect. Also check if the script modifies the DOM (e.g., injecting a banner) that triggers a recalculation. For fonts, `font-display: swap` is not a silver bullet—if the fallback font has a different size, the browser may re-layout when the real font loads, causing a new LCP candidate to appear (and resetting the LCP time). Always use `font-display: optional` if you want to avoid invisible text entirely, or use a fallback with similar metrics (use `size-adjust` in @font-face).

Another non-obvious cause: the LCP element is a text block that is rendered by a client-side framework after hydration. Even with SSR, if the HTML contains placeholder text that is replaced by JavaScript, the LCP may be the placeholder text that gets painted early, but then replaced by the real text—however, LCP only measures the first paint of the largest element, so if the placeholder is smaller, the real text appears later. The fix is to server-render the actual content without client-side replacement, or use streaming SSR to push the real content early.

Chrome DevTools: Performance tab > 'LCP' marker. Also enable 'Show Largest Contentful Paint' in Settings > Experiments. WebPageTest: run a test and look at the 'Largest Contentful Paint' tab—it shows the exact element and a filmstrip. For RUM, use `performanceObserver` to capture LCP entries and send them to your analytics. Example snippet: `new PerformanceObserver((list) => { for (const entry of list.getEntries()) { console.log(entry.startTime, entry.element); } }).observe({type: 'largest-contentful-paint', buffered: true});`.

For server-side debugging, measure TTFB with `curl -o /dev/null -s -w 'time_pretransfer:%{time_pretransfer} time_starttransfer:%{time_starttransfer} total:%{time_total}' https://yoursite.com`. If TTFB > 800ms, investigate backend or CDN. Also check if your CDN is caching the HTML: a miss can cause a slow origin response. Use `curl -I` to inspect cache headers like `cf-cache-status` (Cloudflare) or `x-cache` (Fastly).

For SSR apps, streaming the HTML can push the LCP element to the browser before the full page is ready. In Next.js, enable streaming with `experimental: { streaming: true }` (Next 13+) or use React 18's `renderToPipeableStream`. The key is to flush the head early, then the body containing the LCP element, while the rest of the page streams. This can cut LCP by 30-50%.

Preloading the LCP image is straightforward but often misused. Only preload the image that will be the LCP (usually the first large image above the fold). Avoid preloading multiple images—it competes with the LCP for bandwidth. Use `<link rel="preload" as="image" href="hero.webp" imagesrcset="..." imagesizes="...">` for responsive images. Also set `fetchpriority="high"` on the img tag as a hint (but preload is more reliable). For text LCP, preload the font file with `crossorigin` attribute.

Once LCP is under control, set up monitoring to catch regressions. Use Lighthouse CI in your CI/CD pipeline to fail builds if LCP exceeds a threshold (e.g., 2.5s on a simulated mobile device). For real-user monitoring, CrUX is free but has a 28-day delay. Consider a RUM tool like SpeedCurve or Datadog RUM that surfaces LCP per URL and segment (device, browser, geography). Create alerts for when the 75th percentile LCP increases by more than 10% over a 7-day period.

Also track the sub-metrics: TTFB, resource load time, and element render delay. A tool like Web Vitals Library can report these via the `attribution` build. If you see high element render delay, it's usually main-thread blocking—profile with the Performance tab and audit your JavaScript bundles. Consider code splitting and lazy loading non-critical code.