We measured 22 UK roofing websites on a phone. The median took 6.9 seconds.
A throttled measurement of 22 real UK roofing homepages. The median took 6.9 seconds to show its main content, and only two let you enquire without scrolling. Full method, per-site data and caveats included.
There is no shortage of advice telling trades businesses their website should be faster. There is almost no published data on how fast those websites actually are. So in September 2026 we measured 22 of them, under the same conditions Google uses to grade a page on a phone, and wrote down everything.
The short version: the median homepage took 6.9 seconds to show its main content. Google considers anything over four seconds poor. Eight of the 22 took longer than ten seconds. One took just over thirty.
But the load times turned out to be the less interesting half of the result. The thing that surprised us was how few of these sites give a visitor any way to make contact without scrolling first.
How this was measured
Every site was loaded once in real Chrome on a simulated iPhone viewport (390 × 844), with the network throttled to slow 4G — 1.6 Mbps down, 150 ms latency — and the processor slowed four times. That is Lighthouse's standard mobile configuration, the same one behind the score in PageSpeed Insights. Homepage only, one load per site, no repeat visits and no warm cache.
The sample is 22 UK roofing companies drawn from ordinary search results across Leeds, Manchester, Birmingham, Nottingham, Glasgow and Belfast, taken in the order they appeared. We excluded directories and lead-generation aggregators, since those are not the businesses we are describing. No site was dropped after measurement, and nothing was retried to get a better number.
Finding one: the median site takes 6.9 seconds
The spread matters more than the median. These sites do not cluster around a mediocre average — they split into a group that is genuinely fine and a group that is unusable on a phone, with very little in between.
Three sites came in under Google's 2.5-second bar, and the fastest was a single 20 KB page that loaded in 1.5 seconds flat. At the other end, the slowest site pulled 5.19 MB and took 30.6 seconds to show its main content. On a real phone on a real 4G connection, almost nobody waits that long.
Finding two: only two sites let you enquire without scrolling
This is the result that actually matters, and it is worse than the speed numbers. Of 22 homepages, two had an enquiry form visible without scrolling. Twelve had no form anywhere on the homepage at all. Eight had neither a form nor a tap-to-call link in the first screen, meaning a visitor who lands on the page has no way to make contact until they scroll and go looking for one.
| Above the fold on a phone | Sites | of 22 |
|---|---|---|
| Tap-to-call phone link | 14 | 64% |
| Some call to action | 16 | 73% |
| Enquiry form | 2 | 9% |
| Neither form nor phone | 8 | 36% |
The median site carried 27 navigation links in its header, and one carried 62. That is the underlying pattern: these are brochure sites built to describe a company, offering a visitor a menu of places to wander, at the exact moment that visitor wants one thing — a price, or a person to speak to.
Where forms did exist, the median asked for six fields and the longest asked for ten. Every additional field on a mobile form costs completions, and ten fields on a phone, below the fold, after a nine-second wait, is close to a worst case.
What these sites get right
Two things, and it would be dishonest to leave them out. Layout stability was genuinely good: the median Cumulative Layout Shift was 0.015, comfortably inside Google's 0.1 threshold, so content is not jumping around as it loads. And server response was rarely the problem — median time to first byte was 579 ms.
That second number is the important one, because it tells you where the fault lies. These servers answer reasonably quickly. The seconds are lost afterwards, in what the page then chooses to download.
Does page weight explain it?
Largely, yes. Across the sample, page weight and load time correlate at r = 0.69, which is a strong relationship for field data. The fastest six sites had a median weight of 0.41 MB; the slowest six had 1.91 MB, roughly four and a half times as much.
It is not the whole story — one site managed 7.6 seconds on only 0.7 MB, and another rendered 1.5 MB in 2.1 seconds — but the pattern is clear enough. Weight is the lever most of these sites are pulling in the wrong direction, usually through uncompressed hero photography, and a request count that ran to a median of 70 and a maximum of 190 separate round trips.
The full data
All 22 sites, sorted by load time. Two sites are shown without a weight figure: their resource timing was not exposed to the browser, so we have no honest number to report and have left it blank rather than guess. Weight statistics above use the remaining 20.
| Site | Load | Weight | Requests | Form in first screen | Tap-to-call | Form fields |
|---|---|---|---|---|---|---|
| A | 1.5s | 0.02MB | 2 | No | No | — |
| B | 2.0s | 0.42MB | 21 | No | Yes | — |
| C | 2.1s | 1.50MB | 75 | No | No | — |
| D | 2.8s | 0.90MB | 64 | No | Yes | 8 |
| E | 2.9s | 0.39MB | 11 | No | No | — |
| F | 3.2s | 0.08MB | 10 | No | No | — |
| G | 3.5s | 0.70MB | 98 | No | Yes | — |
| H | 3.8s | 0.89MB | 97 | No | Yes | — |
| I | 4.3s | 0.80MB | 92 | Yes | Yes | 1 |
| J | 4.4s | 0.56MB | 35 | Yes | Yes | 8 |
| K | 6.8s | 2.80MB | 42 | No | Yes | — |
| L | 7.1s | 1.98MB | 190 | No | Yes | 5 |
| M | 7.6s | 0.70MB | 46 | No | No | — |
| N | 9.5s | — | 64 | No | Yes | 10 |
| O | 11.3s | 1.99MB | 138 | No | No | 9 |
| P | 12.8s | — | 91 | No | Yes | 4 |
| Q | 13.1s | 0.68MB | 62 | No | No | — |
| R | 15.4s | 1.69MB | 85 | No | No | — |
| S | 18.5s | 0.77MB | 63 | No | Yes | 4 |
| T | 18.6s | 2.13MB | 173 | No | Yes | 7 |
| U | 20.6s | 2.92MB | 109 | No | Yes | 5 |
| V | 30.6s | 5.19MB | 93 | No | Yes | — |
What we take from it
The speed problem is real and it is fixable, but it is downstream of a more basic one. A site that takes nine seconds to load and then hides its enquiry form three screens down is not suffering from a performance problem. It is suffering from being built to describe a business rather than to convert an advert.
- Nearly two thirds of these sites fail Google's own mobile speed bar, and over a third take more than ten seconds.
- Nine per cent give a visitor a form before they scroll, and over half have no form on the homepage at all.
- The servers are fine. The weight is not, and neither is the structure.
If you want to know where your own site sits against this, paste it into PageSpeed Insights and look at the mobile tab. That is the same test, run by Google rather than by us, and it costs nothing.