Website Speed Audits

What an audit answers

Most site owners arrive with a symptom rather than a diagnosis: the home page feels sluggish on a phone, a score dropped after a redesign, or Search Console flags a group of URLs as poor. An audit turns that symptom into specific causes. It answers three questions in order. Which pages are slow for real visitors, and on which devices? What, exactly, makes each of those pages slow? Which fixes are worth doing first, given the effort involved?

Real-user data first

Lab tests are useful, but they are not what your visitors experience. PageSpeed Insights shows field data from the Chrome User Experience Report alongside its lab results, and Google describes the lab data as "based on a simulated load of a page on a single device and fixed set of network conditions" ^[1]. Field data covers the previous 28 days of visits from real Chrome users ^[1].

Not every site has field data. CrUX includes pages and origins that are publicly discoverable and "sufficiently popular", and Google does not publish the visitor threshold ^[2]. Visits from Chrome on iOS are not included ^[2]. When your site has no field data, we say so in the report and lean on lab testing across realistic device settings instead, rather than presenting lab numbers as if they were real-user results.

What we test and read

We pick the templates that matter: typically the home page, a key landing or service page, a product or article page, and any page with a form or checkout. For each one we record the Core Web Vitals and the supporting measurements, then trace the causes:

• the Largest Contentful Paint element and its four subparts, from server response to render delay, as web.dev breaks them down ^[3];
• long tasks and event handlers that slow responses to taps and clicks ^[4];
• images, embeds and late-loading content that shift the layout ^[5];
• third-party tags, tag manager containers and app scripts ^[6];
• caching headers, compression and whether pages can use the back/forward cache ^[7].

What the report contains

The report is written for two readers at once: you, who need to know what matters and what it will cost, and whoever will make the changes, who needs specifics. Each finding has a plain-English summary, the evidence (a measurement, a trace or a file name), the likely effect, and a suggested fix with rough effort. Findings are ranked, so the first few items are the ones most likely to move your field data.

How long it takes

We plan for one to two weeks from receiving access to delivering the report, depending on how many templates are in scope. We need read access to the site, and for the deeper parts of the audit, temporary access to hosting or the platform admin. We will agree a safe way to share access; please never send passwords by email.

What an audit does not include

The audit itself does not change your site. Fixes are a separate, quoted step, so you can decide what to do and who should do it. We also do not promise a particular score. Lab scores vary between runs, and Chrome's documentation notes that "a lot of the variability" in a Lighthouse performance score "is not due to Lighthouse" ^[8]. What we can promise is a clear explanation of what to change and why.

How findings are ranked

A long list of issues is not much help on its own; most automated reports produce dozens. What matters is which few changes will move your field data. We rank each finding by three things: how much of the failing metric it explains on the templates that carry the most traffic, how much effort it takes, and how much risk it carries for features and tracking. A fix that removes a full second of resource load delay on the product template ranks above a fix that saves a few kilobytes on the privacy page, however easy the second one is.

Each finding also says which metric it affects. Search Console gives a group of URLs the status of its worst metric ^[9], so a report that improves LCP while ignoring a failing INP can leave the group exactly where it was. The ranking keeps every failing metric in view.

Who the audit is for

An audit suits three kinds of situation. You have a warning in Search Console and want to know what it means and what it will take to fix. You are about to invest in speed work and want to spend the budget where it counts. Or you have a developer or agency already and want an independent, evidence-based list of what to change. In each case, the value is the same: knowing the causes before paying for fixes.

What happens after the audit

We walk you through the report and answer questions, by email or on a call once a project is under discussion. You then choose what to do. You can ask us to quote the fixes, give the report to your own developer, or do nothing for now. If you go ahead with fixes, the audit's measurements become the baseline we compare against, so you can see exactly what changed. If you choose your own developer, we can review their changes before release if you would like a second pair of eyes.