Is a slow website costing you inquiries? Core Web Vitals in plain English.

Google measures how fast your pages feel to real visitors with three numbers called Core Web Vitals, and plenty of websites fail them on phones. Here's what each number means, how speed shows up in inquiries and what makes a B2B site pass.

A slow website loses inquiries before anyone reads a word. A buyer taps your link in a search result, watches a blank screen and goes back to the results.

Google measures three things your visitors feel.

Google's web.dev guidance sets a "good" target for each one:

• Loading. How long before the main thing on the page appears, usually the big photo or the headline. Google calls it Largest Contentful Paint. Good is 2.5 seconds or less.
• Responding. How long the page takes to react when someone taps a button or opens a menu. This is Interaction to Next Paint. Good is 200 milliseconds or less.
• Keeping still. How much the page jumps about as it loads, which is what makes people tap the wrong link. This is Cumulative Layout Shift. Good is a score of 0.1 or less.

A page meets a target when at least three in four visits do, measured separately on phones and desktops. The responsiveness measure is newer than many websites. It replaced an older measure in March 2024, so a site tuned before then was tuned for a different test.

Nearly half of websites fail on phones.

The HTTP Archive publishes Core Web Vitals results by technology, built from real Chrome visits. Its September 2026 figures show how sites made with different tools compare. A site passes when all three measures are good:

Two things stand out. Page builders drag WordPress down. And Next.js, the framework we build with, does worse than WordPress on phones. Many Next.js sites are web apps that give a phone a lot of work. The score comes down to how each site is built. Hosted builders like Wix and Squarespace score well and suit a simple site, though they limit what a B2B firm can build on top.

The direction is moving too. In the same report, WordPress sites passing on phones slipped from 49.5% in July 2026 to 48.3% in September, while Next.js sites rose from 33.9% to 35.7%.

Each group fails for a different reason.

A site fails if any one of the three measures falls short, so the pass rate hides where the trouble is. We split the same HTTP Archive September 2026 data by measure, for phones, and added how fast the server starts sending the page (Google's good mark is 0.8 seconds or less).

WordPress sites respond to a tap well but start slowly. Fewer than one in four get the server going in time, and a slow start is one thing that holds loading back. Next.js sites show the opposite pattern. Their servers start as fast as the average site, but four in ten respond to a tap too slowly. The figures don't say why. A common cause is a page that sends a phone a lot of code to run. Responding is the biggest gap between the two groups, and it's the one a careful build can close.

Your own numbers come from real visitors too.

Google's figures come from Chrome users visiting real sites. PageSpeed Insights shows them for your own site, along with a lab test that simulates a mid-range phone. Search Console has a Core Web Vitals report that sorts your pages into good, needs improvement and poor. If your site has too few visitors for the real-visitor figures, you'll see the lab test alone, which is still a useful guide.

A PageSpeed Insights report has two halves. The top half is the real-visitor result, with a clear passed or failed and a figure for each of the three measures. The bottom half is the lab test, with a score out of 100 and a list of suggestions. Start with the mobile tab. It's the harder test, and it's the version of your site Google reads. Then run your most visited project page and your contact page as well as the home page, because they often score differently.

A good lab score is not a pass.

The score out of 100 is the number people quote, but it isn't what Google measures. The pass or fail at the top of the report is. A page can score 95 in the lab and still fail with real visitors on older phones and slower connections. The lab test also can't tap anything, so Google's PageSpeed documentation lists no responsiveness measure among its lab results. Treat the score as a guide to what to fix and the real-visitor result as the verdict.

The same documentation says the real-visitor figures cover the previous 28 days. After a fix goes live, it takes about four weeks for the result to show the full change.

Speed shows up in inquiries.

A study Google commissioned from Deloitte tracked the mobile sites of 37 brands in Europe and the US at the end of 2019. On lead generation sites, a 0.1 second speed improvement went with a 21.6% rise in visitors reaching the form submission page. The study measured how speed and behavior moved together, so treat it as a strong hint.

Google uses these numbers in search too. It says good Core Web Vitals align with what its core ranking systems reward and recommends getting them to good. It's also clear that relevance comes first, so a slow page with the best answer can still outrank a fast one. Speed won't win work by itself, a point we make in fast websites don't grow businesses. A slow site does lose buyers who were already interested.

What slows a B2B website down.

• Huge photos and background video. A drone shot of your latest project can weigh more than the rest of the page put together. On construction and architecture sites the project photos are often the heaviest thing on the page, which is why our construction website design and architecture website design work starts with how the project photos load.
• Page builder code. Extra layout code loaded on every page.
• A slow server. In the HTTP Archive's September 2026 data, only 22.9% of WordPress sites started sending a page within Google's 0.8 seconds on phones, against 45.9% of all websites. Cheap hosting can be part of the reason, which we cover in is cheap shared hosting holding your website back.
• Other companies' scripts. Chat widgets, tracking tags, cookie banners and embedded maps each load code from somewhere else.
• Fonts that load late. Text appears in one font and then jumps when the real one arrives.

What a fast rebuild does differently.

We build pages ahead of time so the server has little to do when a visitor arrives, and serve them from locations close to your buyers. Images are resized for each screen automatically. The code sent to a phone is kept small, so pages respond quickly when someone taps. Fonts load early with matched stand-ins, so text doesn't jump. Other companies' scripts load after your content. We treat Google's three thresholds as a launch requirement and keep measuring real visits after launch. If you're comparing firms for this kind of build, our Next.js and Payload agency page sets out how we work.

Check your own numbers.

Our free Website Health Check is coming soon. It will run Google's speed test on your site for phones and desktops and tell you in plain English what's slowing it down. Join the list and we'll email you when it opens. Until then, PageSpeed Insights gives you the raw numbers.

If the cause is the theme, the page builder or the hosting, it's hard to fix one patch at a time. See how we rebuild legacy websites or book a call.