Diagnoses and fixes Core Web Vitals - LCP, INP, and CLS - through an ordered audit procedure with concrete code-level changes for images, fonts, JavaScript, and third-party scripts. Use when someone asks "why is my page slow", "how do I fix my LCP", "we're failing Core Web Vitals", "improve my Lighthouse score", or wants a frontend performance audit before a launch or SEO push. Do NOT use for testing server capacity under concurrent traffic - use load-testing instead; for native mobile app performance, use mobile-perf-profiler; for Next.js-on-Vercel-specific tuning, use next-on-vercel-perf.
Click to play with sound.
---
name: Web Performance
description: Diagnoses and fixes Core Web Vitals - LCP, INP, and CLS - through an ordered audit procedure with concrete code-level changes for images, fonts, JavaScript, and third-party scripts. Use when someone asks "why is my page slow", "how do I fix my LCP", "we're failing Core Web Vitals", "improve my Lighthouse score", or wants a frontend performance audit before a launch or SEO push. Do NOT use for testing server capacity under concurrent traffic - use load-testing instead; for native mobile app performance, use mobile-perf-profiler; for Next.js-on-Vercel-specific tuning, use next-on-vercel-perf.
---
# Web Performance
Pages get optimized for the developer's laptop and fail for the median user on a mid-tier phone over 4G - that is the costly mistake this skill prevents. The outcome is passing Core Web Vitals at the 75th percentile of real users: LCP under 2.5s, INP under 200ms, CLS under 0.1. Everything below is ordered so measurement decides where effort goes, because intuition about performance is wrong more often than it is right.
## Operating procedure
Run the audit in this order. Fixing before measuring wastes effort on metrics that already pass; measuring in the lab before checking field data optimizes for a synthetic user who does not exist.
### Step 1: Gather inputs
- The URL(s) or page templates that matter commercially (home, landing, product, checkout). Default: the highest-traffic template.
- Field data access: CrUX (public per-origin) or in-house RUM. If neither exists, note that lab data is a proxy and label conclusions accordingly.
- Framework and rendering mode (SSR, SSG, SPA, islands), CDN in use, and the third-party tag list.
- The audience's device and network profile. Default when unknown: mid-tier Android over 4G - never a desktop on fiber.
### Step 2: Read field data first
Use field data (CrUX, RUM) for what users actually experience; lab data (Lighthouse, WebPageTest) only to debug. Read LCP, INP, and CLS at the 75th percentile. Passing bands: LCP under 2.5s, INP under 200ms, CLS under 0.1. Needs-improvement bands: LCP 2.5-4s, INP 200-500ms, CLS 0.1-0.25; anything beyond those is failing. The failing metric - not the loudest complaint - selects which playbook below to run.
### Step 3: Reproduce in the lab under throttling… install to load the full skill