SEO

Page experience diagnosis

Use when Core Web Vitals are failing and you need a prioritized engineering brief.

page-experience-diagnosis.md

Download .md

You are diagnosing page experience problems and writing a brief engineers can act on.

Template or URL: {{URL}}
Field data (CrUX or RUM: LCP, INP, CLS, split by device): {{FIELD_DATA}}
Lab data (Lighthouse or WebPageTest summary): {{LAB_DATA}}
Stack: {{STACK}}
Known third party scripts: {{THIRD_PARTIES}}

Output:
1. A metric table: Metric | Field value | Threshold | Pass or fail | Device where it is worst.
2. For each failing metric, the likely causes ranked by probability, each with the evidence from the supplied data that supports it.
3. A fix table: Fix | Metric affected | Expected direction of change | Effort (S / M / L) | Risk of regression | Who does it.
4. "Measure this to confirm" - the exact check for each fix.

Constraints:
- Field data outranks lab data. Where they disagree, say which you are trusting and why.
- Do not predict a numeric improvement, for example "will cut LCP by 1.2s". State direction and reasoning instead.
- Call out any fix that improves lab scores without improving real user experience.
- If a third party in {{THIRD_PARTIES}} is a plausible cause, name it and say how to test by removal.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{URL}}
{{FIELD_DATA}}
{{LAB_DATA}}
{{STACK}}
{{THIRD_PARTIES}}

Getting a better result

Always paste field data - lab scores alone lead to optimizing the wrong thing.
Split by device before pasting, since mobile INP failures usually have a different cause to desktop.
Ask for the measurement check to be added to the ticket so the fix can be proven.

Questions about this prompt

When are Core Web Vitals worth engineering time?

When field data shows real users failing, not when a lab score looks bad. Page experience is a modest ranking factor and a significant conversion one, so the honest case for the work is usually revenue rather than rankings.

Why does it insist on field data?

Because lab scores lead to optimising the wrong thing. Lab data is a simulation on one device and connection; field data is what your actual visitors experienced. Teams routinely spend sprints improving a lab number while the field metric does not move.

Should I split by device?

Yes, before pasting. Mobile interaction failures usually have a different cause from desktop, and a combined figure averages two different problems into one number that points at neither.

How do I prove the fix worked?

Ask for the measurement check to be written into the ticket. Field data moves on a rolling twenty-eight day window, so a fix shipped today does not show fully for a month, and teams that do not plan for that conclude the work failed.