A marketing leader came to us after spending $80,000 on a redesigned website, only to watch Largest Contentful Paint worsen from 2.1 seconds to 4.6 seconds — and conversions drop 18 percent. The design agency had skipped the performance audit phase entirely. No baseline metrics, no budget constraints, nothing to hold the build accountable to.
This is preventable. The audit takes about a week and saves the redesign from itself.
The 4 baseline numbers to capture before anyone opens Figma
Before any design work starts, capture performance metrics from actual users on real devices, using Google's Core Web Vitals as the foundation:
- LCP (Largest Contentful Paint) — how fast the main content paints. Degrades above 2.5 seconds, poor beyond 4 seconds.
- INP (Interaction to Next Paint) — responsiveness to user interactions. Target under 200ms; this replaced FID in March 2024.
- CLS (Cumulative Layout Shift) — visual stability during page load. Target under 0.1.
- TTFB (Time to First Byte) — server response time. Not a Core Web Vital, but a leading indicator. Target under 600ms.
Pull the data from CrUX (Chrome User Experience Report) field data, not a single Lighthouse run. Lab data doesn't reflect what real users experience on mid-range devices over LTE connections.
Where redesigns make performance worse
Four issues degrade performance in roughly 90 percent of the redesigns we audit:
- Hero imagery that's too large. An unoptimized 4MB hero image can single-handedly tank LCP. Set a file size budget per image and enforce AVIF or WebP formats.
- Hero videos. Autoplay videos in hero sections add 2–8MB before the user does anything. Either give video its own performance budget or use a poster image with click-to-play.
- Web fonts. Each custom font weight costs 30–80KB and blocks text rendering. Use font-display: swap, preload at most two weights, and set metrics-compatible system font fallbacks. We have seen redesigns loading 14 font files.
- Third-party scripts. Hotjar, Drift, Segment, pixels, and chat widgets each add 50–200KB and block the main thread. Inventory all of them during the audit and force a prioritization conversation.
The performance budget you set before any design starts
A performance budget is a binding contract: the site does not launch if the numbers exceed the thresholds. It belongs in the Statement of Work, in the design brief, and enforced in CI with Lighthouse CI or an equivalent.
| Metric | Budget | Enforced where |
|---|---|---|
| LCP (mobile, 75th percentile) | < 2.0s | CrUX, Lighthouse CI |
| INP (mobile, 75th percentile) | < 200ms | CrUX |
| CLS (mobile, 75th percentile) | < 0.1 | CrUX, Lighthouse CI |
| TTFB | < 500ms | WebPageTest |
| Total JS (compressed) | < 200KB on landing | WebPageTest, build step |
| Total page weight | < 1.5MB on landing | WebPageTest |
| Hero image (any single) | < 150KB | Build step |
| Web fonts | <= 2 weights, 1 family | Code review |
| Third-party scripts on first load | <= 3 | Code review |
| Lighthouse Performance score | >= 90 mobile | Lighthouse CI in PRs |
If you set the budget at 'Lighthouse 70,' you'll end up at 55. If you set it at 90, you'll end up at 82. Anchor high.
What we test and what we test it with
The audit uses a multi-tool stack because each tool answers a different question:
- Lighthouse (via Chrome DevTools or Lighthouse CI) for lab metrics, accessibility, SEO, and best-practice signals. We run it three times and record the median.
- WebPageTest for waterfall analysis, filmstrip view, and testing from different geographic locations on different network profiles. This is where CDN gaps show up.
- CrUX dashboard for field data from real Chrome users over the previous 28 days — the ground truth Google uses as a ranking signal.
- Cloudflare or CDN analytics for cache hit ratios, origin response times, and where requests fail.
The compiled audit is a 6–8 page document: current metrics, proposed budgets, the top five issues to fix before the redesign, and the five things to watch during it. It ships as an appendix to the design brief — and it is the reason the new site launches faster than the old one instead of slower.