core-web-vitals

Installation
SKILL.md

Core Web Vitals Review

Report the real-user page experience of one property from Chrome UX Report (CrUX) field data, find the regressions, and rank the pages or templates to fix by the clicks at stake. The user's request may contain a property, a single page URL, a device hint ("mobile", "desktop"), or a metric to focus on (LCP, INP, CLS); honor it by narrowing the calls, but still report all three Core Web Vitals.

Steps

  1. Resolve the property. If the user's request or the conversation names a property, use it. Site URLs use GSC formats: sc-domain:example.com or https://www.example.com/. Otherwise call list_sites and pick the obvious match. If several plausible properties exist, ask the user which one before continuing.

  2. Origin-level vitals. Call get_core_web_vitals with siteUrl and formFactor: "ALL" (the default; the other values are PHONE, DESKTOP, TABLET). Omit url so the whole origin is measured. Three answers are possible:

    • notConfigured: true with a hint: the Chrome UX Report connection is not set up in the GSC Wizard app. Tell the user so, relay the hint (the Core Web Vitals report in the app is where that connection is set up), and stop the vitals part of this workflow; still run steps 4 and 5 so the user gets the traffic picture.
    • noData: true with message, emptyBecause and nextStep: CrUX holds no record for that target and device class because it had too little real-world Chrome traffic. Do what nextStep says (the whole origin instead of a page, formFactor: "ALL" instead of one device); if the origin itself has no data, say the site is below the CrUX traffic threshold and that lab data is the only option.
    • A result: periods (oldest first, each a 28-day collection window ending in that week; never read a series newest-first), periodLabels and latestPeriod.
    • metrics[] with key, label, coreWebVital (true for LCP, INP, CLS; false for FCP and TTFB, which are diagnostics), unit, latestP75, latestP75Formatted, latestRating (good, needs-improvement or poor), latestGoodDensity (a 0-1 fraction of page loads rated good; multiply by 100 only when you present it as a percent and say so), p75Series and goodDensitySeries aligned with periods.
    • Use latestRating as the verdict; do not re-rate the numbers yourself. CLS is unitless, the other metrics are milliseconds.
    • regressions[]: each with metricKey, fromRating, toRating, fromValueFormatted, toValueFormatted, fromPeriod, toPeriod. It lists only a Core Web Vital whose rating band got worse between its two latest weeks with data; when it is empty the response carries methodLimits, so read p75Series for drift inside a band or over a longer span and report that as a trend, not as a regression.
    • adMetrics[] (only when Chrome detected ads): experimental ad count, density, CPU and network weight as p75 trends with no rating and no thresholds; mention them when a site carries ads and INP or LCP is poor.
    • softNavMetrics[] (experimental): LCP, INP and CLS counting single-page-app route changes, rated on the stable thresholds, with pageLoadsOnlyLatestP75 beside each for the same week; entries are null before October 2026 and never appear in regressions.
Installs
2
First Seen
2 days ago