Core Web Vitals benchmark of service-business websites by category

The thresholds come from Google’s guidance on LCP and CLS, and the score bands from the Lighthouse scoring documentation. The 800 ms server line and the page-weight lines are our own reference points, not official targets. 4 of the CLS values weren’t returned by the testing service. We counted those as good, and the “both” row doesn’t depend on them.

The largest element is usually the problem

The gap between the first paint and the largest one is what stands out. The median site showed its first content in 2.2 seconds, but took 6.3 seconds to show the biggest thing on the screen. 17 of the 25 were over 4 seconds. On a service-business home page, that element is often a hero image or video, though we didn’t record which element it was on each site, so check yours.

Servers were rarely to blame

23 of the 25 sites responded within 800 ms, with a median of 103 ms. This number depends on where the test ran and on caching, so it isn’t what every visitor would get. Even so, it suggests buying faster hosting would not have fixed most of these sites. What they load mattered more than where they load it from.

Layout stability was mostly fine

19 sites were in the good range for layout shift, against 5 for loading. 3 were poor, which means content visibly jumped during loading. It’s often among the easier problems to fix, with image dimensions and reserved space for late-loading elements.

Weight matters, but doesn’t decide it

Half the sites were over about 2 MB, and the largest home page weighed 10.9 MB. Heavier pages tended to be slower, but only loosely. One page under 1 MB took more than 5 seconds to show its largest element, while another of nearly 11 MB took less than 5. What loads first matters as well as how much there is.

The platform didn’t tell us much

Lighthouse identified 12 sites as WordPress, 2 as Drupal and 1 as React. It reported nothing for 10, and none as Next.js. The WordPress sites scored from 41 to 98. The 3 sites scoring 90 or more were all WordPress sites running WP Rocket, a caching plugin. Three sites can’t establish cause, but it’s a useful reminder, since we sell both WordPress and Next.js: a site’s platform doesn’t determine its speed.

Read this as a description of these five sites per category, not of each trade. With five sites per row, one result can move a median a long way, and we wouldn’t rank trades on it.

Sites are numbered by score within each category. The numbering has nothing to do with search position.

TBT is Total Blocking Time, the time the page was too busy to respond during loading. It’s a lab measure and not a Core Web Vital. “Not returned” means the testing service left the value out of its response. We show that rather than guess.

1. Categories. Five common local service types, chosen by us: cleaning, plumbing, dental, accounting and electrical.
2. Selection. On 30 October 2026 we pulled Google’s mobile results through the DataForSEO SERP API, for one search in one city per category (table below). We took the first five organic results, in order, that were a business’s own website, and tested each site’s home page.
3. Exclusions. Directories, marketplaces, review and list articles, job boards, trade associations, social media and paid results. We didn’t remove any site for scoring badly, and we didn’t replace any site after testing it. All 25 tests completed.
4. Test. Lighthouse 13.4.0, performance category only, run through DataForSEO’s hosted Lighthouse service with the mobile setup: an emulated Moto G Power, simulated throttling at 150 ms round-trip time and about 1.6 Mbps, and a 4× CPU slowdown. A few tests ran at a time.
5. Runs. One run per site, which is the number in every table. We repeated 5 sites, one per category, to see how much a result moves. We report the first run, whichever was better.

Single runs move a lot. The Lighthouse documentation says scores fluctuate and are better seen as a distribution. Our repeats, run later the same day, agree:

One site’s score moved by more than 30 points, and on two sites LCP roughly doubled or halved. So don’t read much into any one row of the site table. The overall pattern is sturdier, but it comes from single runs as well.

The other limits are these.

• It’s lab data. It simulates one mid-range phone on one slow connection. Real visitors vary, and Google assesses Core Web Vitals at the 75th percentile of real page loads.
• INP isn’t measured. Interaction to Next Paint needs real interactions. Google’s article says TBT can serve as a proxy but isn’t a substitute, so we make no claim about INP.
• It’s a small sample, and not a random one. 25 sites, chosen because they already rank in one city each. Some are larger firms, so this isn’t a picture of all small businesses.
• Home pages only. Someone from search often lands on a service page, and those can behave differently.
• One day. A site can change the next day, and this result won’t follow it.
• We don’t know where the test server sits. The service doesn’t say, which is one reason server response may not match what a local visitor gets.
• Field data is missing. We wanted to add Chrome real-user data as well, but Google’s public PageSpeed Insights API was rate-limiting us, so we didn’t. Many small sites may have none anyway, because the Chrome UX Report only includes sufficiently popular pages and origins.

Results we threw away. We first ran Lighthouse on our own computer, using Edge, while it was busy with other work. The first five completed runs all scored between 24 and 27, which looked wrong. One of those sites scored 25 there with LCP at 10.8 seconds, and 60 with LCP at 3.2 seconds on the hosted service. The machine was the problem, so we discarded those runs and used none of them here.

Largest Contentful Paint is when the biggest visible image or block of text appears, and it’s the closest of these to “when does the page look ready?”. Cumulative Layout Shift measures how much things jump around while the page loads, the effect that makes you tap the wrong button. Total Blocking Time is how long the browser was too busy to respond while loading.

The performance score blends these. The Lighthouse documentation weights Total Blocking Time at 30%, LCP and CLS at 25% each, and First Contentful Paint and Speed Index at 10% each. That’s why the score and LCP don’t always agree in the site table: one page here with LCP over 4 seconds scored 80, while two with LCP near 3 seconds scored in the 60s, with heavy blocking time on each. For a business owner, LCP is the more useful number to watch, and the score is the quick summary.

A stronger version would use more sites per category, three or more runs per site, service pages as well as home pages, and real-user data where it exists. If we repeat it, we’ll publish it as a new dated test and keep this one as it is, rather than quietly changing the numbers. If you run a similar test and get different results, we’d like to hear about it.

1. Open PageSpeed Insights and enter your home page and your busiest service page.
2. Look at the mobile result. If it shows real-user data at the top, that is the one to trust. It’s the closest thing to what Google uses.
3. Run the lab test three times and take the middle result, because of the noise shown above.
4. Compare with this page’s medians: score 67, LCP 6.3 seconds, page weight 2 MB. Beating those means you’re ahead of these ranking sites on one lab test. It doesn’t mean you’re done, since the target is 2.5 seconds.
5. Find what Lighthouse names as the LCP element. If it’s an image or a video, that’s your first job.

Our post on how fast a small-business website should be turns this into targets and an order of work. A faster page helps only if the rest of the site does its job, so see also what a cleaning website needs to get quotes and the local SEO checklist.