Speed is the part of a website nobody sees and everybody feels. A visitor does not think “this page has a poor Largest Contentful Paint”; they think “this is taking ages” and press back. Google, which has measured this across billions of page views, now uses three specific speed measurements as part of how it ranks pages. This guide explains them without the jargon, and shows you how to check your own site.
Why it matters to a business, not just a developer
Three reasons. Slow pages lose visitors before they have read a word, and on a phone on a patchy signal that happens sooner than you would think. Slow pages convert worse even among the people who stay, because every extra second of waiting erodes the patience that a decision needs. And Google uses speed as one of its ranking signals, so a slow site tends to be found less often, which compounds the first two.
For a local business, where most visits come from a phone, speed is not a technical nicety. It is part of whether the phone rings.
The three Core Web Vitals
Google calls its three key measurements the Core Web Vitals. Each has a threshold for “good”.
Largest Contentful Paint (LCP): how quickly the main thing appears
The time until the largest piece of content in view, usually the main image or headline, has finished loading. It is the closest thing to “how long until the page looks ready”. Good is 2.5 seconds or less. The usual culprits are oversized hero images, videos at the top of the page, slow hosting and fonts that hold up the text.
Interaction to Next Paint (INP): how quickly it responds when you tap
How long the page takes to respond visibly after you tap, click or type. A page that looks loaded but ignores your tap for half a second feels broken. Good is 200 milliseconds or less. Heavy JavaScript, chat widgets, tracking scripts and bloated themes are the common causes. INP replaced an earlier measurement called First Input Delay in 2024.
Cumulative Layout Shift (CLS): how much the page jumps about
Whether things move after they appear: the button that shifts just as you tap it, the text that jumps when an image or advert loads above it. Good is 0.1 or less. It is caused by images without set dimensions, fonts that swap late, and content injected above what is already on screen.
Lab data and field data
When you test a page, you may see two sets of results. Field data comes from real visitors using Chrome over the previous 28 days; it is what Google actually uses for ranking, and it only appears for sites with enough traffic. Lab data is a simulated test run on the spot, on a throttled connection, so it can be run on any page, including one that has not launched. Lab results are usually harsher than field results, which is useful: a page that passes in the lab will pass in the field.
How to test your own site in two minutes
- Go to pagespeed.web.dev, Google’s free testing tool, or use the speed check on my home page, which runs the same test.
- Enter your home page address and run the test. It takes between twenty seconds and a minute.
- Look at the Mobile tab first. That is where most of your visitors are, and the harder test.
- Read the four scores: Performance, Accessibility, Best Practices and SEO. Ninety and above is green; fifty to eighty-nine is orange; below fifty is red.
- Scroll to the “Diagnostics” section. It lists what is slowing the page down, usually in order of impact.
- Repeat for your most important service page. Home pages are often the fastest page on a site; the pages that earn the enquiries can be far slower.
What the common problems mean
| What the report says | What it means | Typical fix |
|---|---|---|
| Properly size images | Images are being sent far larger than they are shown | Resize and compress, serve different sizes per device |
| Serve images in next-gen formats | Old formats (JPEG, PNG) where WebP or AVIF would be a fraction of the size | Convert at build time or through the platform |
| Reduce unused JavaScript | Scripts are loading that the page does not need | Remove plugins and scripts, load the rest only where used |
| Eliminate render-blocking resources | Stylesheets and scripts are holding up the first paint | Inline the critical CSS, defer the rest |
| Reduce initial server response time | The hosting is slow to start sending the page | Better hosting, caching, a lighter platform |
| Avoid large layout shifts | Content moves after loading | Set image dimensions, reserve space, load fonts properly |
| Third-party code | Chat widgets, trackers, embeds and fonts from other servers | Remove what is not earning its place; load the rest late |
What a fast site looks like underneath
Every page I build aims for 100 on mobile, and the methods are not secret: images sized and compressed for each screen and served in modern formats, fonts subset and preloaded, the stylesheet inlined so nothing blocks the first paint, scripts deferred and kept small, no third-party code without a reason, and hosting that responds quickly. Most of it is restraint. The fastest feature is the one that was never added.
This site is the demonstration. The home page measures its own Core Web Vitals on your device as it loads, and you are welcome to run it through PageSpeed Insights yourself.
If your site is slow
Some problems are quick: compressing images, removing a plugin, switching hosting. Others are structural: a heavy theme, a page builder, a platform that was never going to be fast. A speed review tells you which you have. If the site is otherwise good, the fixes can be done under a care plan; if it is slow because of how it was built, that is usually a sign a redesign would pay for itself.
