Web performance audit: what your agency must measure (and improve)

There's an uncomfortable moment that repeats with many clients: they arrive with a slow website or with problems, and when we ask to see the last "audit" they had done, they pull out a PDF with a PageSpeed score and some generic tables. That's not a performance audit: it's a smoke certificate.

A web performance audit that's worth what it costs is a deep job, with real measurements, cause diagnosis and a prioritized plan. In this article I explain what an audit like that must really include, so you know how to demand it from your agency — or know if you're the one who needs it.

What a performance audit is NOT

Before saying what it is, let's go with what it isn't, because that's what's sold the most:

• It's not a PageSpeed Insights score. That score is a clue, not a diagnosis. You can have 95 and serious problems, or 70 and be very good.
• It's not a generic PDF with textbook recommendations that work for any website.
• It's not measuring once. Performance varies; a one-off measurement is a photo, not a movie.
• It's not saying "change hosting" as a universal solution. Sometimes it is, sometimes it isn't.

If what they gave you falls into any of these categories, you didn't pay for an audit: you paid for a piece of paper.

How it's really measured

Measuring with field and lab data

A serious audit starts by measuring, and it measures at two levels:

• Field data: your users' real metrics: Core Web Vitals (LCP, INP, CLS) collected by Google in Search Console. It's the source of truth: it's what Google uses to rank.
• Lab data: PageSpeed Insights, GTmetrix or Lighthouse, which simulate loading in controlled conditions and help reproduce problems.

The combination of both makes it possible to distinguish, for example, whether your website really goes badly or only "in the test". And that distinction completely changes the work plan.

Field measurement: the source of truth almost nobody looks at

There's a tool everyone has and almost nobody uses for performance: Google Search Console. In its Core Web Vitals report, Google shows you how your website does on your users' real devices and browsers. It's not a simulation: it's field data, for real.

Why does it matter so much? Because lab data (PageSpeed) simulates a specific connection and device, and sometimes doesn't reflect your reality. Field data tells you what 75% or 90% of your visitors truly experience. It's the difference between measuring your speed "in theory" and measuring it "on the street".

A serious audit always starts with field data and uses the lab to reproduce and confirm. If an agency presents you a performance report without looking at Search Console, it hasn't gone to the source of truth.

From symptom to cause

The diagnosis of causes, not symptoms

Here's the difference between an amateur and a professional: the amateur describes the symptom ("your website takes 4 seconds"); the professional finds the cause ("you take 4 seconds because the server responds in 900ms, the main image weighs 3MB and there are 40 third-party scripts").

A serious audit breaks down the load time into its components:

• Server time: how long the hosting takes to respond.
• Weight of the resources: images, CSS, JavaScript, fonts.
• Number of requests: how many downloads the browser makes.
• Third-party resources: analytics, pixels, chatbots, maps. Each one adds up.
• Rendering: what blocks the page's paint.

Only when you know where each second goes can you prioritize. And prioritizing is the next step.

What a "bottleneck" is and why there's almost always one

In web performance there's a key concept: the bottleneck. Your website's speed isn't marked by the average of its parts, but by the slowest part. You can have perfect images and optimized code, but if the server takes 900 milliseconds to respond to each request, everything else doesn't matter: the website will be slow.

The job of a performance audit is to find that concrete bottleneck. Not "your website is slow" (that's the symptom), but "your website is slow because X". And the typical bottlenecks are very recognizable:

• Server: high TTFB (the time the server takes to start responding). It affects everything.
• Images: a disproportionate weight that lengthens the download. It's the most common.
• Third-party scripts: analytics, pixels, chatbots, players. Each one adds time.
• Web fonts: badly loaded fonts block the visible text.
• JavaScript: scripts that block the page's rendering.

A good report tells you what your main bottleneck is and proves it with data. That's the difference between an audit and a certificate.

Beyond speed: the complete audit

Performance isn't just "load seconds"

When people think of performance, they think of "how long it takes to load". But there are more factors that determine the perceived experience, and a complete report covers them:

• Interactivity: it's not enough that it loads fast; it has to respond to the click. (The INP metric.)
• Visual stability: layout jumps on load are terrible for the experience. (The CLS metric.)
• First impression: how long it takes to see "something useful", even if the page isn't complete.
• Mobile data usage: a website that weighs 8 MB ruins the mobile experience of someone with limited data.

All these are conversion factors. A website that takes time but "doesn't show it" because it displays content gradually can be perceived better than one that stays blank and appears whole at 4 seconds. That's why fine diagnosis matters.

Accessibility

A fast website that people with disabilities can't use is also a website that penalizes in SEO. The report must check: contrast, alt texts, keyboard navigation, heading structure. It's not optional: it's a quality factor and an increasingly present obligation.

Technical SEO

Performance and SEO are intertwined. The audit must review structure, URLs, canonicals, structured data and indexing, because a fast website with a bad structure doesn't rank either. If you want to go deeper, I recommend our article on SEO and structured data.

Basic security

A fast, well-ranked site that's vulnerable is a deferred problem. The audit must check the essentials: certificate, updated versions, basic headers, exposures. Security is part of a website's overall health.

Mobile experience

Today more than 60% of traffic comes from mobile. The audit must measure performance on mobile as a priority, not as an addition: that's the experience most of your users live.

The deliverable worth money: the prioritized plan

Everything above leads to the main deliverable: a prioritized action plan. A list of 50 improvements ordered alphabetically is useless. What works is:

• Impact: which fix improves the experience the most with the least effort.
• Effort: how much each change costs (time and money).
• Priority: what's done first, what can wait and what isn't worth it.

A good report tells you: "start with this, which takes away 2 seconds; this other thing doesn't matter; this is for a few months from now". That's what lets you spend your money well.

The report, the before and the after

Measuring the before and the after

An audit doesn't end with the report: it ends when the improvements are applied and it's measured again. The correct flow is:

1. Measure the initial state with field data.
2. Diagnose and prioritize.
3. Apply the improvements.
4. Re-measure and document the real improvement.

Without that last step, the audit is an expense, not an investment. The goal isn't the report: it's the measurable result.

How a good report is delivered

We've already talked about the prioritized plan, but it's worth detailing how the report is presented so it's truly useful. A good deliverable includes:

• Executive summary: in one page, what's happening to your website and what should be done. So management understands it.
• Data with screenshots: the measurements, with proof that they're real and when they were taken.
• Technical diagnosis: the concrete findings, with the cause of each problem.
• Prioritized action plan: expected impact, effort and order.
• Cost estimate if the agency is going to execute the plan.

And an important detail: the report should be written so you understand it, not to impress other technicians. If you don't understand what's happening to your website after reading the report, the report has failed.

How often is it done?

Performance isn't a permanent state: it degrades over time (updates, new plugins, heavier content). The recommendation is a performance audit every 6-12 months, or when you notice the website going worse. In between, light maintenance avoids degradation.

It's like the car inspection: you do it before it fails, not when you're already on the shoulder.

How much it costs and what to demand

The price of an audit: what's reasonable

It's the million-dollar question. Performance audits vary a lot in price depending on the depth and size of the project. As a general guide in 2026:

• Basic (metrics and diagnosis): €150 - €400. It tells you what's happening and what to do.
• Complete (field measurement, diagnosis, plan and execution of improvements): €500 - €2,000 depending on the website.
• Integrated into a larger project: usually included in the development or maintenance budget.

The key isn't the absolute price but the relationship with what you're going to gain: if the audit tells you how to recover speed (and with it sales and positions), it pays for itself. Distrust "free" audits: they're usually the hook to sell you a list of generic services.

Web performance is measurable, diagnosable and improvable. There's no excuse for the "smoke certificate". When you ask for an audit, demand field data, concrete causes and a prioritized plan with before and after measurement. If what they offer isn't that, it isn't an audit.

At TakeYourDesign we do complete performance audits, with real data and an actionable plan. We're not going to sell you improvements that don't add value: we're going to tell you what's worth it and what isn't. If you want to know how your website really is, check out our audit service or write to us.