Insights · October 4, 2026

How fast is your website? What the score means and how to test it

Test it free at PageSpeed Insights: paste your address and read the Mobile tab. The score, 0 to 100, shows how your page loads on a simulated mid-range phone. The three Core Web Vitals show how fast the main content appears, whether the page jumps, and how quickly taps respond. Aim for 90 or better, with main content in 2.5 seconds or less.

By Travis Abadie

Updated October 4, 2026

What does a mobile speed score measure?

It measures how one page loads on a simulated mid-range phone over a slow mobile connection, scored 0 to 100. Google's Lighthouse tool, which runs inside PageSpeed Insights, rolls five timings into that number. 90 to 100 is green (good), 50 to 89 is orange (needs improvement), and 0 to 49 is red (poor). It's a lab test: one load, under controlled conditions.

Scores move a few points from run to run. Google's Lighthouse documentation suggests thinking of performance "as a distribution of scores" rather than one number, so run the test three times and take the middle result.

The same documentation lists the five timings and how much each one counts toward the score:

• —Total Blocking Time, 30%: how long the page was too busy to respond to a tap
• —Largest Contentful Paint, 25%: when the main content appeared
• —Cumulative Layout Shift, 25%: whether things jumped around while the page loaded
• —First Contentful Paint, 10%: when anything appeared at all
• —Speed Index, 10%: how quickly the screen filled in

What are LCP, CLS and INP, in plain English?

They're Google's three Core Web Vitals. LCP is how long until the main thing on the page shows up. CLS is how much the page jumps while it loads. INP is how long the page takes to react when someone taps. Good means LCP within 2.5 seconds, CLS of 0.1 or less, and INP of 200 milliseconds or less.

Google judges each one at the 75th percentile of visits, so three out of four visits need to hit the mark. INP became a Core Web Vital in 2024, taking over from an older measure called First Input Delay.

Layout shift is the one owners feel without naming it: you go to tap Call, a banner loads above it, the button slides down, and you tap something else.

• —LCP, Largest Contentful Paint: how long until the biggest thing on screen, usually the main photo or headline, appears. Good is 2.5 seconds or less; poor is over 4 seconds.
• —CLS, Cumulative Layout Shift: how much the page moves around while it loads. Good is 0.1 or less; poor is over 0.25.
• —INP, Interaction to Next Paint: how long after a tap before the page visibly responds. Good is 200 milliseconds or less; poor is over 500.

What is the difference between lab data and field data?

Lab data is one test run on a simulated phone, the same way every time. Field data is what real Chrome visitors experienced over the previous 28 days, from Google's Chrome User Experience Report (CrUX). Lab data tells you what to fix. Field data is what your customers actually got, and it's what the Core Web Vitals report in Google Search Console is built from.

Two details trip owners up. First, most small business sites have no field data. CrUX only includes sites with enough visitors to make a statistically significant dataset, so if PageSpeed Insights shows no real-user section for your site, that's normal, not a penalty. When we queried CrUX on October 4, 2026, neither our site nor any of the eight local web company sites we tested had a record.

Second, the lab can't measure INP, because INP needs a real person tapping. Lighthouse reports Total Blocking Time instead, which Google's web.dev describes as "a reasonable proxy metric for INP for the lab but it's not a substitute for INP in and of itself."

How do you test your own website's speed in 2 minutes?

Go to pagespeed.web.dev, paste your homepage address and press Analyze. Stay on the Mobile tab. Read the real-visitor section at the top if your site has one, then the performance score and the LCP and CLS numbers under it. Run it two more times and keep the middle score. That's the whole test.

• —Open pagespeed.web.dev on a computer or a phone.
• —Paste your full address, starting with https://, and press Analyze.
• —Make sure Mobile is selected. Google uses the mobile version of your site for indexing and ranking.
• —"Discover what your real users are experiencing" is field data. If it says there isn't enough data, skip it.
• —"Diagnose performance issues" is the lab test. Note the score, the LCP and the CLS.
• —Run it twice more and use the middle score, not the best one.
• —Scroll down to the diagnostics. The items at the top, with the biggest estimated savings, tell you what's slowing the page down.
• —Test your main service page the same way. The homepage isn't always where a customer lands.

Can you compare my website's speed with yours?

Yes, and it's free. Send your address through the quote form and choose the free speed check. We'll run the same test on your homepage and on ours, mobile Lighthouse, three runs each, middle score, and send you both results side by side.

If you want the whole picture, the paid Google & AI Visibility Audit goes deeper. Speed is one part of it, alongside your Google Business Profile, your indexing in Google and Bing, your structured data, and what AI assistants say about your business.

Why does website speed matter for phone calls?

Because a visitor who leaves before your page appears never sees your phone number. On a slow connection, every second of blank screen is a chance to hit Back and tap the next result. Google's published case studies tie faster pages to more sales and leads, and for a local business the lead is often a call.

In one, Vodafone ran an A/B test in which a version of a page with a 31% better LCP produced 8% more sales and a 15% better lead-to-visit rate. In another, a study commissioned by Google and run by the firms 55 and Deloitte across 37 brand sites found that a 0.1-second faster mobile site lifted retail conversions by 8.4% and travel conversions by 10.1%.

Those are big brands, not a local service business, so don't expect the same percentages. And speed is only part of search. Google says good Core Web Vitals align with "what our core ranking systems seek to reward," and also that Google Search "always seeks to show the most relevant content, even if the page experience is sub-par." A fast page that doesn't answer the search still won't rank.

How fast are local business websites, really?

Often slower than you'd expect, even ones built by web companies. On October 4, 2026, we ran mobile Lighthouse three times each on the homepages of 8 local web companies in the Destin and Fort Walton Beach area. One returned a server error on every run and couldn't be scored. Of the other 7, 5 scored under 70 and 3 scored under 50; two scored above 90. Main-content load (LCP) ranged from 2.5 to 16.7 seconds, with a median of 7.1 seconds.

How we tested: Lighthouse 13.5, mobile, default simulated throttling, three runs per page one at a time, and the median of each measurement. It's a snapshot of one day from one connection, and sites change. We're not naming anyone. The point isn't who's slow. Being built by a web company doesn't make a site fast, so it's worth testing yours rather than assuming.

For comparison, on the same day with the same method, our homepage scored 97 (runs of 96, 97 and 98), with an LCP of 2.5 seconds and zero layout shift, and the five Saltwater Studio pages we tested scored between 96 and 98. Those are lab numbers too, and they move: an earlier run the same week had our homepage in the low 90s. And 2.5 seconds sits right on the good line, so it's a number we're still working on.

How does Saltwater Studio build fast websites?

By deciding what the phone shows first and making everything else wait. The first thing painted is a still image and the headline, which is what the speed test measures. The 3D scene, the scroll effects and the analytics load after the visitor's first scroll, tap, keypress or mouse move. The logo and images have their space reserved, so nothing jumps.

Here is what that looks like on our own site, from performance work in October 2026:

• —The main content is a still image. Phones get only the still image; larger screens get a 3D scene after the first interaction, faded in over it.
• —Scroll effects wait for the first interaction, so their code doesn't run during the first load at all.
• —Analytics wait too. The tracking tag loads on the first interaction or four seconds after the page loads, whichever comes first.
• —No loading screen. We cut our own intro animation because it held the main content back by about 1.8 seconds.
• —Lighter fonts, and boxes sized in advance. The header logo has a fixed size, so the page doesn't shift when it arrives.
• —Our homepage ships under 200 KB of compressed JavaScript, checked on every build. If it goes over its budget, the build fails and nothing publishes until it's fixed.
• —Reduced motion is honored. Visitors who turn off animation on their phone get the still version.

Sources

• Chrome for Developers: Lighthouse performance scoring (weights, color bands, variability)
• web.dev: Web Vitals (good thresholds, 75th percentile, INP in 2024)
• PageSpeed Insights documentation (poor thresholds, 28-day field data)
• Chrome for Developers: Chrome UX Report (eligibility)
• web.dev: Total Blocking Time (proxy for INP)
• Search Console Help: Core Web Vitals report (data from CrUX)
• web.dev case study: Vodafone
• web.dev case study: Milliseconds make millions
• Google Search Central: Core Web Vitals and Google Search results
• Google Search Central: Page experience
• Google Search Central: Mobile-first indexing

Common questions

Next steps, from a free check to a full rebuild: a free side-by-side speed check, the Google & AI Visibility Audit, or a new website build.