The performance audit we run before any redesign

A team will come to us and say "we want a redesign." The first thing we ask is "have you measured what's actually broken?"

About 70% of the time, the answer is no. The site feels slow, the bounce rate is high, conversion is stalled, and the team assumes a redesign will fix it. Sometimes it will. More often, the problems are specific and measurable, and a redesign without measuring will fix some of them while breaking others.

A one-week audit catches this before the redesign starts. It costs a fraction of what a redesign costs, and it tells you whether the redesign is the right project at all.

This is what's in the audit, what it usually finds, and a real example of what changed when we ran it.

What we measure

Seven things, in roughly this order:

1. Lighthouse, lab data.

Lighthouse runs in your browser or via CI. It's a synthetic test under controlled conditions. The scores aren't the point; the specific findings are. Lighthouse tells you:

• Core Web Vitals (LCP, INP, CLS) under simulated conditions
• Image optimisation issues (unoptimised formats, oversized images)
• Render-blocking resources
• Accessibility violations
• SEO basics (missing meta, no canonical, etc.)
• Best-practices violations (HTTPS issues, console errors, vulnerable libraries)

We run Lighthouse on the homepage and three or four other key pages. Mobile and desktop. The whole thing takes thirty minutes.

2. CrUX, real-user data.

Chrome User Experience report. Real-user metrics aggregated by Google. Different from Lighthouse: this is what actual users experience, not what a synthetic test in a lab finds.

The two often disagree. Lighthouse says LCP is 1.8s; CrUX says the 75th percentile is 4.2s. Both are true. Lighthouse measures one device under one network. CrUX measures everyone, including the user on a 2017 Android on patchy 4G. CrUX is the number that matters for SEO and for honest user experience.

3. WebPageTest, waterfall analysis.

WebPageTest gives you a request waterfall. You see exactly what loads, in what order, with what dependencies. This is where you find things like:

• Fonts blocking rendering because the preload hint is missing
• A 200KB JavaScript file that loads on every page but is only used on one
• Third-party scripts adding 500ms to first paint
• Sequential dependencies that should be parallel

The waterfall is more useful than any Lighthouse score for figuring out what to actually fix.

4. Bundle analysis.

For JavaScript-heavy sites, an analysis of the JS bundle. What's in it. Which libraries are large. What's loaded but never used.

We use @next/bundle-analyzer for Next.js sites, vite-bundle-visualizer for Vite. The output is a treemap of the bundle. Common findings:

• Moment.js shipping 70KB when date-fns would do
• A charting library bundled on every page but used on one
• Polyfills for browsers nobody uses anymore
• A heavy CMS preview library bundled into production

5. Server-side performance.

For dynamic sites, time-to-first-byte (TTFB) often dominates everything else. A 1.5s TTFB means the page can't be fast even if everything client-side is perfect.

We look at:

• Database query timing (slow queries in the request path)
• Cache hit rates (Vercel Edge, Cloudflare, application cache)
• Cold-start frequency on serverless
• Memory pressure or CPU saturation on long-running servers

This is the part of the audit that often surprises clients. They've spent months optimising images and JavaScript, but the page hangs for 800ms before a single byte arrives.

6. Network and CDN behaviour.

Where are users actually located, and where are the assets served from? A site hosted in us-east-1 serves European users with 150ms of network latency on every request. A CDN flattens this; not having one is a common, fixable problem.

We check:

• Static asset CDN caching headers
• Image CDN behaviour (is /image.jpg?w=400 actually served from cache?)
• HTML caching (most dynamic pages can be cached for 5-60 seconds without anyone noticing)

7. Perceived performance.

The metrics so far are quantitative. Perceived performance is qualitative: does the site feel fast? Are there layout shifts that catch the eye? Is the loading state visible long enough to be jarring? Do interactions feel responsive, or is there a delay between click and feedback?

We do this manually. Open the site in a fresh browser, throttle to a mid-tier mobile profile, use it for ten minutes. Note what feels wrong.

Perceived performance often diverges from measured performance. A site with great Lighthouse scores can still feel slow because of one specific interaction. A site with worse scores can feel fast because the slow parts are off-path for the typical user.

What the audit usually finds

Patterns we see repeatedly:

The hero image is the largest performance cost. Often loaded as an oversized JPG or PNG, no srcset, no priority hint. Switching to WebP/AVIF, adding srcset, and adding fetchpriority="high" typically shaves 1-2 seconds off LCP on mid-tier mobile.

Web fonts block rendering. The page is invisible for 500-800ms while a custom font loads. Fix: font-display: swap (worse FOUT, much better LCP) or a system font fallback that matches the custom font's metrics closely enough to avoid layout shift.

Third-party scripts add a lot of weight. Analytics, chat widgets, A/B testing tools, customer support chat. Each one is "just a small script." Add them up and you have 800KB of third-party code loading on the homepage.

The bundle is twice the size it should be. Moment.js when date-fns would do. Lodash imported as a whole instead of by function. UI libraries imported as entire packages instead of named imports. A 30-minute pass with the bundle analyser usually drops the bundle by 30-50%.

The TTFB is bad and nobody knew. The team has been optimising the front end, but the API serving the page takes 800ms because of a missing index on a database query. One index, one deploy, the site is twice as fast.

There's no CDN, or the CDN is misconfigured. Static assets are served from the origin. Images aren't cached. The CDN exists but the cache headers are wrong, so it caches nothing. Fix: review the cache headers, set them properly, watch the origin's request count drop by 90%.

A real audit and what changed

A few months ago a team came to us asking for a redesign. The site felt slow, the conversion was bad, the team had spent months tweaking it without results.

We ran the audit instead. The findings, in order of impact:

1. The hero image was a 1.4MB PNG. WebP version was 180KB. LCP dropped from 4.8s to 2.1s. One file change.
2. The custom font was loading without font-display: swap. The page was invisible for 700ms while it loaded. Adding the line dropped time-to-first-content significantly.
3. The site had a 600KB JavaScript bundle on every page. Bundle analysis revealed a charting library that was used on exactly one internal admin page. Code-split it. Bundle dropped to 220KB.
4. The blog index was making a separate API call per blog post to fetch author info. 30 posts, 31 requests. Combined into one query. Page-load time on the blog index dropped from 3.2s to 0.9s.
5. The site had no CDN. Static assets were served from the origin in a different region from most users. Added Cloudflare in front. Asset load times improved across the board.

The audit took five days. The fixes took another five days. The total cost was a fraction of what a redesign would have cost. The site felt twice as fast and converted noticeably better. We never did the redesign.

That's the case for the audit. About 30% of the time we audit a site, the result is "no redesign needed, just fix these five things." The other 70%, the audit reveals what to prioritise during the redesign so the redesign actually fixes the problem.

When you'd skip the audit

Rarely, but it happens:

• The site is fundamentally broken architecturally and a measured audit would just confirm what everyone already knows. Sometimes the WordPress with 47 plugins doesn't need an audit; it needs a rebuild.
• The brand has changed and the redesign is for brand reasons, not performance reasons. The audit is still useful but not blocking.
• The site is so small (a single landing page) that a thirty-minute Lighthouse run is the whole audit.

Otherwise: audit before redesign. Every project we've shipped where we skipped this step had a moment six weeks in when we wished we hadn't.

What you get from the audit

The deliverable is a written report:

• Executive summary: top three findings and recommended actions
• Detail per measurement category (Lighthouse, CrUX, waterfall, bundle, server, network, perceived)
• Prioritised list of fixes with estimated effort and expected impact
• A recommendation: redesign needed, redesign not needed, or redesign needed for some pages but not others

A one-week project. Real numbers. Honest recommendation, even when the honest recommendation is "you don't need to hire us for the redesign."

If you're staring at a site that feels slow and wondering what to do, see how we work on redesign and support. Sometimes the answer is the audit. Sometimes it's the redesign. We'll tell you which.