To fix Largest Contentful Paint (LCP) with AI, give the model a stripped AIReport and tell it to move largest-contentful-paint toward targetFor90. A good mobile LCP is 2.5 seconds or less. Lighthouse gives that metric 25 of 100 performance points, so a slow LCP is often the single largest gap in the score.
Estimated savings on an unused-CSS audit do not change that score. The element, the request that loads it, and a second scan do. This guide is that loop. The shorter tour is How to Fix Your LCP Score Using AI. The diagnostic checklist, without the AI prompt, is How to Diagnose Slow LCP.
What the AI should treat as the finish line
Google's "good" LCP is 2.5 seconds at the 75th percentile of real Chrome users. The lab number you can re-check in minutes is the Lighthouse metric. In an AIReport, scorePlan.strategies[].metrics already states the finish line.
On mobile, targetFor90 for largest-contentful-paint is 2500 ms. On desktop it is 1200 ms. The weight is 25 in both cases. Field ratings stay the usual ones: good at 2.5 seconds or less, needs work from 2.5 to 4 seconds, poor above 4 seconds. The desktop lab target is tighter than the field "good" line.
pointsAtRisk is weight × (1 − metric score). An LCP that scores near 0 can cost about 25 points. An LCP already near 90 costs about 2 or 3. Start with whichever metric in scorePlan has the highest pointsAtRisk. If that metric is not LCP, fix that one first. This page assumes LCP is the one in front.
fieldData is real-user Chrome data. It will not move on the next lab run. Search Console can take weeks to reflect a fix. Use the lab numericValue to know whether the code change worked.
Step 1: Export an AIReport, not a raw PSI dump
Open PageSpeed Exporter and run the URL on Mobile. Google's lab report and mobile-first indexing both care about that pass. Desktop is a second pass: its LCP target is 1.2 seconds, and it is on Starter and Pro.
On the results page, use Download AIReport (JSON) or Copy Prompt + JSON. The file is the stripped report: scores, the score plan, CrUX when Google has it, and the failing rows. Screenshots and passing audits are already gone, so the file stays small enough to paste into ChatGPT, Claude, or Cursor.
What the model needs for LCP is already labeled:
scorePlan→largest-contentful-paint— current value,pointsAtRisk, andtargetFor90issues[]whereaffectsMetricsincludeslargest-contentful-paint— the audits that can move LCP, already sorted by pointslargest-contentful-paint-element→details.items[].snippet— the exact node Lighthouse painted as LCPcritical-request-chains→details.items[].url— the chain the browser had to finish before that noderender-blocking-resourcesand image audits — the stylesheet, script, or image bytes on that chainpassedAuditIds— checks that already score 90 or above. Leave them alone
A raw PageSpeed JSON is 500KB–2MB and mostly screenshots. The model spends the context window on noise. The AIReport is the same Lighthouse engine with that noise removed. See What is an AIReport?.
Step 2: Prompt the model to follow points, then the element
Paste the AIReport and use this prompt. It tells the model to ignore savings that do not move LCP.
You are fixing Largest Contentful Paint for this site. The attached JSON is an AIReport from PageSpeed Exporter.
Rules:
1. Read scorePlan.strategies for mobile. Find largest-contentful-paint. State numericValue, pointsAtRisk, and targetFor90.
2. Only change issues whose affectsMetrics includes largest-contentful-paint. Skip every id in passedAuditIds.
3. Name the LCP node from the issue id largest-contentful-paint-element (snippet or selector).
4. Name the URLs on critical-request-chains that delay that node.
5. Do not rank work by savings.ms. A large unused-CSS savings does not count unless it shortens this metric.
6. Reply with a diff for my stack: [Next.js / WordPress / Shopify / plain HTML].
7. End with the numericValue I should see on the next mobile scan if the diff is applied.
Do not invent files that are not implied by the snippet, selector, or URL.Fill in the stack. If the LCP node is an image, the diff should preload it, stop lazy-loading it, and give it a real width and height. If the node is a heading, the diff should unblock the font or the CSS that paints it. If server-response-time is on the chain, say so before rewriting the hero component. No image change fixes a 3-second TTFB.
Example: a 6.0 s hero image
This is a shaped excerpt, not a live customer site. It shows the order the model should follow.
numericValue: 6000 mspointsAtRisk: 21.4targetFor90: 2500 ms- LCP snippet: an
img.herowhosesrcis/hero.jpgand whoseloadingattribute islazy - Longest chain: HTML, then
theme.css, then/hero.jpg
The model should not start with "remove unused JavaScript." The chain says the hero is discovered late, and the snippet says it is lazy-loaded. A useful diff looks like this:
<link rel="preload" as="image" href="/hero.jpg" fetchpriority="high">
<img class="hero" src="/hero.jpg" width="1200" height="800" alt="Hero" fetchpriority="high">On Next.js the same instruction is priority on next/image for that one image, and no loading="lazy". On WordPress it is a wp_head preload of the attachment that the snippet identifies, not every image on the page.
pointsAtRisk on LCP falls from about 21 to under 3. The performance score moves because the weighted metric moved, not because a savings estimate said it would.
Your chain will name different files. Trust the URLs in the report.
Step 3: Re-scan before you touch the next metric
Deploy the diff, then run the same URL on mobile again. In the new AIReport:
largest-contentful-paint.numericValueis at or under 2500, or it is not done- The LCP snippet is the element you meant to optimize
- Issues you closed are in
passedAuditIdsor gone from the failing list
If LCP is still the highest pointsAtRisk, the first diff missed the chain. Paste both reports and ask what is still on the path to the snippet. Starter keeps a before/after comparison for that pair of scans. Pro adds a batch ZIP when the same template is slow on many URLs.
One homepage fix is two or three reports: the first scan, a wrong guess, and the scan that proves 2.5 seconds. A template plus a landing page uses the free monthly allowance quickly. Anonymous visitors get 2 preview reports. A free account gets 5 mobile reports a month. After those 5 are used, the first paid month is $5 on Starter (then $9) or $15 on Pro (then $29). That rate is only for a free account that has already run all 5 reports.
Desktop LCP and a both-strategy run are on the paid plans. Mobile is the right first scan. Desktop is how you catch a hero that is fine on a phone and late on a wide layout.
Further Reading
- What is LCP? — thresholds and the usual causes
- How to Fix Your LCP Score Using AI — the short prompt tour
- How to Diagnose Slow LCP with Lighthouse — TTFB, discovery, and image delay without the score plan
- How to Fix CLS with AI — the same AIReport loop for layout shift
- Use the report in Cursor — run the audit from the editor
- Pricing — free reports, then Starter and Pro