A website is usually slow for a handful of ordinary reasons: images far bigger than they need to be, too many scripts and plugins, a heavy page builder, or slow hosting. Google cares because it wants to send people to pages that are good to use, and it measures that with three Core Web Vitals: how quickly the main content loads, how quickly the page responds when you tap something, and whether the layout stays still. You can check your own site in a few minutes with PageSpeed Insights, Google's free testing tool.
What Google measures
Core Web Vitals are three measurements of how a page feels to real visitors.
- Loading: Largest Contentful Paint (LCP). How long until the biggest thing in view — usually the main image or headline — has appeared. Google counts 2.5 seconds or less as good.
- Responsiveness: Interaction to Next Paint (INP). When someone taps a button, opens a menu or types into a form, how long before the page visibly reacts. Good is 200 milliseconds or less. INP replaced an older measure, First Input Delay, in March 2024.
- Visual stability: Cumulative Layout Shift (CLS). How much things jump around as the page loads. It's a score rather than a time, and good is 0.1 or less.
To pass, at least three out of four visits need to hit the "good" mark on each one. So visitors on older phones and patchy mobile signal count, not just you on the office wifi.
Why Google cares
Google has said that Core Web Vitals are used by its ranking systems, as part of what it calls page experience. It has also been clear that they aren't the whole story. A fast page with thin content won't beat a slower page that answers the question better. Think of speed as something that can hold a good page back, rather than something that lifts a weak one.
The bigger reason to care is the people on the page. A slow, sluggish or jumpy page tests their patience before they've read a word. None of that shows in a ranking report, but all of it gets between a visitor and your phone number.
The usual culprits
Huge images. Photos go straight from a phone or camera onto the page at full size, then get shown at a fraction of that width.
Here's a worked example you can redo with your own numbers. Say your homepage has eight photos and each file is 4 MB. That's 32 MB for a visitor to download, quite possibly on mobile data, before the page settles. Resize each photo to the largest width it's actually shown at, save it in a modern format such as WebP or AVIF, and each file can often come down to a few hundred kilobytes. PageSpeed Insights lists your heaviest images, so you can do the sum for your own page.
Too many scripts. Every chat widget, tracking pixel, booking embed, review badge, social feed and cookie tool adds code the browser has to download and run. Each is small; together they make a page slow to respond, which is exactly what INP picks up.
Plugins and page builders. On platforms like WordPress, each plugin can add its own files to every page, whether that page uses it or not. Drag-and-drop page builders are convenient, but they tend to produce far more code than the design needs. That can be a fair trade for ease of editing. It's still a trade.
Slow hosting. If the server takes a long time to start sending the page, everything after it is late too. Budget shared hosting puts your site on a machine alongside many others, and when they're busy, so is yours. In PageSpeed Insights this shows up as a slow Time to First Byte (TTFB) or a warning about server response time.
Things that load late. Images without set dimensions, adverts and banners that arrive after the page, and web fonts swapping in all push content around. That's what CLS measures, and the fix is usually to reserve space before things arrive.
How to check your own site
- Go to pagespeed.web.dev and paste in your homepage address.
- Look at the mobile results first. It's the tougher test.
- The top section shows field data: how real Chrome users experienced your page over the previous 28 days, with a pass or fail for Core Web Vitals. If your site doesn't get many visits, it may say there isn't enough data. That's normal for a small business.
- The section below is a lab test run by Lighthouse, Google's own test of speed and quality. It gives a performance score out of 100 and a list of suggestions, each with an estimate of what it would save.
- Run it two or three times; lab scores move a little between runs.
- Test your busiest pages as well, not only the homepage.
If you use Google Search Console, its Core Web Vitals report groups your pages into good, needs improvement and poor, using the same real-visitor data.
What to fix first
Start with images, because it's usually the simplest fix and you can often do it yourself. Then go through every third-party script and plugin and ask whether it still earns its place.
If the server itself is slow, tidying the page will only get you so far; that's a conversation with your host. And if the site sits on a heavy theme or page builder, there may be a limit to how fast it can go without a rebuild.
Retest after every change, so you know which fix made the difference.
Where we come in
We build sites in our own code, not on WordPress or a page builder, and every site is tested on Google's own speed test before launch. If yours is slow and you'd like a second opinion, book a 15-minute call.