Short answer
A project moves through four stages: audit (measure the site), diagnose (explain causes and rank fixes), optimize (make agreed changes on staging and release them in small steps) and measure (retest and follow field data). We plan for one to two weeks for the audit and three to six weeks for audit plus fixes on a typical small business site.
Stage 1: Audit
We start by measuring. Where your site has enough traffic, we read real-user data from the Chrome UX Report through PageSpeed Insights and Search Console. Field data in PageSpeed Insights covers the previous 28 days [1], so it shows what visitors have been experiencing, not just today. Then we run lab tests on your key templates under consistent settings, with CPU throttling to approximate mid-range phones [2].
What we need from you: the pages that matter most, read access to Search Console if you have it, and temporary access to the site or platform admin, shared in a safe way that we agree with you.
Stage 2: Diagnose
Measurements tell you that something is slow; diagnosis tells you why. For each template we trace the causes behind each metric, for example which LCP subpart is too long [3] or which scripts occupy the main thread after a tap [4]. We turn the findings into a ranked list of fixes with rough effort, and explain any risks, such as tracking that depends on a script.
What you get: the written audit report. We talk it through with you and agree which fixes to do, and who will do them.
Stage 3: Optimize
We make the agreed changes on a staging or preview copy first, where the platform allows it, and test the features each change could affect: navigation, forms, search, checkout, consent tools and tracking. Then we release changes in small groups so that, if anything unexpected happens, it can be traced to one change and reversed quickly. Every change goes into a written log.
What we need from you: a list of the tools and events that must keep working, and someone who can confirm that key features behave as expected after release.
Stage 4: Measure
Lab tests confirm straight away whether each change worked. Field data takes longer to catch up because of its 28-day window. If Search Console flagged a group of URLs, we start validation after the fix; the report then runs a 28-day monitoring session to check for the issue [5]. We book a follow-up check about four weeks after release and send you a comparison against the starting point.
What you get: before and after measurements, the change log, and notes on keeping the site fast, such as image upload rules and how to check new plugins or tags.
Timings we plan for
| Stage | What we plan for | What can change it |
|---|---|---|
| Audit and diagnosis | One to two weeks | Number of templates, speed of access |
| Fixes | Two to four weeks | Number of fixes, platform limits, testing needs |
| Field data follow-up | About four weeks after release | The 28-day field data window |
Larger stores and sites with many third-party tools take longer, and we will say so in the quote.
Communication
You get one named contact for the project. We send a short written update at the end of each stage and whenever something unexpected comes up. If we find a problem outside the agreed scope, we stop and explain it before doing anything about it. First contact is by email; calls can be arranged once a project is under discussion.
After the project
Speed tends to drift as sites change. You can keep the gains yourself using the notes we provide, or add performance monitoring so someone checks the site on a schedule.
Questions about the process
Do you need full admin access?
For the audit, read access and Search Console access are often enough. For fixes, we need access to whatever will be changed. We agree a safe way to share it; please never send passwords by email.
Will my site go down during the work?
Changes are tested on staging first and released in small steps, which keeps the risk low. If a release causes a problem, it is reversed straight away.
Can my developer do the fixes instead?
Yes. The audit report is written so another developer can act on it, and we can review their changes if that helps.
Sources
Opened and checked on November 3, 2026.
- About PageSpeed Insights, Google for Developers. Primary documentation, last updated October 21, 2024.
- Throttling, Chrome DevTools documentation. Primary documentation, last updated April 16, 2024.
- Optimize Largest Contentful Paint, web.dev. Primary documentation, last updated March 31, 2025.
- Optimize Interaction to Next Paint, web.dev. Primary documentation, last updated September 2, 2025.
- Core Web Vitals report, Search Console Help. Primary documentation, checked November 3, 2026.