Use web-performance-review

Read a Lighthouse report or PageSpeed Insights result, with field data when there is any (CrUX, PSI loadingExperience or RUM p75), and say what makes the page slow for…

Read a Lighthouse report or PageSpeed Insights result, with field data when there is any (CrUX, PSI loadingExperience or RUM p75), and say what makes the page slow for real users and what to fix first, ranked by how much each fix moves LCP, INP and CLS at the 75th percentile. Names the LCP element and which LCP phase dominates, the elements that shift and why, the long tasks and third parties by main-thread time, and treats estimated savings as lab estimates that overlap.

Reach for it when the user shares a Lighthouse JSON or PSI result and asks "why is this page slow", "what should we fix first", "we score 92 but Search Console says LCP is poor", "did our change fix INP", "review this Lighthouse report", or "how do we pass Core Web Vitals".

Install it

npx skilldrop-cli install web-performance-review                 # Claude Code, your user folder
npx skilldrop-cli install web-performance-review --project       # Claude Code, this repo
npx skilldrop-cli install web-performance-review --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Frontend pack: --pack frontend installs it with its neighbours.

It ships scripts, so it needs Python 3 (standard library only, nothing to install). What they may touch is declared in its manifest.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Here's our Lighthouse JSON for the product page, why is it slow and what should we fix first?"
• "PageSpeed says 92 but Search Console says LCP is poor on mobile. Which one is right?"
• "We deferred the analytics scripts and the Lighthouse score went up 12 points. Did that fix INP?"
• "Review this PSI result and tell me how to get the homepage passing Core Web Vitals"
• "What is the LCP element in this Lighthouse report and why is load delay so high?"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Lighthouse flagged contrast and missing labels on the checkout form, can you audit it against WCAG?"
• "Our main.js is 1.4 MB, here's the webpack stats file, what's making it so big?"
• "Should the blog and product pages be SSR or static with revalidation in Next.js?"

If another skill answers instead, ask for this one by name: "use web-performance-review".

Check what you get

A good result:

• The first lines say whether real users have a problem, on which vital, from which data, with the p75 threshold.
• No verdict from the Performance score. The score is described as a lab weighting, not as Core Web Vitals.
• The LCP element is named by selector or snippet, with the phase breakdown when the report has it, and the fix matches the dominant phase.
• Every CLS fix names the shifting element and its cause; field CLS above lab CLS is called out as after-load shifts the run can't see.
• TBT is never reported as INP. Long tasks and third parties are named by script or entity with milliseconds.
• Fixes are ranked by the failing vital's per-metric saving, load-time-only savings are not ranked as vital fixes, and overlapping savings are not summed.
• The single-run caveat and the emulated device and network appear once, with medians of 3 to 5 runs or field data as the bar for "improved".
• No invented numbers, elements or URLs. Every figure and selector is in the input or computed from it.

See a worked example

• quayside article

Use something else when

• The accessibility findings in the same Lighthouse report: use accessibility-audit
• What is in a JavaScript bundle and why it is heavy (source maps, stats files): use bundle-size-review
• Choosing SSR, static, ISR or client rendering for routes: use rendering-strategy
• Setting up RUM, web-vitals collection, dashboards or alerts: use observability-plan
• Lighthouse SEO and Best Practices scores; this skill reads the Performance category only

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: accessibility-audit, bundle-size-review, observability-plan, rendering-strategy

Edit this page on GitHub · View source