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