Web Performance — Diagnose & Fix Core Web Vitals — refactor-chain · DEBUG lane

Bundle: refactor-chain (self-diagnosing, self-healing fix-it pipeline). Phase: do-the-work (debug) · Prerequisite: diagnose (harness classified the case as debug/web-performance) · Next: review gate → docs → ship. Adaptivity / conditional: web/front-end only. Prefers a live trace via a browser/DevTools tool (chrome-devtools performance trace or Lighthouse audit) when one is connected; falls back to static/build-artifact evidence (bundle sizes, render-blocking tags, missing image dimensions) when no browser is available.

Purpose

Turn "the site feels slow" into a measured, ranked, fixed result. This skill audits the page's Core Web Vitals — LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), and TBT/INP (Total Blocking Time / Interaction to Next Paint) — from a real trace, identifies the single biggest offender driving the worst metric, fixes that one thing, and re-runs the same audit to prove the improvement. It fixes the largest lever first rather than scattering micro-optimizations.

When to use

• The page is slow to load or paint. Triggers: "loads slowly", "first paint takes forever", "sluggish".
• The UI is janky or shifts. Triggers: "it's laggy", "the layout jumps around", "buttons feel unresponsive".
• The user cites a metric or tool. Triggers: "fix my LCP", "improve Lighthouse score", "high TBT/CLS".
• Not for: a functional bug/crash (use refactor-whats-wrong) or memory growth over repeated actions (use refactor-code-memory).