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.