Performance work usually fails the same way: a team spends a week chasing a 5ms backend win while three seconds of render-blocking CSS sit untouched on the frontend, or adds three layers of cache with no invalidation plan and ships a stale-data bug. These prompts force the opposite shape — measure first, name the biggest user-visible bottleneck, then apply the smallest fix that moves the metric. The set now includes an INP prompt (Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024 and is the most-failed of the three as of June 2026), the diff prompt that catches regressions disguised as noise, and a premature-optimization detector that scans your last five perf PRs for “added complexity, no measured win.” Pair with the bug audit prompts when slowness turns out to be a correctness bug.
TL;DR
- Paste real data (Lighthouse, PageSpeed Insights field data, APM trace, slow-query log) into the prompt — never ask the model to guess a bottleneck from a code description.
- Optimize against the field thresholds Google actually scores at the 75th percentile: LCP under 2.5s, INP under 200ms, CLS under 0.1 (see table below).
- For the analysis itself, a reasoning model earns its keep: Claude Opus 4.7 or GPT-5.5 (Thinking) handle long traces and EXPLAIN plans far better than a fast/instant tier.
- The two highest-leverage prompts most teams skip: the INP fix (#3) and the premature-optimization detector (#14).
Core Web Vitals thresholds (June 2026)
Google’s pass/fail uses field data from the Chrome User Experience Report (CrUX) over a rolling 28-day window, evaluated at the 75th percentile — not your Lighthouse lab score. A page passes only when all three metrics are in the “good” range for 75% of real visits.
| Metric | Good | Needs work | Poor | Measures |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2.5s | 2.5–4.0s | > 4.0s | Load: when the largest element renders |
| INP (Interaction to Next Paint) | ≤ 200ms | 200–500ms | > 500ms | Responsiveness: worst interaction latency |
| CLS (Cumulative Layout Shift) | ≤ 0.1 | 0.1–0.25 | > 0.25 | Visual stability: unexpected layout movement |
INP replaced FID in March 2024 and, as of June 2026, is the most commonly failed of the three — roughly 43% of tracked origins still miss the 200ms bar. Lighthouse still reports Total Blocking Time (TBT) as a lab proxy; treat TBT as a debugging signal and INP field data as the score that counts.
Best for
- Web app performance audits (LCP / INP / CLS)
- Backend latency reduction (TTFB)
- Database query tuning
- Bundle-size reduction
- Memory-leak triage
1. Bottleneck identifier
Below: my performance data ([Lighthouse / PageSpeed field data / APM trace / DB slow log]).
Identify the top 3 bottlenecks. For each: where it shows up, estimated user impact,
the smallest fix that helps, and the downside of that fix. Rank by user-visible impact,
not by how easy the fix is.
[paste data]2. Largest Contentful Paint (LCP) fix
My LCP is [X] seconds at the 75th percentile; the "good" threshold is 2.5s.
Below: my HTML head, critical CSS, and the loading code for the hero image.
Diagnose: (a) what is the LCP element, (b) what blocks its render (render-blocking
CSS/JS, late image discovery, slow TTFB), (c) the smallest set of changes to get under 2.5s.
Consider fetchpriority="high" on the LCP image and a preload — but only one per page.
[paste]3. Interaction to Next Paint (INP) fix
My INP is [X]ms at the 75th percentile; the "good" threshold is 200ms.
Below: the event handlers for my slowest interaction plus a performance-panel trace.
Break the latency into input delay, processing time, and presentation delay, then tell me:
(a) which long task is blocking the main thread, (b) what to defer, yield, or move to a
web worker, (c) what re-renders unnecessarily on this interaction.
[paste]4. Cumulative Layout Shift (CLS) fix
My CLS is [X]; the "good" threshold is 0.1. Below: my above-the-fold HTML and CSS.
Find the shifting elements, name the cause (images/iframes without width+height,
fonts swapping, late-injected ads/banners, content above existing content), and
propose fixes that reserve space up front.
[paste]5. Slow-query identifier
Below: my slow query log + EXPLAIN (ANALYZE) plans. For each of the top 5 queries:
(a) why it is slow (seq scan, bad join order, missing index, function on indexed column),
(b) the specific missing index or query rewrite, (c) expected gain, (d) risk of the fix
(write amplification, index bloat, plan instability).
[paste]6. N+1 query finder
Below: ORM query log for a single page request. Find N+1 patterns: which loop generates
how many sub-queries, what to eager-load, what to batch. Output the fix in [Prisma /
ActiveRecord / SQLAlchemy / Django ORM] syntax and the expected query-count reduction.
[paste]7. JS bundle-size reducer
Below: my [webpack-bundle-analyzer / vite-bundle-visualizer] output. Identify the top 5
size offenders. For each: (a) is it tree-shakable, (b) is there a lighter alternative
(name it), (c) is it lazy-loadable via dynamic import, (d) estimated kB saved (gzipped).
[paste]8. Render-blocking-resource fix
My page has [N] render-blocking resources. Below: the HTML head. Propose: (a) which CSS
to inline as critical, (b) which scripts to defer or async, (c) which fonts/assets to
preload, (d) which to remove. Explain the ordering rationale and the LCP/INP impact.
[paste]9. Server-response-time (TTFB) reducer
My TTFB is [X]ms; target is under [Y]ms. Below: my server handler. Walk through:
(a) what work happens before the first byte, (b) what can be parallelized or moved off
the critical path (background job, queue), (c) what to cache and at which layer.
[paste handler]10. Memory-leak finder
My [Node / browser] app grows in memory over time. Below: heap snapshots / profiler output.
Identify the leak: (a) what is retained, (b) why it is retained (closure, detached DOM node,
unbounded cache, un-removed event listener), (c) the exact line to fix.
[paste]11. Cache-strategy designer
My [endpoint / page] gets [N] req/s. Below: response shape + cacheability constraints.
Design the cache strategy across edge/CDN, app, and DB layers. Be explicit about
invalidation triggers and a realistic hit-rate target. Flag any data that must never
be cached (per-user, auth-scoped, real-time).
[paste]12. Image-optimization audit
Below: 10 images on my page with current size, format, and rendered dimensions.
For each: (a) target format (AVIF first, WebP fallback, JPEG src), (b) target width
and srcset/sizes, (c) loading strategy (eager + fetchpriority="high" for the LCP image,
lazy for everything below the fold), (d) estimated bytes saved.
[paste]13. Web Vitals diff (before / after)
Below: Web Vitals before my changes ([paste]) and after ([paste]), both at the 75th
percentile. Tell me: (a) what actually improved, (b) what got worse, (c) what is within
normal CrUX variance (noise) vs a real signal, (d) what to ship vs revert.14. Premature-optimization detector
Below: my recent perf changes ([paste 5 PRs]). For each, ask: (a) was there a measured
before/after, (b) was the bottleneck real or assumed, (c) what was the actual user-visible
win, (d) which should be reverted as code-complexity-for-no-gain. Be ruthless about the
ones with no number attached.Which model to run these on
- Long traces, EXPLAIN plans, multi-file bundle output: Claude Opus 4.7 or GPT-5.5 in Thinking mode. Both carry a 1M-token context (Opus standard; full 1M in-app on ChatGPT is the $200 Pro tier), so you can paste a whole slow-query log without truncating.
- In your editor, against the actual repo: Cursor or Claude Code (see the Claude Code execution prompts) so the model sees the real handler and config, not a paraphrase.
- Quick “is this a bottleneck?” gut check: a fast tier (GPT-5.5 Instant, Claude Sonnet 4.6) is fine — but never let it invent the bottleneck. Paste data first.
Common mistakes
- Optimizing without measuring first — guessing at the bottleneck wastes the sprint.
- Scoring yourself on Lighthouse lab numbers when Google grades the CrUX field data at the 75th percentile over 28 days.
- Ignoring INP because the old habit was FID; INP is the most-failed Core Web Vital as of June 2026.
- Chasing 5ms backend wins while 3 seconds of render-blocking frontend sit ignored.
- Adding caches with no invalidation plan, then shipping a stale-data bug instead of a perf fix.
- Lazy-loading the above-the-fold LCP image, which makes LCP worse, not better.
- No before/after measurement, so “performance work” lives forever as a story without proof.
FAQ
What are the current Core Web Vitals thresholds? At the 75th percentile of real visits: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1. A URL passes only when all three are in the “good” band. These are Google’s published field thresholds as of June 2026.
Why is there an INP prompt now but no FID prompt? INP (Interaction to Next Paint) replaced First Input Delay as a Core Web Vital on March 12, 2024. INP measures the latency of all interactions across a visit, not just the first input, and it’s the metric most sites still fail.
Lighthouse says 95 but Search Console says I’m failing — which is right? Search Console. Lighthouse is a lab simulation on one device; Google’s pass/fail uses CrUX field data from real Chrome users at the 75th percentile over a rolling 28-day window. Use Lighthouse to debug, field data to score.
Should I paste code or paste data into these prompts? Data first, always. Performance is about what real users measure, so a model reasoning over a Lighthouse report, an APM trace, or a slow-query log gives a grounded answer. A model reasoning over a code description guesses.
Which AI model handles a long performance trace best? A reasoning tier with a large context window: Claude Opus 4.7 or GPT-5.5 (Thinking). Both support a 1M-token context, so a full slow-query log or bundle report fits without truncation.
Related
- Bug audit prompts
- Security audit prompts
- Database schema review prompts
- React component refactor prompts
- Deployment check prompts
Tags: #Prompt #AI coding #AI coding