A marketing leader called us last quarter. They had just spent $80,000 on a beautiful new site, and their Largest Contentful Paint had gone from 2.1 seconds to 4.6 seconds. Conversion was down 18 percent. The agency had not run a performance audit before they started, so there was no baseline to defend against and no budget the design had to fit inside.
This is preventable. The audit takes about a week and saves the redesign from itself. Here’s exactly what we capture and how we use it.
The 4 baseline numbers to capture before anyone opens Figma
Before any wireframes, before any moodboards, you need today’s performance numbers from real users on real devices. Google’s Core Web Vitals are the right starting point because they’re what ranking and conversion correlate to.
- LCP (Largest Contentful Paint) — how fast the main content paints. Anything above 2.5 seconds is “needs improvement”; above 4 seconds is poor.
- INP (Interaction to Next Paint) — how responsive the page feels when the user clicks or taps. Replaced FID in March 2024. Target under 200ms.
- CLS (Cumulative Layout Shift) — how much the page jumps around as it loads. Target under 0.1.
- TTFB (Time to First Byte) — how fast the server responds. Not a Core Web Vital, but a leading indicator. Target under 600ms.
Capture these from CrUX (Chrome User Experience Report) field data, not from a single Lighthouse run. Lighthouse gives you lab data, which is useful for debugging but unreliable as a baseline because it doesn’t reflect what your actual visitors experience on mid-range Android phones over LTE.
Where redesigns make performance worse
The same four things degrade performance in nine out of ten redesigns. Knowing this upfront lets you push back during design review instead of finding out at QA.
- Hero imagery that’s too large. A 4MB unoptimized hero image will tank LCP single-handedly. Designers love them. Hold the line on file size budgets per image and require AVIF or WebP.
- Hero videos. Autoplay video in the hero adds 2-8MB before the user has done anything. If the brief includes a hero video, the performance budget should include a separate carve-out for it, or it should be a poster image with click-to-play.
- Web fonts. Each custom font weight is 30-80KB and blocks text rendering. The fix is font-display: swap, preloading two weights max, and using a system font fallback that’s metrics-compatible. We’ve seen redesigns load 14 font files. Fourteen.
- Third-party scripts. Marketing wants Hotjar, Drift, Segment, three pixels, and a chat widget. Each one adds 50-200KB and blocks the main thread. The audit needs to inventory every third-party script and decide which survive the redesign.
The performance budget you set before any design starts
A performance budget is a contract: the new site cannot ship if it exceeds these numbers. It goes in the SOW. It goes in the design brief. The developer enforces it in CI with Lighthouse CI or a similar gate.
| 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 |
These numbers are tight on purpose. 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 isn’t one tool, it’s a stack. Each tool tells you a different piece of the truth.
- Lighthouse (in Chrome DevTools or Lighthouse CI) for lab metrics, accessibility, SEO, and best-practice signals. We run it three times and take the median.
- WebPageTest for waterfall analysis, filmstrip, and testing from real geographic locations on real network profiles. This is where you’ll see that your CDN is missing in APAC.
- CrUX dashboard for field data from actual Chrome users over the past 28 days. This is the ground truth, and it’s what Google uses for ranking signals.
- Cloudflare or your CDN’s analytics for cache hit ratios, origin response times, and where requests are failing.
We package all of this into a 6-8 page audit document with current numbers, the proposed budget, the top five issues to fix before redesign, and the top five things to watch during redesign. That document becomes the design brief’s appendix.
Now what? See how we approach performance, security, and compliance on every site we build, or get the broader picture of our website development work.