PluginBench
Skill
Pass
Audit score 90

core-web-vitals

addyosmani/web-quality-skills

Optimize Core Web Vitals (LCP, INP, CLS) for better page experience using field and lab evidence.

What is core-web-vitals?

Diagnose and fix the three Core Web Vitals metrics that Google uses to measure page experience. Use this skill when optimizing loading performance (LCP), interactivity (INP), or visual stability (CLS) based on real-user data and browser traces.

  • Measure LCP, INP, and CLS using CrUX field data and browser performance traces
  • Diagnose LCP issues including slow TTFB, render-blocking resources, late resource discovery, and client-side rendering delays
  • Optimize INP by analyzing input delay, processing time, and presentation delay separately
  • Fix CLS by identifying shifted nodes and their triggers using field attribution or traces
  • Apply Speculation Rules API for prerendering likely next-page navigations
  • Identify LCP elements and verify fixes with lab measurements

How to install core-web-vitals

npx skills add https://github.com/addyosmani/web-quality-skills --skill core-web-vitals
Prerequisites
  • A runnable URL or source code to analyze
  • Chrome DevTools or equivalent browser performance tracing capability
  • Access to CrUX data (via Search Console or PageSpeed Insights) for field evidence
Claude Code
Cursor
Windsurf
Cline

How to use core-web-vitals

  1. 1.Check page-level CrUX p75 data to identify which metric is failing (LCP, INP, or CLS)
  2. 2.Record a browser performance trace under realistic conditions to diagnose root causes
  3. 3.For LCP: optimize TTFB, inline critical CSS, preload discoverable resources, and ensure content is in initial HTML
  4. 4.For INP: analyze input delay, processing time, and presentation delay; reduce main-thread work
  5. 5.For CLS: identify shifted elements and their triggers; reserve space for dynamic content and fonts
  6. 6.Re-run lab measurements after fixes to verify improvement; allow time for CrUX to reflect field changes

Use cases

Good for
  • Improve a page's p75 Core Web Vitals scores to meet Google's "Good" thresholds
  • Reduce Largest Contentful Paint time by optimizing server response, critical CSS, and resource discovery
  • Fix Interaction to Next Paint slowness by diagnosing main-thread contention and application work
  • Eliminate unexpected layout shifts by reserving space for dynamic content and fonts
  • Accelerate same-origin navigations using prerendering for predictable user journeys
Who it's for
  • Web performance engineers
  • Frontend developers optimizing page experience
  • Site owners improving search visibility and user experience
  • Teams using Chrome DevTools or performance monitoring tools

core-web-vitals FAQ

What are the good thresholds for Core Web Vitals?

LCP ≤ 2.5s, INP ≤ 200ms, and CLS ≤ 0.1 are considered "Good". Google measures at the 75th percentile, meaning 75% of page visits must meet these thresholds.

Should I preload the LCP image?

Only if a browser trace shows the resource is discovered late. Prefer a discoverable <img> with fetchpriority="high" in initial HTML. Unnecessary preloads can compete for bandwidth.

How do I identify which element is causing layout shift?

Use field attribution or a browser trace to identify the shifted node and its trigger. Do not assume the visible victim caused the shift; the actual cause may be elsewhere.

Can I use Speculation Rules API to improve LCP?

Speculation Rules prerender likely next pages, making subsequent navigations faster. Start with "moderate" eagerness and measure prediction hit rate and server load before expanding. This is a navigation optimization, not a substitute for fixing the current page's LCP.

When should I claim an improvement in Core Web Vitals?

Only after re-running equivalent lab measurements post-fix. Do not claim field improvement immediately; CrUX and first-party RUM require new user visits to reflect changes.

Full instructions (SKILL.md)

Source of truth, from addyosmani/web-quality-skills.


name: core-web-vitals description: Optimize Core Web Vitals (LCP, INP, CLS) for better page experience using field and lab evidence. Use when asked to "improve Core Web Vitals", "fix LCP", "reduce CLS", "optimize INP", "page experience optimization", or "fix layout shifts". license: MIT metadata: author: web-quality-skills version: "2.0"

Core Web Vitals optimization

Targeted optimization for the three Core Web Vitals using field data to identify user impact and browser traces to diagnose causes.

Measure before optimizing

When a runnable URL is available, read the performance measurement workflow. Prefer this sequence:

  1. Check page-level CrUX p75 data, with a clearly labeled origin fallback when page data is unavailable.
  2. Record a browser performance trace under stated conditions. With Chrome DevTools MCP, trace summaries can include CrUX alongside the observed lab metrics.
  3. Analyze only the insights associated with the failing metric, then inspect the implicated code and resources.
  4. Re-run equivalent lab measurements after the fix. Do not claim an immediate field improvement; CrUX and first-party RUM need new user visits.

If only source code is available, identify likely causes but do not claim that LCP, INP, or CLS is failing without runtime evidence.

The three metrics

MetricMeasuresGoodNeeds workPoor
LCPLoading≤ 2.5s2.5s – 4s> 4s
INPInteractivity≤ 200ms200ms – 500ms> 500ms
CLSVisual Stability≤ 0.10.1 – 0.25> 0.25

Google measures at the 75th percentile — 75% of page visits must meet "Good" thresholds.


LCP: Largest Contentful Paint

LCP measures when the largest visible content element renders. Usually this is:

  • Hero image or video
  • Large text block
  • Background image
  • <svg> element

Common LCP issues

1. Slow server response (TTFB > 800ms)

Fix: CDN, caching, optimized backend, edge rendering

2. Render-blocking resources

<!-- ❌ Blocks rendering -->
<link rel="stylesheet" href="/all-styles.css">

<!-- ✅ Critical CSS inlined, rest deferred -->
<style>/* Critical above-fold CSS */</style>
<link rel="preload" href="/styles.css" as="style" 
      onload="this.onload=null;this.rel='stylesheet'">

3. Slow resource load times

<!-- ❌ LCP image is discovered only after a stylesheet loads -->
<div class="hero"></div>

<!-- ✅ Discoverable in initial HTML and prioritized -->
<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">
<img src="/hero.webp" alt="Hero" fetchpriority="high">

Prefer a discoverable <img> with fetchpriority="high". Add the preload only when the trace shows that the resource would otherwise be discovered late; duplicate or speculative preloads can compete for bandwidth.

4. Client-side rendering delays

// ❌ Content loads after JavaScript
useEffect(() => {
  fetch('/api/hero-text').then(r => r.json()).then(setHeroText);
}, []);

// ✅ Server-side or static rendering
// Use SSR, SSG, or streaming to send HTML with content
export async function getServerSideProps() {
  const heroText = await fetchHeroText();
  return { props: { heroText } };
}

5. Make navigations instant with the Speculation Rules API

For sites with predictable same-origin journeys, prerendering a likely next page can make a successful subsequent navigation much faster. Treat this as a measured navigation optimization, not a substitute for fixing the current page's LCP.

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/*" },
    "eagerness": "moderate"
  }]
}
</script>

Current Chrome behavior is specific enough to guide the choice:

eagernessTrigger
conservativePointer or touch down
moderateDesktop: 200ms hover, or earlier pointer down; mobile: viewport heuristics
eagerChrome 143+: desktop 10ms hover; mobile 50ms after the anchor enters the viewport
immediateAs soon as the rules are observed

Start conservatively and measure prediction hit rate, transferred bytes, server load, and navigation improvement before expanding the rules. Recheck Chrome's maintained eagerness documentation before hardcoding timing-sensitive behavior.

Caveats:

  • Bandwidth/CPU cost. Each prerender is roughly a full page load. Scope where carefully (href_matches patterns, exclude logout/checkout) and avoid immediate outside small sites.
  • Side effects fire early. Analytics, ads, and any code that runs on load will fire when the prerender starts, not when the user navigates. Gate side effects on the prerenderingchange event or document.prerendering.
  • Chromium-only. Safari and Firefox ignore the script — it's a progressive enhancement, never a regression.

LCP optimization checklist

- [ ] TTFB < 800ms (use CDN, edge caching)
- [ ] LCP resource is discoverable in initial HTML and prioritized; preload only if the trace shows late discovery
- [ ] LCP image optimized (WebP/AVIF, correct size)
- [ ] Critical CSS inlined (< 14KB)
- [ ] No render-blocking JavaScript in <head>
- [ ] Fonts don't block text rendering (font-display: swap)
- [ ] LCP element in initial HTML (not JS-rendered)
- [ ] Speculation Rules added for likely-next navigations (moderate eagerness)

LCP element identification

This snippet diagnoses the current page session. It is not field data.

// Find your LCP element
new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];
  console.log('LCP element:', lastEntry.element);
  console.log('LCP time:', lastEntry.startTime);
}).observe({ type: 'largest-contentful-paint', buffered: true });

INP: Interaction to Next Paint

INP measures responsiveness across clicks, taps, and key presses during a visit. Diagnose its input delay, processing time, and presentation delay separately; a slow interaction may involve main-thread contention before the handler, expensive application work, or delayed rendering after it.

When field INP is poor or a trace identifies a slow interaction, read the INP reference for trace interpretation, yielding patterns, third-party and rendering causes, a single-session observer, and first-party attribution.


CLS: Cumulative Layout Shift

CLS measures unexpected layout shifts across a page visit. Use field attribution or a trace to identify the shifted node and the trigger; do not assume the visible victim caused the shift.

When field CLS is poor or a trace reports shifts, read the CLS reference for reserved-space patterns, dynamic content, font and animation fixes, a debugging observer, and a verification checklist.


Measurement sources

SourceUse
Browser performance trace (Chrome DevTools MCP: performance_start_trace)Observe one load or interaction and diagnose focused insights; use included CrUX context when available
CrUX or Search ConsolePrioritize aggregated real-user outcomes at p75
Lighthouse CLI or PageSpeed InsightsControlled lab fallback when DevTools tools are unavailable
First-party RUMSegment current production experience by route, device, release, and attribution
Raw PerformanceObserverInspect one page session during debugging

Do not route performance through Chrome DevTools MCP's lighthouse_audit; that capability intentionally covers non-performance Lighthouse categories. Do not compare a single lab value directly with a field p75 as if they were equivalent samples.

When adding or reviewing production collection, read the first-party RUM reference. Prefer the web-vitals library because raw browser APIs do not by themselves implement every Core Web Vital's lifecycle and reporting rules.


Framework quick fixes

Next.js

// LCP: Use next/image with priority
import Image from 'next/image';
<Image src="/hero.jpg" priority fill alt="Hero" />

// INP: Use dynamic imports
const HeavyComponent = dynamic(() => import('./Heavy'), { ssr: false });

// CLS: Image component handles dimensions automatically

React

// LCP: Preload in head
<link rel="preload" href="/hero.jpg" as="image" fetchpriority="high" />

// INP: Memoize and useTransition
const [isPending, startTransition] = useTransition();
startTransition(() => setExpensiveState(newValue));

// CLS: Always specify dimensions in img tags

Vue/Nuxt

<!-- LCP: Use nuxt/image with preload -->
<NuxtImg src="/hero.jpg" preload loading="eager" />

<!-- INP: Use async components -->
<component :is="() => import('./Heavy.vue')" />

<!-- CLS: Use aspect-ratio CSS -->
<img :style="{ aspectRatio: '16/9' }" />

References