Fix LCP With an AI Agent: Field Data to Code Fix
The complete LCP diagnosis workflow using CWV Superpowers: from identifying the bottleneck phase in field data to the specific code change.
A slow Largest Contentful Paint has four possible causes. An AI agent connected to field data can identify which one is your actual bottleneck, trace it in Chrome, and generate the fix. This is the full LCP diagnosis workflow using CWV Superpowers.
Last reviewed by Arjen Karel on March 2026
The four LCP phases
Google breaks LCP into four phases. Each one has different causes and different fixes.
TTFB is the time from navigation start to the first byte of the HTML response. Slow servers, missing CDN, no caching, long database queries. If TTFB is the bottleneck, nothing else matters until you fix the server.
Load Delay is the gap between receiving the HTML and the browser requesting the LCP resource. This is the discovery problem. If the LCP image is in a CSS background, loaded via JavaScript, or buried behind a chain of redirects, the browser cannot start fetching it until it discovers it needs it.
Load Time is how long the LCP resource takes to download once requested. Large images, missing compression, slow CDN, no responsive srcset.
Render Delay is the gap between the resource finishing download and the browser actually painting it on screen. Render-blocking scripts, web font loading, or JavaScript that manipulates the DOM before the LCP element becomes visible.
Finding the bottleneck with proportional reasoning
Lighthouse tells you "LCP is 3.8 seconds." That is the total. It does not tell you which phase to fix.
CWV Superpowers gets the phase breakdown from CoreDash field data and interprets it proportionally. The bottleneck is the phase consuming the largest share of total time. Not the phase exceeding some absolute threshold.
Concrete example. LCP is 3,800ms on mobile product pages. The breakdown from real users:
- TTFB: 600ms (16%)
- Load Delay: 1,900ms (50%)
- Load Time: 800ms (21%)
- Render Delay: 500ms (13%)
Load Delay is the bottleneck. Half the total LCP time is the browser waiting to discover the image exists. A Lighthouse audit would just say "3.8 seconds" and suggest compressing images. Image compression fixes Load Time, which is 21% of the problem. The real fix is in the 50%.
For a full explanation of this approach, see proportional reasoning for web performance.
Why the browser finds your image late
Load Delay is the most common LCP bottleneck I see. It means the browser received the HTML but did not know it needed the hero image until much later.
Three common causes. The image is a CSS background image invisible to the preload scanner. The image URL is constructed in JavaScript. Or the image is technically in the HTML but has a lazy loading attribute that the browser respects too eagerly.
Open the Chrome trace. You will see a fat gap in the network waterfall between the HTML arriving and the image request firing. That gap is your Load Delay. On the sites I audit, it is 1,500 to 2,500ms on mobile. Two full seconds where the browser has the HTML but has no idea it needs the hero image.
The agent sees the same gap. It matches the waterfall to the CoreDash breakdown and tells you exactly why the image was late.
What the diagnosis looks like
This is what the output looks like:
Root cause: The LCP image div.hero-banner > img.product-main on /product/running-shoes-42 is discovered 1,980ms late because it lacks a preload hint and has no fetchpriority="high". CoreDash data: LCP is 3,820ms (poor) on mobile, p75. Load Delay is the bottleneck at 52% of total. Chrome trace confirms: 1,940ms gap between HTML first byte and image request in the network waterfall.
That is the entire diagnosis. The agent found the file, wrote the diff. You check it and ship.
Typical fixes by phase
Load Delay: Add a preload hint in the <head>. Set fetchpriority="high" on the LCP image. Move the image from CSS background or JavaScript into HTML where the preload scanner can find it.
Load Time: Convert to WebP or AVIF. Reduce image dimensions to match actual display size. Add responsive srcset so mobile users do not download a desktop-sized image. See optimizing images for Core Web Vitals.
Render Delay: Remove or defer render-blocking scripts that execute before the LCP element becomes visible. Check font-display on web fonts affecting the LCP text element. Use 103 Early Hints to deliver CSS earlier.
TTFB: Add a CDN. Enable server-side caching. Reduce database query time. Use 103 Early Hints to let the browser start preloading resources while the server is still generating the response.
Verifying the fix
After deploying, query CoreDash field data for the same page and device segment. Field data updates as real users load the page. I typically check after 24 to 48 hours of traffic. The LCP p75 should drop, and the bottleneck phase distribution should shift.
This is the step that separates field-data-driven fixes from Lighthouse guesswork. You do not hope the fix worked. You see it in real user numbers.
Find out what is actually slow.
I map your critical rendering path using real field data. You get a clear answer on what blocks LCP, what causes INP spikes, and where layout shifts originate.
Book a Deep Dive
