Speed is not a score. It is a chain of events, each with its own duration and its own cause. We break the whole chain apart, find where the time goes and recover it where it actually matters.
A laboratory test runs a page in a controlled environment: a simulated device, a simulated network, a single load. It is reproducible, so it is useful for comparing before and after a change. It does not tell you what your people experience.
Field data comes from real visitors' browsers, on their phones, on their connections, with their extensions installed. This is the data Google uses for ranking. A site can look immaculate in the lab and poor in the field, usually for three reasons: most traffic comes from mobile, a significant share of visitors are first time and have nothing cached, and a third party script behaves differently under real load.
We work with both. The field sets the priority, because it says what actually hurts. The lab establishes the cause, because it can be reproduced and isolated.
Every stage between clicking a link and a usable page has a cost. We measure them separately, because optimising the wrong stage produces nothing.
| Stage | What we measure | What we correct |
|---|---|---|
| DNS resolution | Time to first response, number of DNS providers queried | A fast DNS provider, fewer distinct domains, preconnect where justified |
| Connection and TLS | Negotiation duration, protocol version, session reuse | HTTP/2 or HTTP/3, TLS session resumption, removing redirects that force reconnection |
| Time to first byte | Separately for cached and uncached pages | Page cache, object cache, slow queries, PHP version, distance to the user |
| Render blocking | Which CSS and JS files stop display, and for how long | Critical CSS delivered inline, the rest deferred, non-essential scripts moved off the critical path |
| Largest contentful paint | Which element it is, how long it takes, what delays it | Preloading the correct resource, sizing the image, eliminating chained request waterfalls |
| Interaction delay | How long until the page responds to the first tap or press | Reducing main thread work, breaking up long tasks, delaying third party scripts until interaction |
| Layout stability | How much content jumps during load and because of what | Explicit dimensions on images and iframes, space reserved for ads and banners, fonts loaded without shift |
| Fonts | Number of families, weights, formats, display behaviour | Only the weights actually used, modern format, character subsetting, display without invisible text |
| Images | Transferred size against displayed size, format, load timing | Modern format, multiple sizes per screen, deferred loading below the fold but never for the main image |
| Third party scripts | Every external domain, what it brings, what it weighs, how long it holds the main thread | Removing unused ones, delaying non-essential ones, moving tracking somewhere it does not block |
| Database | Slow queries, bloated tables, excessive autoload, scheduled tasks | Indexing, cleanup, moving heavy tasks out of the visitor request |
When somebody says "we added caching", they usually mean just one of the layers below. They do not substitute for one another.
Stores the already generated HTML, so PHP no longer runs on every visit. The single biggest win for a site with mostly static content. The delicate part is invalidation: what gets cleared when you publish, when a price changes, when a user is logged in.
Holds database query results in memory. It matters enormously for the areas page caching cannot cover: baskets, accounts, filters, anything personalised per user. Redis, configured properly and monitored, not merely switched on.
At the PHP level, it avoids recompiling the same files on every request. Often left on defaults, which are too small for a WordPress site with many plugins. We size it after measuring how much memory is actually requested.
Copies of content in data centres near the visitor. With Cloudflare included in the subscription, we configure what is cached at the edge, for how long, what bypasses it and how it is purged on publish. For a visitor far from your server the difference is hundreds of milliseconds.
Files already downloaded are not requested again on a second visit. It depends entirely on correct headers and versioned filenames. Done badly, it is either never used at all, or it serves visitors a stale version for days after you publish a change.
Expensive results stored temporarily by WordPress and by plugins: exchange rates, feeds, responses from external APIs. When they expire badly, one unlucky visitor pays the wait for an external call. We identify them and move them into the background.
We do not switch on every option in a caching plugin to produce a higher score. Aggressive file combining, automatic removal of unused styles and blanket JavaScript deferral can look excellent in a test and break the checkout form in a particular browser. Every option is enabled separately, tested against the site's real flows, and then kept.
Every page under management, on mobile and desktop, in the lab and in the field. Results are saved, so there is a real reference point rather than a memory.
A change that cuts 40 milliseconds is not worth the risk if another cuts 900. The order is set by numbers, not by what is easiest to tick off.
One change at a time, so the effect is attributable. Critical flows are checked by hand: forms, basket, login, search.
The same pages, the same conditions. If the difference is not confirmed in production, the change is withdrawn.
Performance degrades on its own: an image uploaded without resizing, a new plugin, a tracking script added by somebody in marketing. Continuous measurement catches that in days rather than months.
What changed, how much it gained, what remains and why. No screenshots of green dials and no conclusions you cannot verify yourself.
Not necessarily. That score comes from a laboratory test, on a single simulated device, on a single page, at a single moment. For ranking, Google uses field data, meaning what your real users experience on their phones and their connections. We have seen sites with 100 in the lab and poor field data, and the reverse.
It solves one layer, page generation, and we configure it carefully. It does not touch image sizes, render blocking, font behaviour, third party scripts, layout stability or interaction delay. Caching makes the page arrive quickly. It does not make it fast once it has arrived.
Technical changes show immediately in the lab. The field data Google uses is calculated over a rolling 28 day window, so official reporting settles after roughly a month. Your visitors feel the difference from day one.
Every change is made on staging first, with a measurement before and one after. If a result does not justify the risk, we do not keep it. All changes are version controlled, so reverting is immediate.
Up to a point. If the server responds in 1.2 seconds on an already cached page, no amount of front end work compensates. We measure and tell you with figures exactly how much of the problem is the hosting and how much can be won without changing it.
Send us your website address. We measure it and show you concretely what is slowing it down, with figures you can verify yourself.