What this prompt does
This prompt turns your Core Web Vitals numbers into a prioritized, code-level fix plan and returns concrete code or config, not vague advice. It casts the AI as a frontend performance engineer. You provide the [url], the [framework], and a pasted [cwv_report]. For each of LCP, INP, and CLS it returns the current value, a target, likely causes ranked by probability, and a code or config fix, plus the expected improvement per fix, whether it needs infra or only frontend, a priority order computed by impact over effort, and a regression-guard note.
The value is converting a raw report into an ordered fix list instead of guessing. Most CWV regressions trace to a handful of culprits — oversized hero images, blocking JS, layout shift from late content — and ranking causes by probability points you at the likely one first. Sorting by impact divided by effort stops you from chasing low-value green-score wins, and the regression-guard note flags which metric a careless fix could worsen.
When to use it
- Translating a
[cwv_report]into a concrete, code-level fix plan - Prioritizing fixes by impact over effort instead of guessing
- Diagnosing LCP, INP, or CLS issues in a specific
[framework] - Separating fixes that need infra changes from frontend-only ones
- Avoiding regressions where fixing one metric quietly worsens another
- Stopping the chase for green scores once real user metrics improve
Example output
You get a ranked table with columns for metric, fix, code snippet, expected delta, and infra-or-frontend, followed by the highest-priority snippet in full. Each of LCP, INP, and CLS gets its current value, a target, causes ranked by probability, and a concrete code or config fix. A regression-guard note flags which metric each change could worsen if applied carelessly, so you can avoid trading one regression for another.
Pro tips
- Paste the full
[cwv_report]with real numbers — the diagnosis and ranking depend on actual values, not field-vs-lab assumptions you skip - Set
[framework]precisely (e.g. Next.js 15) so the fixes use the right APIs, like the framework's image and script components - Work the list in impact-over-effort order and stop once real user metrics improve, rather than chasing a perfect lab score
- Read the regression-guard note before applying a fix — aggressive INP work can shift cost onto LCP if done carelessly
- Distinguish the infra-or-frontend flag so you batch infra changes separately from quick frontend wins
- Re-measure after each change with the same
[url]so you attribute the delta to the specific fix you shipped - Start from the highest-priority snippet returned in full, ship it, confirm the delta, then move down the ranked table rather than batching everything at once
