Website speed and Core Web Vitals: what actually matters for enquiries

Why speed matters for a service business

A slow website costs you enquiries before anyone reads a word. If a page takes several seconds to show anything useful, or the layout jumps just as someone goes to tap "Get a quote", a fair few visitors give up and try the next business on the list. Speed isn't a vanity metric, it's part of whether a genuinely interested person actually reaches your form.

It matters for search too, but not in the way people often assume. Google is clear that there is no single page-experience signal, and that its ranking systems look at a variety of signals. Core Web Vitals are used by those systems, but Google also says there is more to a great page experience than the scores alone, and that good scores don't guarantee a top ranking. So treat speed as something you fix for the visitor first, and let the search benefit follow from a site people can actually use.

Keep readingMake the enquiry itself easy to complete

The three Core Web Vitals, in plain English

Core Web Vitals are three measures Google uses to describe the real-world experience of a page. Each one covers a different moment in a visit, and each has a "good" target assessed at the 75th percentile of page loads across mobile and desktop. In plain terms, the 75th percentile means about three in four of your visitors should get at least this experience, so you are judged on a typical visit rather than your best one.

You don't need to memorise the numbers. The useful idea is that "fast" has three parts, loading, responding and holding still, and a site can be great at one and poor at another. A page that paints quickly but jumps around as fonts and images settle will still feel broken.

• Largest Contentful Paint (LCP) is loading. It measures how long it takes for the biggest thing in view, usually your hero image or main heading, to render. Good is 2.5 seconds or less; 2.5 to 4 seconds needs improvement; beyond 4 seconds is poor.
• Interaction to Next Paint (INP) is responsiveness. It watches how quickly the page reacts to taps, clicks and key presses across the whole visit, and reports the slowest meaningful one. Good is 200 milliseconds or less; 200 to 500 needs improvement; beyond 500 is poor.
• Cumulative Layout Shift (CLS) is visual stability. It measures how much the page unexpectedly moves as it loads, the reason you sometimes tap the wrong button. Good is 0.1 or less; 0.1 to 0.25 needs improvement; beyond 0.25 is poor.

INP replaced FID in 2024

If you read an older guide that talks about "First Input Delay", it is out of date. On 12 March 2024, Interaction to Next Paint officially became a Core Web Vital and replaced First Input Delay. FID only measured the delay before the browser started handling your first interaction. INP is stricter, because it looks at how long every click, tap and key press takes to produce a visible result, across the entire visit.

The practical upshot is that responsiveness now covers your whole page, not just the first tap. FID was removed from Google Search Console as soon as the change happened, while other tools such as PageSpeed Insights kept it for a six-month wind-down. If a report or plugin is still quoting FID today, it is measuring something Google no longer counts, so look for INP instead.

Lab scores and real-user data are not the same

This is the part that trips people up. When you run a speed test you can get two very different kinds of result, and only one of them is what Google actually assesses. "Lab" data comes from a single simulated load on a standard device and fixed network, which is great for debugging because it is repeatable. "Field" data is the real experience of your actual visitors, gathered from Chrome users over a rolling 28-day period, across all their different phones and connections.

PageSpeed Insights shows both, and they often disagree, because a quick test on a good connection isn't the same as a real visitor on a three-year-old phone and patchy mobile data. Core Web Vitals are assessed on the field data, not the lab score. So a green lab number is encouraging, but it isn't the finish line. The field data is the honest report of how your site behaves for the people you are trying to reach.

How to check your own site

You can get a reliable picture in a few minutes with two free Google tools, and you don't need to be technical to read them.

Google is careful to say that a good result in these reports doesn't guarantee top rankings, and that they exist to help you improve the site for people, not just for search. That is the right way to hold them: a health check for your visitors, with any search benefit as a side effect.

• PageSpeed Insights (pagespeed.web.dev): enter your URL and read the real-user section first, because that is the field data. Check the mobile tab, since that is how most people arrive, and look for the three vitals to sit in the green.
• Search Console's Core Web Vitals report: if your site is verified in Search Console, this groups your pages into good, needs improvement and poor using real-user data, and tells you which URLs share a problem. It is the best way to see patterns across a whole site rather than one page at a time.

What usually slows a small-business site

When a service-business site is slow, the cause is usually one of a short list of ordinary things rather than anything exotic. Knowing the usual suspects helps you brief a developer, or check what a redesign should fix.

You don't have to fix everything at once. Start with whatever the field data flags as poor, usually images and layout shift, since those give the biggest improvement for the least work. If you are planning a rebuild anyway, it is far cheaper to design speed in from the start than to bolt it on afterwards.

• Big, unoptimised images. A hero photo saved straight from a camera or phone can be several megabytes and single-handedly wreck LCP. Properly sized and compressed images are the highest-value fix on most sites.
• Images and embeds without set dimensions. If the browser doesn't know how tall an image, ad or video will be, everything below it jumps down when it loads, which is the main cause of a poor CLS. Reserving the space fixes it.
• Heavy third-party scripts. Chat widgets, popups, review badges, multiple tracking tags and social embeds all add weight and can delay responsiveness. Keep the ones that earn their place and drop the rest.
• Slow hosting or bloated page builders. Cheap shared hosting, or a theme loading code for features you don't use, can add seconds before your content even starts to arrive.
• Fonts that load late. Custom fonts that swap in after the page renders can shift text around and add to CLS. Loading them sensibly avoids the jump.

Keep readingBuild speed into a redesign from the start

A worked example

Here is how this plays out, with the business and the numbers invented to show the shape of the problem rather than promise a result. Picture a physiotherapy clinic, Riverside Physio, whose homepage feels sluggish on phones. PageSpeed Insights shows green in the lab, but the field data reads poor: a mobile LCP around 5 seconds, and a CLS above 0.25 because the booking button shifts down as a large banner image loads.

The fixes are unglamorous. The 4 MB hero image is resized and compressed to a couple of hundred kilobytes, and width and height are set on it and the banner so nothing jumps. A rarely used chat widget is removed. Over the following weeks, as real visits accumulate, the field LCP settles under 2.5 seconds and CLS drops into the green. Nobody rewrote the site; they fixed the three or four things the data pointed at. Those figures are illustrative only, and your own site will differ, but the order of work is the part worth copying: measure the field data, fix images and layout shift first, then re-check.