Website speed and Core Web Vitals: why a slow site costs you customers

A customer finds you on Google Maps, taps through to your website and waits. If nothing appears for a while, or the “Call us” button slides away under their thumb because a banner has just loaded above it, they go back to the results. Your competitors are listed there too.

Website speed can be measured for free, and on small business sites the problems tend to have the same few causes. Below is what Google measures, how to read the results and what usually fixes them.

What are Core Web Vitals?

Core Web Vitals are the three metrics Google uses to describe how a website feels to real visitors. Since March 2024 they have been:

Metric	What it measures	Good	Poor
LCP (Largest Contentful Paint)	when the largest element on screen appears, usually the main photo or heading	2.5 s or less	over 4 s
INP (Interaction to Next Paint)	how quickly the page visibly responds to a tap, click or key press	200 ms or less	over 500 ms
CLS (Cumulative Layout Shift)	how much the content jumps around unexpectedly	0.1 or less	over 0.25

Anything between “good” and “poor” counts as needing improvement. INP replaced an older metric, First Input Delay (FID), in March 2024. If someone sends you a report that still talks about FID, the information is out of date.

The thresholds apply at the 75th percentile. Your site doesn’t pass because it loaded quickly once on the office Wi-Fi. At least three in four visits have to meet the target, and mobile and desktop are assessed separately. A page passes only when all three metrics are good.

How to measure website speed

Lab data and field data

Before you open any tool, it helps to know the difference between two kinds of data, or the numbers will be confusing.

• Lab data comes from a test run on a preset device and network. It’s available straight away and you can repeat it, but it doesn’t show what your actual visitors experience.
• Field data comes from real people on their own phones and connections. web.dev says that when you have both, field data is what you should use to prioritise, because it shows what real users are struggling with.

Google’s field data comes from the Chrome UX Report (CrUX), a public dataset of anonymised measurements from Chrome users. Both PageSpeed Insights and Search Console use it.

PageSpeed Insights

At pagespeed.web.dev you paste in a page address and get a report in two parts:

1. At the top, real-user data for the previous 28 days, with a verdict on whether the page passes Core Web Vitals. If a single page doesn’t have enough data, the tool falls back to figures for the whole site. If the site doesn’t have enough either, this part is missing.
2. Below, a Lighthouse lab test with a score from 0 to 100. On mobile it simulates a mid-range phone on a mobile network. A score of 90 to 100 is good, 50 to 89 needs improvement and anything below 50 is poor.

The score changes by a few points from one run to the next, and that isn’t a fault. The Lighthouse documentation lists causes such as different ads being served, changes in network routing, browser extensions and antivirus software. Don’t aim for 100 either. The same documentation calls a perfect score “extremely challenging to achieve and not expected”.

The Core Web Vitals report in Search Console

If your site is in Google Search Console, you’ll find a Core Web Vitals report there. It doesn’t rate individual addresses. It puts similar pages into groups (all your blog posts, for example) and gives each group the status of its worst metric. Once you’ve fixed a problem, you can start validation, and Search Console then watches the data for 28 days to see whether the issue comes back.

Smaller sites often see a message that there’s no data. It means Chrome hasn’t collected enough anonymised measurements for your pages. You aren’t penalised for it, but you’ll have to rely on the lab test.

When you have no field data

Most websites for tradespeople, salons and small consultancies get too few visits to show up in CrUX. In that case I’d do three things:

• In PageSpeed Insights, always test the mobile version, starting with your home page and the page for your main service.
• Open the site on your own phone over mobile data, not the office Wi-Fi, and note when your phone number appears.
• Try tapping the phone number and sending the contact form before the page has finished loading.

How many customers does a slow website cost?

You’ll come across plenty of figures with no source behind them here, so it pays to be careful.

The most quoted one says that 53% of mobile visits are likely to be abandoned if a page takes longer than 3 seconds to load. It comes from a Google and DoubleClick study published in September 2016, The Need for Mobile Speed. The footnote says it’s based on anonymised Google Analytics data from about 3,700 mobile sites in March 2016 that had opted in to sharing benchmark data. The study was written for publishers who earn money from advertising, and other figures in it were measured on 3G connections. It works as an illustration that speed matters. It isn’t a precise figure for a plumber’s website today.

A more recent study is Milliseconds Make Millions, prepared by Deloitte Ireland and commissioned by Google, published in 2020. Over four weeks it looked at mobile sites of retail, travel, luxury and lead generation brands in Europe and the US. After a 0.1-second improvement in mobile site speed, retail conversions rose by 8.4% and the bounce rate on lead generation information pages improved by 8.3%. Bear in mind that these were large brands, Google paid for the study, and it shows a correlation rather than proof that speed caused the change.

Nobody has a reliable figure for a small business. It makes more sense to measure your own site: how many mobile visitors leave straight from the home page, and how many tap your phone number or send the form. Enquiries also need to land in one place, or you won’t be able to tell whether a faster site changed anything. Our business website checklist covers the rest of what a site needs to bring in enquiries.

Does website speed affect Google rankings?

Yes, but less than people selling “speed optimisation for SEO” tend to claim. Google’s documentation makes three points:

• Core Web Vitals are used by its ranking systems, and Google recommends good results.
• Good results in Search Console or other tools don’t guarantee top rankings. Google says that chasing a perfect score just for SEO “may not be the best use of your time”.
• Google “always seeks to show the most relevant content, even if the page experience is sub-par”. A good page experience helps most where many results are equally relevant.

For a small business, the order is simple. First, content that answers what people are searching for. Then get the speed metrics into the green. Chasing the last few points of the score isn’t worth the effort.

What slows small business websites down

Oversized photos

A photo from a phone is often several megabytes and thousands of pixels wide. On a website it’s displayed at the width of a phone screen. On a home page, that photo is usually the LCP element.

What helps:

• Resize photos to the size they’re actually shown at, and serve smaller versions to phones.
• Save them as WebP or AVIF. Google’s Lighthouse documentation says these formats compress better than JPEG and PNG, so pages load faster and use less mobile data.
• Don’t lazy-load the main photo at the top of the page (loading="lazy" delays it). Give it a high priority instead (fetchpriority="high").
• Set a width and height on every image, so the browser reserves the space and the content doesn’t jump.

Page builders and heavy themes

Visual editors and all-purpose themes have to do everything, so they add a lot of code your page doesn’t need. The result is often slow loading and slow responses to taps, which means a poor INP. Google’s guidance on INP names long tasks on the browser’s main thread and very large pages (in technical terms, a large DOM) among the causes.

If your WordPress site runs on a page builder with dozens of plugins, start by tidying up. Switch off plugins that don’t do anything useful and remove sliders and animations nobody reads. With a new site, it’s easier to make speed a requirement from the start than to fix it later.

Third-party scripts

A chat window, analytics tags, advertising pixels, a reviews widget, an embedded map, a YouTube video. Each one loads its own code from someone else’s server, which you don’t control.

What helps:

• Check what’s actually running on the site and delete tags left over from old campaigns.
• For video and chat embeds, use a facade. The page shows a lightweight preview, and the real code loads only when the visitor clicks on it.
• Load tracking and advertising scripts only after consent. In the UK this is also a legal point. Under PECR, the ICO says that online advertising can’t rely on any of the consent exceptions. Simple analytics used only to improve your site can run without consent if you tell visitors and give them a free, simple way to object. If you serve customers elsewhere in Europe, check the rules in that country.

Cheap hosting

Before anything appears, the server has to respond. That wait is measured by a metric called TTFB (Time to First Byte). web.dev counts 0.8 seconds or less as good and anything over 1.8 seconds as poor. An overloaded shared hosting plan, or a site that builds every page from the database on each visit, often falls outside that.

What helps: page caching, a CDN (a network of servers that delivers your site from a location closer to the visitor) and fewer redirects. When a visitor arrives through an ad or a shortened link and passes through several redirects, each one adds to the wait.

Web fonts

A custom font looks good, but the browser has to download it first. Until it arrives, the text is either invisible or shown in a fallback font that gets swapped out once the custom font loads. web.dev notes that both can cause layout shifts.

What helps: fewer font weights (three instead of eight), preloading the main font and choosing a fallback font with similar proportions. System fonts are the fastest option of all.

Bars and banners that push content down

A cookie bar, a promotional strip or a widget that appears above the content after the page has loaded pushes everything else down. The visitor goes to tap your phone number and hits something else. Reserve the space for these elements in advance, or show them as an overlay that sits on top of the content without moving it.

What to do this week

1. Test the mobile version of your home page and your main service page in PageSpeed Insights. Write down LCP, INP, CLS and the score.
2. Find out which element is the LCP. If it’s a photo, resize it and convert it to WebP.
3. Go through your third-party scripts and remove anything you don’t use.
4. If you use Search Console, open the Core Web Vitals report and see which page groups have problems.
5. Open the site on your phone over mobile data and check that you can call or send an enquiry straight away.

If the site is still slow after the clean-up because of its theme or hosting, small fixes usually won’t be enough. Our custom websites page explains how we build new sites.