Lesson 6 of 1714 minIntermediate

Core Web Vitals and Page Speed

Lcp Diagnosing and Fixing Largest Contentful Paint

Break LCP into its sub-parts and apply the fix that matches which sub-part is actually slow.

Reading time · unlocks the next lesson

0:00 / 5:00 · paused

The four sub-parts of LCP

LCP time is the sum of Time to First Byte (TTFB), resource load delay, resource load time, and element render delay. Diagnosing which sub-part dominates tells you exactly where to focus: a slow TTFB points to server or hosting issues, while a long resource load delay usually means the LCP image is discovered late in the HTML or blocked behind other requests.

Fixing a slow TTFB

Common causes are uncached server-side rendering, slow database queries, or a distant origin server with no CDN. Fixes include enabling full-page or fragment caching, moving to edge-rendered or static generation for content that does not need to be dynamic per request, and serving through a CDN with points of presence near your audience.

Fixing late discovery and slow loading of the LCP element

If the LCP element is a background CSS image, it will not be discovered until the CSS is parsed; using an <img> tag or a preload hint fixes this. Lazy-loading the LCP image itself is a frequent mistake since it deliberately delays what should load first. Preload the LCP image with <link rel='preload' as='image'> and serve it in a modern compressed format such as WebP or AVIF at the correct rendered size.

  • Never lazy-load the LCP element
  • Preload the hero image or font causing the LCP
  • Serve responsive image sizes via srcset to avoid oversized downloads
  • Avoid render-blocking CSS and JS above the fold

Fixing render delay

Even once the resource has loaded, long JavaScript tasks on the main thread can delay the browser from actually painting it. Splitting large bundles, deferring non-critical scripts, and removing third-party scripts that block rendering all reduce this final sub-part.

Diagnosing sub-parts in RankAudit

RankAudit's LCP breakdown chart shows the four sub-parts as a stacked bar per tested URL, so you can immediately see whether a page's problem is server response, resource discovery, download time, or render delay, and jump straight to the relevant fix.

Key takeaways

  • Identify which of the four LCP sub-parts is dominant before fixing anything
  • Never lazy-load the largest contentful element
  • Preload the LCP resource and serve it in a compressed format
  • Defer or split JavaScript that delays the final render

Why this lesson matters

This lesson belongs to Core Web Vitals and Page Speed, the part of Technical SEO Excellence where the goal is: diagnose and resolve the specific rendering and interaction bottlenecks that drag down core web vitals.

Read it once, then do it straight away on a real site inside RankAudit. Nothing here is theory for its own sake — every step produces something you can show a client.

Do it now

  1. 1Open RankAudit with sample data already loaded, so you are not stuck on setup.
  2. 2Crawl a site and triage the issue list.
  3. 3Use RankAudit's field and lab data views to trace each Core Web Vital back to the exact element or script causing it.