Open your website on your phone, on mobile data rather than the office Wi-Fi. Count how long it takes before you can read the page and tap something. Watch whether the page jumps around while it loads, so the button you were aiming for slides out from under your thumb.
If that felt slow, your visitors feel it too, and Google measures it. The measurements are called Core Web Vitals, and they're one of the things Google's ranking systems look at. This post explains what they mean in plain English, how to check yours (including what to do when the test says "no data", which is common for small sites), and what you can fix on Wix, Squarespace or WordPress.
The quick answer
- Put your homepage into PageSpeed Insights and look at the mobile results.
- If the top section shows real-user data, check the three scores: LCP, INP and CLS. If it says there's no data, use the lab results below it instead.
- Shrink and compress your largest images. It's the most common fix.
- Remove apps, plugins, widgets and embeds you don't need.
- Retest after each change, and recheck the real-user data a month later.
Does speed actually affect your ranking?
Yes, but less than most speed-test companies imply. Google's page experience documentation says plainly that "Core Web Vitals are used by our ranking systems". The same page also says Google "always seeks to show the most relevant content, even if the page experience is sub-par", and that a great page experience helps most when lots of pages are equally helpful.
So a slow page with the best answer can still win, which is why on-page SEO and useful content come first. Speed is a tiebreaker against competitors with similar content, and a much bigger deal for the people who land on your site and have to wait. A Deloitte study of 37 brands' mobile sites, published on Google's web.dev, found a 0.1 second speed improvement was linked to 8.4% more conversions on retail sites and 10.1% more on travel sites. You're not a national retailer, but the direction is the same: a slow site loses people before they read a word.
The three measurements
Core Web Vitals are three scores, each for a different way a page can be annoying. Google's thresholds as of October 2026:
LCP: how long until the main thing shows up
Largest Contentful Paint is how long the biggest thing on the screen, usually your main image or headline, takes to appear. Good is 2.5 seconds or less. Over 4 seconds is poor.
Think of being seated at a restaurant: LCP is how long until someone hands you a menu.
INP: how fast the page reacts when you tap
Interaction to Next Paint is how quickly the page visibly responds when someone taps a button, opens a menu or types. Good is 200 milliseconds (a fifth of a second) or less. Over half a second is poor.
INP replaced an older metric, FID, on March 12, 2024. FID only measured the first tap; INP looks at all of them. If an article talks about FID, it's out of date.
CLS: how much the page jumps around
Cumulative Layout Shift measures how much things move while the page loads, like a button sliding down because an image appeared above it. Good is 0.1 or less. Over 0.25 is poor.
Google judges each score on what 75% of visits achieved over the last 28 days, so roughly three in four visits need to be in the good range for the page to pass.
How to check yours
- PageSpeed Insights tests one page. The top section shows what real visitors experienced; the section below runs a fresh simulated test and lists what to fix.
- Search Console's Core Web Vitals report (under Experience) groups all your pages into Good, Need improvement and Poor. Set it up with our Search Console guide.
- Wix's Site Speed dashboard, if you're on Wix: go to Site Speed in your site's dashboard. It shows real-visitor Core Web Vitals from Wix's own data.
Real-user data vs lab data
The two sections in PageSpeed Insights often disagree, and that's normal.
Field data (real-user data) comes from the Chrome UX Report, which collects anonymous measurements from real Chrome users over a rolling 28 days. This is what Google's ranking systems use.
Lab data is one simulated visit on one device and one connection. Google's PageSpeed Insights documentation describes it as "useful for debugging issues, as it is collected in a controlled environment." It's great for finding problems, but it's not what you're graded on.
If your lab score looks bad but your field data says Good, real visitors are fine. Don't panic over the lab number.
PageSpeed shows "no data"?
This is the most common result for small business sites, and it doesn't mean anything is broken.
The Chrome UX Report only includes pages and sites that are "sufficiently popular". Google's CrUX methodology says there's a minimum visitor threshold and that "an exact number is not disclosed." When a single page doesn't have enough visits, PageSpeed Insights falls back to data for your whole site. If the whole site doesn't qualify either, it can't show any real-user data, and Search Console's Core Web Vitals report will say "No data available".
What that means for you:
- Use the lab results instead. The simulated test still finds the slow images, heavy scripts and layout jumps. Run your homepage and your top two service pages, on mobile.
- INP needs real taps. A simulated test can't measure INP directly. The lab section shows Total Blocking Time instead, which is a rough stand-in: if it's high, the page is likely slow to respond.
- On Wix, check the Site Speed dashboard. Wix says it shows data once a site has had 10 or more sessions in the last 7 days, a much lower bar than Chrome's.
- Do the phone test from the top of this post. It's crude, but it's real.
And keep perspective: Google's Core Web Vitals assessment is built on that real-user data, so a site without any isn't being scored on it the way a busy site is. Fix the obvious problems for your visitors' sake, then spend your time on the things that matter more for a small site, like being found for the right searches.
How to fix a slow site
Start with what your platform lets you control.
Wix and Squarespace
These platforms handle hosting, caching and content delivery for you, so the server side is out of your hands. Your levers are what you put on the page.
- Upload sensible images. Don't upload a 6,000-pixel photo straight off a camera. Resize it to about the width it displays at, and run it through a free compressor like Squoosh first. Both platforms resize images for different screens, but a smaller original still helps.
- Go easy on the top of the page. A full-screen background video or a slideshow in the first section is the most common cause of a slow LCP. A single well-compressed image loads much faster.
- Remove apps, embeds and widgets you don't use. Chat widgets, social feeds, review carousels, pop-up tools and tracking pixels all add code that makes the page slower to respond. On Wix, check Apps in your dashboard. On Squarespace, look in the site's Code Injection settings (search "code injection" in the Squarespace menu) for scripts someone added years ago.
- Limit fonts. Every extra font and weight is another download. Two fonts is plenty.
- Keep pages lean. Long pages stacked with galleries, videos and embeds are slow on phones. Split them, or move heavy content further down.
WordPress
WordPress gives you more control, which also means more ways for it to go slow.
- Compress and resize images. Same as above. An image optimization plugin can compress your existing library in bulk and serve modern formats like WebP.
- Turn on caching. Caching saves a ready-made copy of each page so the server doesn't rebuild it for every visitor. Many managed WordPress hosts include it; otherwise, use one well-reviewed caching plugin (not two).
- Cut plugins and scripts. Each plugin can add code to every page. Deactivate the ones you don't use, then delete them. Ask whoever maintains the site to "defer" non-essential scripts so they load after the main content. This is the biggest fix for poor INP.
- Check your theme. Heavy page-builder themes with sliders and animations are a common cause of slow LCP. Sometimes a lighter theme is the real fix.
- Use a CDN. A content delivery network keeps copies of your files on servers closer to visitors. Many hosts include one, and Cloudflare offers a free plan.
- Look at your hosting. If the lab results flag a slow server response even after everything above, cheap shared hosting is likely the bottleneck.
On any platform: stop the jumping
Most layout shift comes from images, ads and embeds that load without a reserved space, and from banners (cookie notices, promos) that push the page down after it appears. On Wix and Squarespace, the built-in image blocks reserve space for you, so look first at embeds and third-party banners. On WordPress, make sure images have a width and height set (WordPress adds these automatically for images inserted normally), and that cookie or promo bars overlay the page rather than push it down.
Your action plan
- Measure. Run your homepage and two top pages through PageSpeed Insights on mobile. Note the field data if there is any, and screenshot the lab results.
- Fix the images on those pages.
- Cut what you don't use: apps, plugins, widgets, fonts, embeds.
- Retest the lab results after each change, so you know what helped.
- Recheck the field data in four weeks. It covers the previous 28 days, so improvements show up gradually.
When to call someone
Get help if your field data is Poor and the fixes above didn't move it, if the lab results point at server response time or JavaScript you can't identify, or if your site breaks when you remove a plugin. If a WordPress site is slow because of where it's hosted, that's what our secure WordPress hosting is for.
