The State of UK Trades Websites 2026

The headline figures

Three measurements and the sample behind them. Each measurement is a median or a share, carries the number of websites behind it, and was recalculated inside both collection waves before it was allowed here. The lead measurement is how long the largest visible content element during loading took to appear in the mobile Lighthouse test — Lighthouse calls it Largest Contentful Paint, and the rest of this report calls it LCP.

Key findings

We requested a Lighthouse audit for 43,738 UK trades business websites, once as a mobile test and once as a desktop test. 31,030 returned a usable result on at least one of the two. Each finding below carries the number of websites that returned that particular measurement; those counts differ from one another, and none of them is 43,738. Every figure here was recalculated inside each collection wave separately, and anything that did not hold across both was left out.

1. Half of the 30,399 websites with a mobile LCP took 6.7 seconds or more for their largest contentful element to render. That is a median, not an average: half were slower still. 72.5% of them took over 4 seconds.
2. The same websites are slower on mobile than on desktop, almost without exception. Of the 29,969 websites that returned an LCP on both devices, 99.5% recorded a higher one under the mobile strategy, a median of 5.1 seconds apart. Of the 29,965 scored on both, 87.5% scored lower on mobile, a median of 18 points apart. These compare each website against itself rather than one population against another.
3. Across all returned scores, median Performance was 67 on mobile (30,397 websites) and 90 on desktop (30,481). Those are different cohorts, which is why the within-site comparison above is the stronger evidence of a device difference.
4. Sorted into Lighthouse's own bands, 15.7% of the 30,397 websites with a mobile Performance score sit in “good”, 73.6% in “needs improvement” and 10.7% in “poor”. The middle band holds roughly three websites in four.
5. 12,708 of the 43,738 websites attempted returned no usable automated audit on either device, equal to 29.1% of those attempted. That is a failed measurement, not evidence of a broken website. Some attempts failed on our side of the request and others were reported by the audit service as pages it could not load or render; the retained data does not establish the underlying reason for each failure. Those websites remain in the dataset but do not contribute to performance measurements they did not return.
6. Platform differences were visible, but they are not causal. We identified a platform for 19,359 websites, or 44.3% of those attempted. Among identified sites, median mobile Performance was 61 for WordPress across 9,869 websites and 69 for Wix across 5,031. That is an observed difference between two groups of websites, not evidence that either platform caused the result.

About the dataset

This is the first edition of an annual study, and dataset 2026-09.2 is the version every figure on this page was produced from. Between 2026-07-30 and 2026-09-01 we requested a Lighthouse audit for 43,738 UK trades business websites, found through listings on a UK business directory, once with Lighthouse's mobile test and once with its desktop test. 31,030 returned a usable result on at least one of the two.

1. The dataset narrows at every step, and the steps are not interchangeable. 30,557 websites returned at least one mobile category score and 30,608 at least one desktop score. These device-specific cohorts overlap, but they are not identical. Narrower still are the individual measurements: 30,397 websites returned a mobile Performance score and 30,399 a mobile LCP. 43,738 is the number of websites we attempted, and it is the denominator of none of them.
2. 12,708 websites, 29.1% of those attempted, returned no usable automated audit on either device. They stay in the dataset and in the row-level download, and they contribute to no measurement. A failed automated audit is not evidence that a website is broken.
3. Collection ran in two near-disjoint passes: 23,525 websites in the first, across 183 towns and cities, and 20,213 in the second, across 18. The two waves differ in date, city set and trade mix at once, so a difference between them cannot be separated from the way the data was gathered. Every figure in this report was therefore recalculated inside each wave before publication, and anything that did not hold across both was left out.
4. A platform could be identified for 19,359 websites, 44.3% of those attempted. Detection was a separate request to each homepage rather than part of the audit, so a website that answered neither request appears in neither count.

How slow is slow on a phone

LCP is the measurement this chapter is built on: how long the largest contentful element on the page took to render. Below is the whole spread behind the median in the headline figures, with Google's published LCP reference thresholds marked on it.

1. Half of the 30,399 websites with a mobile LCP took 6.7 seconds or more, and 72.5% took over 4 seconds. Both figures were recalculated inside each collection wave before they were published, and both held.
2. A single figure is a poor summary of a spread this wide, which is why the chart shows all of it and the table beneath the chart gives the percentiles. The distribution has a long right tail: the axis is capped so the bulk of the data stays legible, and the websites beyond the cap are counted on the chart rather than hidden by it.
3. The 2.5-second and 4-second lines are Google's published LCP reference thresholds. Here they are reference points for interpreting a laboratory result and nothing more: not a pass or fail certification, not a claim about search rankings, and not a measurement of what visitors to these websites experienced.
4. These are laboratory measurements. The absolute numbers describe the test rather than any particular visitor's connection. The main comparisons in this report were collected through the same PageSpeed Insights request pattern within the same five-week window, and the headline figures used here also held when the two collection waves were recalculated separately. The exact service-side device and network conditions were not retained.

The four Lighthouse categories, in Lighthouse's bands

Lighthouse returns four category scores, not one, and each is scored out of 100 and sorted into the same three bands. Performance is the category this report leads on. The other three are checklists of things Lighthouse can test on the page, and they sit in quite different places.

1. On mobile the median Performance score is 67 across 30,397 websites, against 89 for Accessibility (30,557 websites), 81 for Best Practices (30,538) and 92 for SEO (30,545). Each category has its own cohort, because a website can return one category's score without returning another's.
2. Performance is also the category with the widest spread. 10.7% of the 30,397 websites with a mobile Performance score sit in Lighthouse's lowest band, 73.6% in the middle band and 15.7% in the highest. The other three categories are drawn on the same bands in the table below; their splits were not tested across the collection waves, so they are shown there and not quoted here.
3. The SEO category is the one most often misread. It is a set of automated checks for a subset of technical and on-page SEO basics that Lighthouse can test, scored out of 100. It is not a ranking score, it does not measure search visibility, and a high score here does not tell us how a search engine ranks the page.
4. Across the 30,481 websites that returned a desktop Performance score, the median is 90. That is a different cohort from the mobile one, which is why the device comparison in the next section is made on the websites that returned a score on both devices rather than by setting these two medians against each other.

Mobile against desktop

The same websites, measured twice. This section compares a website's two results against each other — the same listed URL requested once with PageSpeed Insights' mobile strategy and once with its desktop strategy — rather than setting one population's median against another's. The mobile and desktop cohorts are not the same websites, so subtracting one median from the other would describe no website at all.

1. Of the 29,965 websites that returned a Performance score on both devices, 87.5% scored lower under the mobile strategy, and the median within-site gap is 18 points.
2. Among the 29,969 websites that returned an LCP on both devices, 99.5% recorded a higher LCP under the mobile strategy. The median within-site difference was 5.1 seconds. This is a comparison of one website's two laboratory results, not a measurement of what anyone waited for, and the dataset does not say why the two differ.
3. Those are the four measurements this section quotes, and each was recalculated inside both collection waves before publication. The counts below are sample sizes, not measurements. Everything else is in the table, described rather than quoted.
4. Every metric has its own paired cohort, because a website can return a measurement on one device and not on the other. Performance is paired on 29,965 websites, LCP on 29,969, First Contentful Paint on 30,043, Speed Index on 30,038, and the other category scores on up to 30,135. Read the pair count beside a row, not the size of the dataset.
5. Directions differ between the measurements, so the chart states each one beside the row it belongs to: for Largest Contentful Paint a lower value is the better result, and for the Performance score a higher value is the better result.
6. Two of the paired measurements are not summarised by a median here. Total Blocking Time and Cumulative Layout Shift sit at exactly zero for a large share of websites on both devices, so a median of the within-site gap would report that zero and hide everything either side of it. They are paired in the dataset and in the download, and they are neither drawn nor tabulated here. Two more, Time to Interactive and Speed Index, repeat LCP and First Contentful Paint on a large share of these websites, so they are paired in the dataset but not drawn beside them either.
7. This compares two laboratory tests of the same listed URL, not two audiences. Nothing here says that visitors using a phone experienced the mobile result or that visitors using a desktop experienced the desktop result. Nor does the dataset say why any website's two results differ: page weight, hosting, scripts and layout were not measured, and the conditions the service applied to each test were not retained.

What UK trades websites are built on

This section covers only the websites whose platform we identified in this sample. The results are shown as a table rather than a chart: a row of bars can look like a market-share graphic, and this seeded sample is not one.

1. A platform was identified for 19,359 of the 43,738 websites attempted, 44.3%, and that figure held when the two collection waves were recalculated separately. The majority of websites attempted therefore had no platform identified at all. That group is not a platform: it is the websites where the detector found nothing, and it has its own row.
2. Among those 19,359 websites, 52.9% are WordPress and 26.6% are Wix. Both were recalculated inside each collection wave and held. The other platforms are in the table with their own figures; they were not tested across the waves, so this section does not quote them. The table's “of identified” column is a share of those 19,359 websites and its “of all” column is a share of every website attempted, so read the column heading before lifting a figure out of it.
3. The undetected group is large and it is not a random slice of the dataset. Detection was a separate request to each homepage, so a website that answered neither that request nor the audit appears in neither count, and the websites with no identified platform are disproportionately the websites that returned no measurement either. Every share here therefore describes the websites that answered: a platform unusually common among the websites that did not answer would be under-counted here, on the strength of its answering websites alone.

How the platforms compare

Median mobile Performance by platform, for the websites whose platform we identified. The chart carries the comparison with enough websites on both sides to hold across the two collection waves and after restricting the analysis to stronger platform fingerprints — Wix against WordPress, pooled and then restricted, with both waves' figures marked on each bar. Every other platform is in the table, with the number of websites behind its median and how often its audits failed.

1. Among the websites we identified, the median mobile Performance score is 61 for WordPress (9,869 websites with a mobile Performance score) and 69 for Wix (5,031) — 8 points apart across the 14,900 websites in the two groups combined.
2. Detector strength is not neutral, so the same comparison is made again on firmer ground. Restricted to the websites whose platform was identified from a strong fingerprint, the medians are 60 for WordPress (8,374 websites) and 67 for Wix (3,841), 7 points apart across 12,215. The difference narrows but does not disappear, and all four medians and both gaps held when the collection waves were recalculated separately.
3. Squarespace's median, 54 across 600 websites, also held across the waves. The other platforms' medians are in the table and are not quoted here, because they were not tested across the waves — including the platform with the highest median in the table, which was tested and did not hold. Leaving the top of a table unquoted without saying so would be a choice disguised as a result, so it is said here.
4. Each row carries its own audit-failure rate, and those rates differ materially across the table. A platform whose websites returned a measurement less often is represented in its median by the ones that answered, so read a median beside the failure rate in the same row. The undetected-platform row needs particular caution, because missing platform detection and missing Lighthouse results are related in this dataset.
5. These are differences between groups of websites, and the study cannot say more than that. Nothing was assigned: every business chose its own platform, and businesses that choose one platform can differ from those that choose another in ways this dataset did not observe — budget, who built the site, how old it is, and how complex its content or functionality is. There is no control group and no intervention here. The next section narrows the question by holding the trade constant.

The same trade, different platforms

Comparing platforms across the whole dataset invites an obvious objection: different kinds of business choose different platforms. These comparisons hold the trade constant, which removes one of those differences and not the rest. The chart shows Wix and WordPress in every trade with enough websites on both sides; the table shows every cell.

1. A cell is one platform inside one trade. A cell needs 100 websites before it carries a median, so a trade appears in the chart only where both platforms clear that bar, and the table marks the cells that do not. Every median in the table is published with the number of websites behind it, and those counts differ from cell to cell.
2. Across the 12 trades with enough WordPress and Wix websites for a comparison, the WordPress group has the lower median mobile Performance score in every one: no ties and no reversals. Repeating the test inside each collection wave, and rebuilding the eligible set from scratch each time rather than carrying the pooled one in, the direction holds again — 4 qualifying trades in the first wave and 8 in the second, with WordPress lower in all of them, again with no ties and no reversals.
3. Read that narrowly. The wave sets are smaller than the pooled set and are largely different trades, so this is not the same 12 trades measured twice over. It is not a controlled experiment, it does not show that either platform caused a score, and it says nothing about what would happen to a website that moved from one to the other. What it supports is one narrow point: the difference between the two platforms in the previous section does not appear to be explained by trade mix alone.
4. The individual cell figures — each trade's two medians and the gap between them — were not themselves recalculated inside the waves, so this section quotes none of them. They are in the chart and the table.
5. Holding the trade constant removes one difference between the two groups of websites and leaves the others in place. The businesses inside a single trade still differ in budget, in who built the site, in how old it is and in how complex its content or functionality is, and none of that was observed here. A trade's cells are also drawn from different mixtures of towns and collection waves.
6. So this is a narrower question than the one before it, not an answer to it. Nothing was assigned, there is no control group, and a difference inside a trade remains a difference between the websites in that trade that chose each platform.

Page builders inside WordPress

Page builders sit inside WordPress, so this is a smaller group again. Page-builder detection is only applied to WordPress websites, and a recognised third-party builder was found for only a subset of them. Everything here describes that subset.

1. Among the WordPress websites with a mobile Performance score, the medians are 60 for Elementor (2,972 websites), 61 for Beaver Builder (397), 59 for Divi (1,311) and 57 for WPBakery (951). All four held when the collection waves were recalculated separately.
2. A fifth group sits beside them and is not a page builder. “No third-party builder detected” means exactly that: the detector recognised no third-party builder. It is not evidence that the website used none. The group takes in WordPress’s own native block editor, which the detector reports on some of these websites and not on others, and any builder outside the set of fingerprints it holds. Its median is 65 across 4,058 websites and it held across the waves, but it is reported separately and kept out of the sequence above, because it is a residual rather than a tool anyone chose. Reading it as though it were one would turn an absence of evidence into a product comparison.
3. Two builders are in the table with their sample size and no median: their cohorts fall below the 100 websites this report requires before it publishes one. They are shown rather than dropped, so the table says what exists as well as what can be measured.
4. These are differences between groups of WordPress websites, not effects of the tools. Nothing was assigned; the websites in each group differ in ways this dataset did not observe, and the builder groups are drawn from different mixtures of trades, towns and collection waves. Detection also only recognises the builders it holds fingerprints for, so a website using something it does not know appears in the residual group.

How the page builders compare

The same builders, with the lower and upper quartile beside each median so the spread behind it is visible. The residual cohort is listed last and outside any comparison, for the reason given above.

1. A median is one point in a distribution. The interquartile ranges overlap substantially: the quartile columns show how far each builder’s middle half reaches, and those ranges sit across one another rather than in a line. A website in one group can therefore sit above the median of another, which is why the medians should not be read as clean dividing lines between builders. The quartiles are descriptive figures for this dataset pooled, were not recalculated inside the collection waves, and are not quoted outside this table.
2. Each row also carries its own audit-failure rate and the number of websites behind each figure, and the counts are not the same from column to column: a website can return a Performance score without returning an LCP. Read the count in the row rather than the size of the cohort above it.
3. Nothing in this table is ranked, and no row is a recommendation. These are groups of WordPress websites that differ in ways this dataset did not observe, drawn from different mixtures of trades, towns and collection waves.

How the trades compare

Median mobile Performance by trade, in order of sample size rather than score. The table below is descriptive: it shows what each trade's websites did in this sample, and it is not a league table.

1. No trade-level figure in this report was recalculated inside the two collection waves, so this section quotes none of them. That is a limit of the data rather than an oversight. Trade is the part of this dataset most entangled with the way it was gathered: the two waves covered different towns and different trades, so several trades exist almost entirely inside one of them and a wave test would compare a trade against itself.
2. The trades are nothing like the same size, and the table keeps three tiers apart. 26 trades meet the report's 300-site threshold for ranking, although this section deliberately does not rank them by score. 35 trades hold at least 100 websites and carry a median. 2 fall below that and show their sample size alone. A trade of a few hundred websites and a trade of several thousand do not carry the same certainty, and the table shows the count beside every figure so the difference is visible.
3. 2 of the trades large enough to order were collected almost entirely inside a single wave, so their medians are entangled with that wave's city set, collection design and other cohort differences. The table gives each trade's wave split, its WordPress share and its undetected-platform share in the same row as its median, because those are the mixtures a trade difference would have to be separated from before it could be called a trade difference.
4. Trade labels are the source's own and are not merged. Carpenters and joiners are separate labels here, and so are gardeners and landscape gardeners; combining them would be an editorial judgement about trades rather than a correction to data. One consequence is visible in the table, where a label can sit below the reporting threshold while a close neighbour sits well above it.
5. None of this attributes a score to a trade. A trade's websites differ from another's in platform mix, in who built them, in how old they are, in what the business needs to show, and in which towns and collection waves they were drawn from — none of which this study separated. And this is a seeded sample, so a figure in the table describes the websites of that trade in this sample and never that trade across the UK.

Is there a difference between cities?

Every city with enough measured websites to report, with its sample size. They are not ranked, and the table sits collapsed beneath the note for anyone who wants to look up their own.

1. No city-level figure in this report was recalculated inside the collection waves, so this section quotes none of them. The pipeline also declines to rank cities at all, whatever their sample size, and records that decision in the data rather than leaving it to the writing: the reason given is that the medians span too narrow a range for an order to mean anything.
2. In the pooled descriptive table, that narrowness is the main pattern. Where a city has enough measured websites to carry a median at all, the medians sit close together, and they sit closest among the cities with the largest samples — the ones where a real difference would be easiest to see. The figures are in the table; the point is that there is no city story in this dataset to tell.
3. The sample sizes were set by the collection design, not by the towns. 53 cities have at least 100 measured websites and carry a median; 75 more are listed with their sample size alone; and 56 cities fall below 30 websites and are not listed at all, together holding 786 websites. Only 16 cities reach 300 measured websites, and the cohorts below them are a fraction of that size rather than a gentle slope.
4. The two collection waves covered very different places — 183 towns and cities in the first and 18 in the second — so most of the smaller cohorts here come from one wave only and carry that wave's collection design with them. A city's median also carries its own mix of trades and platforms, which is why the table shows the WordPress share and the audit-failure rate beside each figure.
5. Nothing here shows that location explains how a website performs. Nobody was assigned a town. A city cohort is the businesses a seeded search happened to find there, with their own trades, platforms and websites, so a difference between two cities in this table is a difference between those two sets of websites and nothing more. It is not a regional result, and this sample cannot support one.

What the data suggests

Six things the evidence in this report supports, and the readings it does not. Every figure here has appeared above with the number of websites behind it, and every one was recalculated inside both collection waves before it was published.

1. The clearest repeated device gap in this dataset is on mobile performance, and it is consistent rather than occasional. On the 29,965 websites that returned a Performance score on both devices, 87.5% scored lower under the mobile strategy, a median of 18 points apart. On the 29,969 that returned an LCP on both, 99.5% recorded a higher one on mobile, a median of 5.1 seconds apart. Those comparisons use the same listed URLs under both strategies rather than two separate populations, which makes them stronger evidence of a within-site device difference than comparing independent mobile and desktop medians. The URL each request finally resolved to after redirects was not retained.
2. The picture is dominated by a large middle rather than a small extreme tail. Half the 30,399 websites with a mobile LCP took 6.7 seconds or more, and 72.5% took over 4 seconds. Sorted into Lighthouse's own bands, 15.7% of the 30,397 websites with a mobile Performance score sit in the top band and 10.7% in the bottom one — 73.6% are in between. A reader looking for a scandal at the bottom of the table will miss where most of these websites actually are.
3. Read a Lighthouse score comparatively, and as a laboratory result. Each measurement comes from one automated test of one listed URL, and the conditions the service applied were not recorded. It is not a measurement of what any visitor experienced, and it is not a judgement passed by a search engine. What it supports is comparison between websites collected through the same request pattern inside the same five-week window, which is how this report uses it.
4. Platform is associated with a difference here, and this study cannot say what produced it. Among the websites whose platform we identified, the median mobile Performance score is 61 for WordPress (9,869 websites) and 69 for Wix (5,031); restricted to strong fingerprints it is 60 (8,374) against 67 (3,841); and in every one of the 12 trades with enough websites on both sides, the WordPress group is the lower of the two. The direction survives holding the trade constant, which is why the difference does not appear to be explained by trade mix alone. Why it is there at all is a question this dataset was never able to ask: nothing was assigned, and the businesses that choose each platform differ in ways it did not observe.
5. A label is not a verdict on any individual website. The pooled descriptive tables show substantial variation within platform, builder and trade groups, with overlapping interquartile ranges. That is why their medians should not be treated as clean dividing lines between individual websites. The residual group of WordPress websites where no third-party builder was recognised is not a product and carries no recommendation either. The trade and city chapters are descriptive: no trade- or city-level performance measurement was wave-tested, so those pooled tables are not used to support claims about which trade or town performs better.
6. What returned nothing is part of the evidence. 12,708 of the 43,738 websites attempted, 29.1%, produced no usable automated audit on either device. They are kept in the dataset rather than quietly dropped, because removing them would have made every failure rate look better and quietly narrowed the population every share describes. A failed automated audit is not evidence of a broken website, and the retained data does not establish why any individual page could not be measured.

Methodology

How the sample was gathered, how each figure was calculated, and the decisions taken along the way. What was recorded about the conditions each audit ran under — and what was not — is set out in full beneath this.

1. Websites were found through business listings on a UK online business directory, searched by trade and by town. Each listing's website field was reduced to a bare domain and de-duplicated, giving 43,738 websites, and every figure in this report describes some subset of those. Collection ran between 2026-07-30 and 2026-09-01 in two waves, which covered different towns and different trades; where a website was audited more than once, the most recent result is kept.
2. Each website's listed URL was sent to Google's PageSpeed Insights API twice: once with its mobile strategy and once with its desktop strategy, asking for all four Lighthouse categories. The two results are kept independently, so a website that returned a mobile result and not a desktop one keeps the mobile one. Audits that returned some category scores and not others are kept too, contributing only the categories they produced. Attempts that returned nothing are kept in the dataset as missing measurements rather than deleted, which is why the failure rates in this report are rates rather than an absence.
3. Platform detection was a separate request to each homepage, not part of the audit, and it recognises only the platforms it holds fingerprints for. Page-builder detection runs only inside WordPress. The trade and town attached to each website are the directory's own labels. Both are lowercased for grouping, and one trade spelling variant is mapped onto another — “roofer” is counted as “roofers”, which affects 116 of the websites attempted. Nothing else is mapped and no categories are combined: carpenters and joiners are separate labels here, as are gardeners and landscape gardeners. The published file carries each trade both as the directory recorded it and as normalised, so the mapping is visible rather than assumed.
4. Medians are used throughout rather than averages, because the timing distributions have long right tails. Quantiles are computed by linear interpolation between the two nearest order statistics — the definition R calls type 7 — and are pinned to that one method so a figure cannot move because a different convention was used. Every figure is published with the number of websites that returned that particular measurement, and those counts differ from one another. 43,738 is the number of websites attempted. It is not used as a default denominator for Performance, timing or Lighthouse-category measurements: each of those uses the number of websites that returned that specific measurement. Attempt- and coverage-level figures — how often an audit returned nothing, how often a platform could be identified — do use 43,738, because that is genuinely their denominator.
5. Three sample-size thresholds decide what may be published. A cohort of fewer than 30 websites is not listed; below 100 it is listed with its sample size and no median; and only at 300 is it treated as large enough to place in an order at all. A controlled comparison — one platform inside one trade — needs 100 websites in each cell, and the median must clear that on its own sample rather than the cell's.
6. One rule decides which analytical results this report states as findings. Every performance, comparative or distributional figure promoted into the writing was recalculated independently inside each of the two collection waves, and only those that held across both are quoted; anything untested, or tested and not holding, stays in a table and is labelled descriptive. That rule governs analytical results, not every number on the page: sample counts, the thresholds above, provenance and other deterministic facts about the dataset carry no wave verdict, because there is nothing about them to be robust to. It is why the trade and city chapters quote no measurement at all — no trade- or city-level performance figure was wave-tested, so both remain descriptive pooled tables.
7. The published dataset carries a pseudonymous identifier for each website in place of its domain, and no domain, URL or business name. Where a town-and-trade combination described fewer than 5 websites, that value is withheld and marked. One row could not be protected that way, because neither its town nor its trade was ever recorded, so it is omitted from the download: the internal dataset holds 43,738 websites and the published file 43,737 rows. Every figure in this report is computed from the internal dataset, so no statistic is affected. This is dataset 2026-09.2, and its checksum is below.

Limitations

What this dataset cannot tell you, stated once and in full. Each of these also appears beside the findings it affects rather than only here.

1. The sample was seeded on a set of towns and trades and is not a random or weighted sample of UK trades businesses. No figure here is a national estimate.
2. The two collection waves differ in date, town set and trade mix at once, so a difference between them cannot be separated from the way the data was gathered.
3. Each website was audited once per device. A single automated run carries run-to-run variation, and a repeat of the same page can land elsewhere.
4. The exact historical service-side emulation, network and throttling configuration was not fully retained in the dataset, and neither was the Lighthouse version that produced these figures. The test-conditions table records exactly which conditions were retained, partly retained and not retained.
5. The URL each request finally resolved to after redirects was not retained, so a row may describe a page other than the address that was listed.
6. Platform detection recognises a closed set of fingerprints, so “no platform identified” means the detector recognised nothing rather than that a website has no platform. Those websites are also disproportionately the ones that returned no measurement, so the undetected group is selected rather than random.
7. The platform and builder comparisons are observational. Nothing was assigned, there is no control group, and the businesses choosing each platform differ in ways this study did not observe.
8. The trade and city chapters are descriptive pooled analyses. No trade- or city-level performance measurement was wave-tested, and neither table supports a conclusion about which trade or town performs better.
9. The Accessibility, Best Practices and SEO categories are limited to what Lighthouse can test automatically. A high Accessibility score is not an accessibility audit, and the SEO category is not a measure of search visibility.
10. A failed automated measurement is not evidence of a broken website, and the retained data does not establish why any individual page could not be measured.

When the audit returned nothing

Roughly three in ten attempts returned no usable automated audit. That is a failed measurement, not a broken website: the table separates the attempts where our own request to the audit service failed from the ones where the service itself reported that it could not produce a usable result for the page. Neither records why, and a website that could not be measured here may be perfectly serviceable to a visitor.

How we tested these findings

Collection ran in two waves. Every headline was recalculated inside each one separately; anything that did not hold across both was not published as a headline.

Download the data

The dataset behind every figure on this page, with the methodology that produced it beside it. This report, its analysis and the statistics derived from the data are CC BY 4.0; the row-level file's terms are set out below.

1. One row per website: its town, its trade as the directory recorded it, the platform we identified if we identified one, and every Lighthouse score and timing the audit returned on each device — including the rows where it returned nothing, which are kept as missing measurements rather than dropped. No domain, no URL and no business name is in the file.
2. Cite it as: Websites for Tradespeople (2026), "The State of UK Trades Websites 2026", https://www.websitesfortradespeople.co.uk/research/state-of-uk-trades-websites-2026. This report, its analysis, its charts and the statistics derived from the data are published under CC BY 4.0: republish, reuse and build on them freely, with credit. The row-level file also contains factual fields taken from the source directory listings (each website's town and trade). We have not established that those may be relicensed, so no licence is asserted over the file and it is not being distributed while we confirm the redistribution terms. Every figure on this page is reproducible from the aggregate artefacts and the methodology, both of which are published in full. If you quote a figure, quote the number of websites beside it — every figure in this report carries one, and they differ from figure to figure.
3. The methodology sits in the provenance panel at the top of this page and sets out how the sample was gathered, how each figure was calculated, which test conditions were retained and which were not, and why these numbers are not directly comparable with studies built on actual visits. The checksum below identifies the exact version of the row-level file that every figure here was computed from.

For journalists and researchers

Everything in this report is free to quote with attribution, and there is no embargo. What follows is what you need to quote it accurately.

1. Quote the sample size with the figure, because the sample sizes are not the same. 43,738 websites were attempted; a Performance, timing or category measurement rests only on the websites that returned it, and those counts differ from figure to figure. Attempt- and coverage-level figures — how often an audit returned nothing, how often a platform could be identified — do rest on all 43,738. A figure quoted without its n is a figure someone else gets to characterise.
2. Two distinctions the report keeps, and we would ask you to keep. These are laboratory measurements from an automated test, not a record of what visitors experienced. And they are observational: where two groups of websites differ, that is a difference between those groups, not evidence that a platform, trade or town produced it.
3. Analytical findings promoted in the writing use results that held across both collection waves. Dataset counts, thresholds and provenance facts are structural facts and do not require a wave verdict. The tables carry more than the writing does, and anything in a table the prose does not quote is labelled descriptive.
4. Charts may be screenshotted and reproduced with attribution; each one carries its title, its sample size and its source line, so a lifted image still says what it is. There is no separate image pack — every chart on this page is drawn as text and vector, so it stays sharp at any size.
5. For a figure we have not published, a cut of the data we have not shown, or a question about method, write to us at hello@websitesfortradespeople.co.uk. If a figure here is wrong we will correct it in public, with the date and what changed.

Corrections and versions

This is dataset 2026-09.2. Its audits were collected between 2026-07-30 and 2026-09-01; the version identifies the analysis those audits went through, and neither date is the date this report was published. The report is generated from that version, and it will be corrected in public if it is wrong.

1. Every figure on this page is read from the dataset at build time. A corrected figure means a new dataset version, a new build and a dated note here — never a number edited by hand.
2. A material numerical change is recorded here with its date, what changed and why. A cosmetic fix to wording does not create a new dataset version unless it changes how a figure should be read.
3. Earlier dataset versions keep their checksums, which are published with each release, so anything quoted from an earlier version can still be identified and checked against the version it came from. Where a superseded file is still held, it is available on request.
4. If you believe a figure, a label or a method is wrong, write to us at hello@websitesfortradespeople.co.uk.

Questions people ask about these scores

Six questions readers arrive with, and what this study can and cannot say about each.

What is a good PageSpeed score?

Lighthouse draws the lines at 90 and 50: 90 to 100 is good, 50 to 89 needs improvement, below 50 poor. Those are Lighthouse's definitions. What this study adds is where real websites fell — a median of 67 on mobile across 30,397 websites, with 15.7% in the good band.

Why is a mobile score lower than a desktop one?

In this dataset it nearly always is: 87.5% of the 29,965 websites scored on both devices scored lower on mobile. Why is not something this study measured — the conditions the audit service applied were not recorded, and nothing about page weight, hosting or layout was collected.

What is a good LCP?

Google publishes reference thresholds of 2.5 seconds and 4 seconds for Largest Contentful Paint. In this sample the median mobile LCP was 6.7 seconds across 30,399 websites, and 72.5% were over 4 seconds. The thresholds are reference points for reading a result, not a pass mark.

Why do these figures differ from studies based on actual visits?

Because the two measure different things, over populations that need not overlap. This study is one automated laboratory test per listed URL; studies of that other kind aggregate visits to websites that meet their own inclusion criteria. Neither corrects the other. The methodology sets the difference out in full, and names the dataset involved.

Does a Lighthouse SEO score show how well a website ranks?

No. It is a set of automated checks for a subset of technical and on-page basics that Lighthouse can test. It does not measure search visibility, and a high score says nothing about how a search engine ranks the page.

Is WordPress slower than Wix?

Not a question this study can answer. What it can say is that among the websites whose platform we identified, the WordPress group had a lower median mobile Performance score than the Wix group — 61 across 9,869 websites against 69 across 5,031 — and that the direction held inside every one of the 12 trades with enough websites on both sides. That is a difference between two groups of websites that chose their own platforms, not a property of either platform.