Performance Review Checklist
Performance review belongs in every meaningful frontend change — not only when Lighthouse turns red.
01 — Purpose
Performance work is continuous
Treat performance as part of every review — not a panic session when metrics drop.
This checklist targets the changes you can spot in code review and quick manual testing: weight, stability, scripts, and whether the team can measure impact. See Performance standards for deeper delivery expectations.
02 — Weight
Page weight and assets
The fastest request is the one you never make.
- images appropriately sized — dimensions set; compression applied
- lazy loading used where below-the-fold media is large — not on LCP hero images
- fonts subset and limited — no loading entire families for two weights
- CSS reviewed for unused rules and expensive selectors on hot paths
- JavaScript bundles reviewed — new dependencies justified
03 — Rendering
Rendering and stability
Users notice jank and layout shift more than a missing kilobyte.
- layout shifts during load investigated — reserved space for images and embeds
- loading states stable — no content jumping when data arrives
- long tasks on interaction considered — debounce, defer, or web workers where needed
- critical content visible without waiting for full JavaScript hydration
04 — Third-party
Third-party scripts
Every embed is a performance and privacy bet someone else controls.
- each script justified — link or static embed considered first
- analytics, chat, and widgets load after consent where required
- lazy or deferred loading for non-critical third-party code
- iframe titles and fallbacks present — see Third-Party Embeds pattern
05 — Measure
Measure what you ship
Opinions about speed are less useful than before-and-after data.
- Lighthouse or WebPageTest run on changed templates — regressions noted
- Core Web Vitals considered for high-traffic routes — LCP, INP, CLS
- real-device or throttled network test for major changes
- performance budget or team threshold agreed when adding heavy assets