This guide shows you how to test your own site for free, how to read the numbers Google gives you, and which fixes usually make the biggest difference on WordPress and online store sites. You'll also get a simple order of work, so you spend money on the problem you actually have, and an honest note on when rebuilding costs less than patching.
Run your homepage through PageSpeed Insights and look at the real-user data first, not the score. Google calls a page fast when Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less. On most small business sites the fix is oversized images, slow hosting, or too many plugins and third-party scripts.
What does "slow" actually mean to Google?
Google doesn't judge speed by one number. It uses three measurements called Core Web Vitals, and each one describes a different kind of slowness a visitor feels. The thresholds below come straight from Google's web.dev Core Web Vitals page.
Largest Contentful Paint (LCP)
LCP is how long it takes for the biggest thing at the top of the page to appear. On most business sites that's the hero image or the main headline. According to web.dev's LCP guide, 2.5 seconds or less is good, 2.5 to 4 seconds needs improvement, and anything over 4 seconds is poor.
Interaction to Next Paint (INP)
INP measures how quickly the page reacts when someone taps a button, opens a menu or types in a form. It looks at the interactions across the whole visit and reports one of the slowest. web.dev's INP guide sets 200 milliseconds or less as good, 200 to 500 milliseconds as needs improvement, and over 500 milliseconds as poor. INP replaced the older First Input Delay metric as a Core Web Vital on 12 March 2024, so any article still talking about FID is out of date.
Cumulative Layout Shift (CLS)
CLS measures how much the page jumps around while it loads. You know the feeling: you go to tap "Call now" and a banner loads above it, so you tap something else. web.dev's CLS guide calls 0.1 or less good, 0.1 to 0.25 needs improvement, and over 0.25 poor. CLS is a score, not a time, so it has no unit.
The large number is the "good" limit. Google checks each metric at the 75th percentile of real page loads, mobile and desktop separately. Source: web.dev, Web Vitals.
One detail matters more than it looks. Google judges these at the 75th percentile of page loads, split by mobile and desktop. In plain terms, at least three out of four visits need to hit the "good" mark. A page that's fast on your office Wi-Fi but slow for a quarter of your mobile visitors doesn't pass.
How to test your site with PageSpeed Insights
PageSpeed Insights is Google's free testing tool. It needs no login and takes about a minute per page.
- Go to pagespeed.web.dev and paste in the full address of your homepage.
- Wait for the report, then make sure the Mobile tab is selected. Most small business traffic is mobile, and mobile results are usually worse.
- Read the top section first, the one about what your real users are experiencing. This is field data.
- Note whether it says the Core Web Vitals assessment passed or failed, and which of the three metrics is red or orange.
- Scroll down to the performance score and the "Diagnose performance issues" section. This is lab data, and it's where the clues about causes live.
- Repeat for your two or three most important pages: a service page, a product page, a booking or contact page.
Field data and lab data are not the same thing
This is where most people get confused. The top of the report shows field data: real visits from Chrome users, collected through the Chrome User Experience Report over the previous 28 days. The lower half shows lab data: a single simulated visit run by a tool called Lighthouse, on a mid-range phone and a throttled mobile connection.
Field data tells you whether you have a problem. Lab data helps you find out why. They often disagree, and that's normal. The lab test is one run in fixed conditions, while field data is weeks of real people on real phones.
If your site is new or gets little traffic, you may see no field data at all. PageSpeed Insights first falls back to data for your whole domain, and if there isn't enough of that either, it shows nothing. In that case the lab results are all you have, so treat them as a rough guide.
What the score out of 100 means
The big circle is the Lighthouse performance score. Chrome's Lighthouse documentation puts 90 to 100 in green, 50 to 89 in orange and 0 to 49 in red. The score blends five lab measurements, with Total Blocking Time carrying 30%, LCP and CLS 25% each, and two others 10% each. The same page can score differently from one run to the next because of network routing, ads, browser extensions and similar noise. The same documentation says a perfect 100 is "extremely challenging to achieve and not expected".
How to check speed in Google Search Console
PageSpeed Insights tests one page at a time. Search Console shows every page Google has enough data for, grouped together, which makes it better for spotting patterns across a whole site.
In Search Console, open the Core Web Vitals report from the left-hand menu. You'll see separate reports for mobile and desktop, with pages sorted into Good, Needs improvement and Poor. According to Google's Core Web Vitals report help page, a group of pages takes the status of its worst metric. Good LCP and poor CLS means the group shows as Poor.
The report groups pages that behave alike. If all your product pages sit in one Poor group, the problem is almost always in the product page template, not in each product. That's good news, because one fix covers them all.
After you fix something, open the issue and click Start Tracking. Google then watches the pages over a 28-day period. Don't panic if nothing changes for a week or two. The data is a rolling average and it moves slowly.
If the Core Web Vitals report is empty, your site probably doesn't have enough Chrome visits yet. That's common for a new local business site. Use PageSpeed Insights lab data in the meantime and check back in a month. If your pages aren't showing on Google at all, that's a different problem, covered in why your website isn't showing on Google.
Does site speed affect your Google rankings?
Yes, but less than many speed tool sellers suggest. Google's page experience documentation says Core Web Vitals are used by its ranking systems, and that there's no single page experience signal. It also says good results in Search Console or third-party tools don't guarantee top rankings.
The same page includes this line: "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." A slow page that answers the search well can still outrank a fast page that doesn't.
Chasing a green 100 in the lab is a hobby. Getting real visitors below 2.5 seconds is a business decision.
Google's ranking documentation talks about Core Web Vitals from real visitors. It doesn't mention the Lighthouse score. So if someone quotes you a price to "get your PageSpeed score to 100", ask what it will do to your field data and your enquiries. Moving from 62 to 94 in the lab while real-user LCP stays at 3.8 seconds has bought you very little.
The better reason to care is your customers. A visitor who taps "Book now" and waits, or watches the price jump just as they reach for the button, often leaves. You can't see those people in your analytics as complaints. They just don't come back.
What to fix first on a slow website
Fix the metric that's failing in field data, on mobile, on the pages that bring in money. Everything else waits. Here's the order that avoids wasted effort.
Sources: web.dev guides to LCP, INP and CLS; Search Console Help, Core Web Vitals report.
- Start with field data. If it passes on mobile, your site isn't slow in Google's eyes. Any work from here is polish.
- If LCP fails, look at the hero image and the server response time first. Those two cover most LCP problems on small sites.
- If INP fails, look at JavaScript: plugins, page builders, chat widgets, tracking tags and pop-ups.
- If CLS fails, look for images without set sizes, late-loading fonts, cookie banners and ad or review widgets that push content down.
- Only then look at lab-only suggestions like "reduce unused CSS".
This table puts the main causes and fixes in one place. The thresholds are Google's; the causes are the ones web.dev lists, narrowed to what shows up on typical WordPress and store sites.
| Metric | What it measures | Good | Typical causes | Typical fixes |
|---|---|---|---|---|
| LCP | How fast the main content appears | 2.5 s or less | Huge hero image, slow hosting, lazy-loaded hero, sliders, render-blocking CSS and scripts | Resize and compress the hero, serve WebP or AVIF, turn on page caching, better hosting or a CDN, remove the slider |
| INP | How fast the page reacts to taps and clicks | 200 ms or less | Heavy JavaScript, too many plugins, page builder bloat, chat widgets, tag managers full of old tags | Remove plugins and tags you don't use, delay chat widgets until clicked, trim the page builder, audit tracking |
| CLS | How much the layout jumps while loading | 0.1 or less | Images with no width and height, web fonts swapping in, banners and widgets injected at the top | Set image sizes, reserve space for banners and embeds, load fonts early, fewer font files |
Swipe sideways to see the whole table.
The fixes that usually matter most on WordPress and store sites
Shrink the hero image
This is the single most common cause of poor LCP on small business sites. A photographer hands over a 6,000-pixel photo, it goes straight into the homepage banner, and every phone downloads several megabytes before anything meaningful appears.
Resize the image to the largest size it's actually shown at on screen, and compress it. Use a modern format. MDN's image format guide says lossy WebP files are on average 25 to 35% smaller than JPEGs of similar quality, and lossy AVIF files are around 50% smaller. WordPress can serve WebP, and most image optimisation plugins convert files automatically.
Then check one setting people get backwards. Lazy loading (the loading="lazy" attribute) tells the browser to wait until an image is near the screen before downloading it. MDN explains it's meant for off-screen content. web.dev's LCP optimisation guide is blunt: "Never lazy-load your LCP image." Some themes and plugins lazy-load every image, including the hero. Lazy-load the gallery further down, not the banner at the top.
Turn on caching and look hard at your hosting
Before a page can show anything, the server has to send the first bit of HTML. That wait is called Time to First Byte (TTFB). web.dev suggests 0.8 seconds or less and calls anything over 1.8 seconds poor. TTFB isn't a Core Web Vital on its own, but it eats into your LCP budget. If the server takes 1.5 seconds to reply, you have one second left for everything else.
The WordPress optimisation documentation says caching gives "the biggest benefit for the smallest hassle". A page cache stores a ready-made copy of each page, so WordPress doesn't rebuild it from the database for every visitor. Many managed WordPress hosts include this. If yours doesn't, a caching plugin does the job. The same documentation recommends a current PHP version and a CDN (a network of servers in different countries that holds copies of your images and files closer to visitors). A CDN helps most when your customers are spread out, say a UK shop selling to Australia.
If TTFB is still slow with caching on, the host is often the problem. The cheapest shared hosting puts many sites on one server, and the WordPress documentation notes that shared hosting limits what you can tune. Moving to a better host can do more for LCP than a month of plugin tweaking, and it's usually a one-off job.
Cut plugins and scripts you don't need
Every plugin that adds something to the front of your site adds code the visitor's phone has to download and run. The WordPress documentation's advice is short: "Deactivate and delete any unnecessary plugins."
Go to Plugins > Installed Plugins and ask of each one: does this do something a customer or I would miss this week? Common candidates for removal:
- A second SEO plugin doing the same job as the first
- Social share buttons nobody clicks
- An old pop-up or countdown timer plugin from a past campaign
- Several form plugins where one would do
- Page builder add-on packs where you use two widgets out of eighty
Deactivate on a staging copy first if you can, and test your forms and checkout afterwards. On WooCommerce stores, be careful with anything touching payments, shipping or tax.
Remove the slider
Homepage sliders load several large images, a script to rotate them, and often an animation library. Most visitors never see slide three. A single strong image with a clear headline is almost always faster and usually converts better too, because the message doesn't change while someone's trying to read it.
Tame chat widgets and third-party tags
Live chat tools, review badges, booking embeds, YouTube videos and marketing pixels all load code from other companies' servers. You can't make their code faster, but you can load it later. Chrome's Lighthouse documentation describes a facade: a static image that looks like the chat bubble or video player, and only loads the real thing when someone clicks it. It lists chat widgets such as Intercom and Drift, and YouTube and Vimeo players, as good candidates.
Open Google Tag Manager too, if you use it. Tags for a campaign that ended two years ago still run on every page view.
Fix fonts and image sizes for CLS
Two quick checks cover most layout shift. First, every image should have a width and height set in the HTML, so the browser can reserve the space before the file arrives. Custom theme code and some page builders skip this. Second, fonts. web.dev's font guide explains that swapping from a fallback font to your web font causes layout shift, and recommends using WOFF2 files and fewer web fonts. Four weights of two font families is a lot to ask a phone to download. Two weights of one family usually looks just as good.
When a rebuild is cheaper than patching
Sometimes the honest answer is that the site can't be made fast without replacing its foundation. Signs you're in that position:
- The theme is a heavy "multipurpose" theme that loads every feature on every page, and removing features breaks the layout.
- The site was built with a page builder that nests dozens of containers for each section, and INP fails on simple pages.
- There are dozens of active plugins and nobody knows what half of them do.
- WordPress, PHP or the theme are years out of date, and updating breaks things.
- You've already paid for speed work once and the gains faded within months.
In those cases, paying a developer to fight the theme hour by hour often costs more than a clean rebuild on a lightweight theme, and you end up with a site that's still fragile. A rebuild is also the right time to check whether WordPress is still the best fit; WordPress vs Shopify for small businesses covers that choice. If you go that way, protect your existing rankings with proper redirects and a careful launch, as explained in how to redesign a website without losing SEO.
The reverse is also true. If the site is otherwise sound and only the hero image and hosting are the problem, a rebuild is a waste of money. Fix those two things and retest.
Common mistakes
- Judging the site on desktop results. Your phone visitors are the ones failing.
- Testing once, seeing 71, then testing again and seeing 58, and assuming something broke. Lab scores wobble between runs.
- Installing three speed plugins at once. Two caching plugins fighting each other can make things slower or break the site.
- Turning on every "optimise JavaScript" option in a speed plugin and not testing the checkout, menu or contact form afterwards.
- Lazy-loading the hero image because a plugin enabled it for all images.
- Paying for a green 100 while ignoring field data, which is what Google's ranking systems actually use.
- Fixing the homepage only. Your product and service pages usually get more search traffic.
- Expecting Search Console to update overnight. It works on 28 days of data.
A sensible next step
If you'd rather not do this yourself, a website care plan that includes regular speed checks, updates and plugin clean-up keeps the site from slowly getting heavier again. You can see what's included in BerdisDev care plans, or, if your tests point to a rebuild, ask for a free quote and send your PageSpeed Insights link along with it.
Frequently asked questions
Why is my website slow on mobile but fine on desktop?
PageSpeed Insights tests mobile on a simulated mid-range phone with a throttled connection, and real mobile visitors often have weaker processors and patchier signal than your office computer. Large images and heavy JavaScript hurt far more on a phone. Check the mobile tab first, because that's where most small business visitors are and where most failures show up.
What is a good PageSpeed Insights score?
Lighthouse marks 90 to 100 as good, 50 to 89 as needs improvement and 0 to 49 as poor. But the score is lab data from one simulated visit. The more useful result is the Core Web Vitals assessment at the top of the report, based on real visitors. A site scoring 75 that passes all three field metrics is in better shape than one scoring 95 that fails them.
What are good LCP, INP and CLS values?
Google's thresholds are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. These are measured at the 75th percentile of page loads, so at least three out of four visits need to meet them. Values between those and 4 seconds, 500 milliseconds and 0.25 need improvement. Anything beyond is poor.
How long does it take for speed fixes to show in Search Console?
Search Console's Core Web Vitals report is based on real Chrome visits over a rolling 28-day period, so improvements appear gradually over about a month. When you click Start Tracking on an issue, Google tracks the affected pages for 28 days before confirming. PageSpeed Insights lab data updates immediately, so use it to confirm the fix worked while you wait.
How do I speed up a WordPress site without a developer?
Start with three things. Resize and compress your homepage hero image and serve it as WebP. Turn on page caching through your host or a single caching plugin. Then delete plugins you no longer use from Plugins > Installed Plugins. Test in PageSpeed Insights after each change, and check your forms and checkout still work before moving on.
Will a faster website rank higher on Google?
It can help, but it's one signal among many. Google says Core Web Vitals are used by its ranking systems, and also that it shows the most relevant content even when page experience is sub-par. Speed won't rescue a page that doesn't answer the search. It matters more for keeping visitors once they arrive.
Sources (17)
- Core Web Vitals (web.dev)
- Largest Contentful Paint (web.dev)
- Interaction to Next Paint (web.dev)
- INP is now a Core Web Vital (web.dev)
- Cumulative Layout Shift (web.dev)
- PageSpeed Insights
- About PageSpeed Insights (Google)
- Lighthouse performance scoring (Chrome)
- Core Web Vitals report (Search Console Help)
- Understanding page experience (Google Search Central)
- Optimize LCP (web.dev)
- Time to First Byte (web.dev)
- Image file type and format guide (MDN)
- Lazy loading (MDN)
- WordPress optimization (developer.wordpress.org)
- Lazy load third-party resources with facades (Chrome)
- Best practices for fonts (web.dev)