Web Development · Quality & performance
The Best Prompt for Diagnosing Core Web Vitals Problems
The best prompt for web performance treats the task as diagnosis, not a checklist of tips. This prompt has the model read the measurements you paste, break the failing metric into its phases, and rank hypotheses by the evidence for each, with a confirmation step and a fix per hypothesis. It is not allowed to promise numeric improvements or recommend changes that your data does not support.
Core Web Vitals Diagnosis Prompt
Works from your own field and lab data to rank likely causes of poor LCP, INP or CLS, with a way to confirm each one before you change code.
- Works with
- ChatGPT, Claude, Gemini, Cursor
- Difficulty
- Advanced
- Complexity
- Multi-part reply
- Variables
- 6
- Version
- 1.0
Customize this prompt
Fill in what you know. Anything left blank stays as a [bracketed placeholder]. Nothing you type leaves your browser.
6 variables · fields marked * matter most
You are a web performance engineer. I need a diagnosis of a Core Web Vitals problem on one page, based on evidence, not a general list of optimizations. <page> Page and its purpose: [Page and its purpose] Failing metric: [Failing metric] Stack and hosting: [Stack and hosting] What is on the page: [What is on the page] Things I cannot change: [Things you cannot change] </page> <measurements> [Measurements] </measurements> Method 1. Read the data. Say which numbers are field data from real users and which are lab data from a single test, and what each can and cannot tell us. Judge against the "good" thresholds at the 75th percentile: LCP 2.5 s, INP 200 ms, CLS 0.1. If field and lab disagree, offer the most likely reason. 2. Break the metric into phases, using only what the measurements show. - LCP: time to first byte, resource load delay, resource load duration, element render delay. Name the LCP element if the data identifies it. - INP: input delay, processing duration, presentation delay, and which interaction is slow. - CLS: which elements shift, when, and what moves them. Where the data does not let you fill a phase, write "not measurable from what was provided". 3. Rank hypotheses. A table of up to six causes, most likely first, with columns: cause, evidence from my data, how to confirm (a specific tool, panel or measurement), fix, effort (low, medium, high), and risk of side effects. 4. Recommend an order of work: what to confirm first, and the smallest change worth shipping first. 5. List the measurements that would most improve this diagnosis. Rules - Every hypothesis must cite something in the measurements or page details. If it rests on general experience only, label it SPECULATIVE and rank it last. - Do not predict specific metric gains in seconds, milliseconds or scores. Describe which phase a fix should reduce. - Respect the constraints. Do not propose removing things I said must stay; propose how to reduce their cost. - Skip advice that does not affect the failing metric. - Do not assume features of my framework or host that I have not mentioned; ask instead. Format: five numbered sections matching the method, the table in section 3, short paragraphs elsewhere.
Use it when you are
- A page template has moved into "needs improvement" or "poor" in Search Console's Core Web Vitals report
- Lighthouse scores look fine but real-user data does not, or the reverse
- Deciding which of several possible performance fixes deserves engineering time first
- Preparing an evidence-based explanation of a performance problem for a team or client
Why this prompt works
It separates field data from lab data at the start
The two answer different questions. Field data shows what real users experienced across devices and networks; a lab run shows one controlled load you can inspect in detail. Making the model label each number and explain disagreements prevents a common mistake, which is optimizing for a lab score while the field problem sits elsewhere.
Each metric is split into the phases web.dev documents
"LCP is slow" has four different possible locations: the server response, the delay before the resource starts loading, the download itself and the wait to render. Assigning time to phases narrows the cause before any fix is discussed, and the instruction to mark unmeasurable phases shows you which data to collect next.
Hypotheses must point at your evidence
Generic performance advice is easy to produce and mostly irrelevant to a given page. Requiring a citation from the pasted data for every cause, and pushing uncited ones to the bottom under a SPECULATIVE label, keeps the list short and tied to this page.
No invented numbers
A model cannot know how many milliseconds a preload will save on your page. Banning predicted gains and asking instead which phase a fix should reduce keeps the output honest and gives you a specific thing to measure after shipping.
How to use it
- Collect field data for the page or its template from Search Console, the Chrome UX Report or your own real-user monitoring.
- Run a lab test on a mobile profile and copy the metric breakdown, the LCP element or shifting elements, and the main-thread summary.
- Paste both into the measurements field with a label saying where each came from, the device and the date range.
- List what is on the page honestly, including tag-manager scripts and widgets added by other teams.
- Work through the confirmation step for the top hypothesis before writing a fix.
- After shipping one change, wait for field data to update, then re-run the prompt with the new numbers.
AI model compatibility
| Model | Status | Notes |
|---|---|---|
| ChatGPT | Expected to work | No model-specific adjustment needed. Paste the prompt as written. |
| Claude | Expected to work | The prompt already wraps your page facts and measurements in XML-style tags, the structure Anthropic's guidance recommends for separating data from instructions. Paste raw tool output inside the measurements tags as it is. |
| Gemini | Expected to work | If you attach a screenshot of a performance trace, also paste the key timings as text; the method relies on exact numbers. |
| Cursor | Expected to work | Use this inside the repo once the diagnosis points at code, so the fix column can refer to the actual template, image component or script loader. The measurements still have to be pasted in. |
“Expected to work” means the prompt uses plain, model-independent structure and has been reviewed for that — not that it has been run on that model. A model is marked Tested only when a test record is published below.
Worked example
Scenario: An illustrative case: a furniture retailer's product page template is flagged for LCP on mobile.
You are a web performance engineer. I need a diagnosis of a Core Web Vitals problem on one page, based on evidence, not a general list of optimizations. <page> Page and its purpose: Product detail page template on a furniture store; the main landing page type from organic search Failing metric: LCP (Largest Contentful Paint) Stack and hosting: Next.js 15 on Vercel; product images served from the CMS vendor's CDN What is on the page: Above the fold on mobile: sticky header, image carousel rendered by a client-side slider library, product title and price. Also a reviews widget, a chat widget, a consent banner and two web fonts. Things I cannot change: Carousel must remain; consent banner and analytics must stay </page> <measurements> Field (CrUX, mobile, 28 days, this URL group): LCP p75 3.9 s, INP p75 180 ms, CLS p75 0.04. Lab (Lighthouse mobile, one run): LCP 4.6 s, TTFB 0.5 s, LCP element is the first carousel image, a 2000 px wide JPEG; resource load delay 1.9 s, load duration 1.4 s, render delay 0.8 s. </measurements> Method 1. Read the data. Say which numbers are field data from real users and which are lab data from a single test, and what each can and cannot tell us. Judge against the "good" thresholds at the 75th percentile: LCP 2.5 s, INP 200 ms, CLS 0.1. If field and lab disagree, offer the most likely reason. 2. Break the metric into phases, using only what the measurements show. - LCP: time to first byte, resource load delay, resource load duration, element render delay. Name the LCP element if the data identifies it. - INP: input delay, processing duration, presentation delay, and which interaction is slow. - CLS: which elements shift, when, and what moves them. Where the data does not let you fill a phase, write "not measurable from what was provided". 3. Rank hypotheses. A table of up to six causes, most likely first, with columns: cause, evidence from my data, how to confirm (a specific tool, panel or measurement), fix, effort (low, medium, high), and risk of side effects. 4. Recommend an order of work: what to confirm first, and the smallest change worth shipping first. 5. List the measurements that would most improve this diagnosis. Rules - Every hypothesis must cite something in the measurements or page details. If it rests on general experience only, label it SPECULATIVE and rank it last. - Do not predict specific metric gains in seconds, milliseconds or scores. Describe which phase a fix should reduce. - Respect the constraints. Do not propose removing things I said must stay; propose how to reduce their cost. - Skip advice that does not affect the failing metric. - Do not assume features of my framework or host that I have not mentioned; ask instead. Format: five numbered sections matching the method, the table in section 3, short paragraphs elsewhere.
What a good response should contain
- A note that field and lab agree LCP is the problem while INP and CLS pass, so advice on those is omitted
- A phase breakdown that identifies resource load delay as the largest portion and points to the image being discovered late
- A ranked table whose top causes cite the client-rendered carousel and the oversized image, each with a way to confirm in DevTools or WebPageTest
- Fixes that keep the carousel, such as rendering the first slide's image in the initial HTML with appropriate priority and sizing
- A request for additional data, for example whether the image is lazy-loaded and a breakdown of field LCP by device or connection
This is an illustrative scenario showing how to fill in the prompt and what to look for. It is not a recorded model output. Recorded outputs will be published here once this prompt has a test record.
Testing and editorial review
Status: Untested. Reviewed for structure and clarity by the editorial team. No recorded model test yet.
No test record has been published for this prompt yet. When it is tested, this section will show the model and version, the date, the inputs, the actual output and notes against our seven-point rubric. We do not publish numerical scores.
| Author | TheBestPromptFor Editorial Team — The editorial team writes, reviews and maintains the prompts and guides on TheBestPromptFor. Prompts are drafted with AI assistance and reviewed against published editorial standards. |
|---|---|
| Published | November 15, 2026 |
| Last reviewed | November 15, 2026 |
| Last tested | Not yet tested |
| Version history |
|
Limitations and things to check
- The diagnosis is inference from the numbers you paste. The model cannot load your page or record a trace.
- A single lab run varies between runs. Repeat tests before treating a lab figure as stable.
- Field data from the Chrome UX Report is aggregated over a rolling window, so the effect of a fix takes time to appear.
- Metric definitions and thresholds are maintained by Google and can change. Check web.dev for the current ones.
- Framework-specific fixes should be checked against your framework version's documentation.
Alternative prompts
SEO
Technical SEO Audit Prompt
Reviews crawl exports, URL lists and Search Console notes you supply, and returns evidence-backed findings ranked by impact with a fix and a check for each.
- ChatGPT
- Claude
- Gemini
Web Development
Pull Request Code Review Prompt
Reviews a diff the way a careful senior engineer would: intent first, findings ranked by severity, each tied to a line with a suggested fix.
- ChatGPT
- Claude
- Gemini
- Cursor
Web Development
Next.js App Router Feature Prompt
A plan-then-build prompt for App Router work: routes, server and client boundaries, caching, mutations and authorization, approved before any code.
- ChatGPT
- Claude
- Gemini
- Cursor
Coding
Bug Diagnosis Prompt
Give the model the error, the code and what you expected. It ranks likely causes by evidence, tells you how to confirm each, and proposes a minimal fix.
- ChatGPT
- Claude
- Gemini
- Cursor
Related resources
Guide
How to Improve AI Responses
A diagnostic approach to weak AI answers: name the fault, trace it to the gap in your prompt, then follow up precisely or rewrite and start again.
Guide
How to Write a Good AI Prompt
The five parts of a complete prompt (goal, context, task, constraints, output format), with a worked rewrite and a pre-send checklist.
Frequently asked questions
What data do I need before using this prompt?
At minimum, the failing metric's 75th-percentile field value and one lab run that identifies the LCP element, the slow interaction or the shifting elements. Without any measurements the model can only guess, and the prompt will tell it to label nearly everything speculative.
Why won't it tell me how much faster the page will get?
Because that number would be made up. The effect of a fix depends on your users' devices, networks and caches. The prompt asks which phase should shrink, which is something you can verify in a trace after the change and later in field data.
My Lighthouse score is good but Search Console says the page is poor. Can this help?
Yes, that mismatch is what step 1 is for. Paste both sets of numbers. Typical explanations include lab tests on faster conditions than your real users have, interactions that a load-only test never performs, and shifts that happen after scrolling.
Sources and references
- Web Vitals — web.dev
- Prompt engineering overview — Anthropic
Was this prompt useful?
No account needed. Do not include personal information.