Run a small-business website through Google PageSpeed Insights and the two results often disagree: a respectable desktop score and a worrying mobile one, for the same page.
The test isn’t broken. The mobile score is a stress test run under deliberately tough conditions, and once you understand them, real problems are easier to separate from cosmetic ones.
The short version. A low mobile score usually comes down to three things: an oversized top image, code that must load before anything appears, and third-party scripts competing for a slow phone’s processor. Fix those first, then judge the result by what real visitors experience.
What the mobile test simulates
PageSpeed Insights runs Lighthouse, Google’s open-source auditing tool, against your page. For the mobile result, Lighthouse imitates a mid-range phone on a slow connection: it slows the processor down four-fold, caps downloads at about 1.6 Mbps, and adds a 150-millisecond delay to every request.
Lighthouse’s documentation places that connection in roughly the slowest quarter of 4G: an older phone on a weak signal, not you on office Wi-Fi. That’s why a page can feel instant to you and still score poorly. Desktop is tested under easier conditions and graded on its own scale.
Google treats a score of 90 to 100 as good, 50 to 89 as needing improvement, and under 50 as poor. The scale is demanding by design: each metric is graded against a large public record of real websites (the HTTP Archive), and a 90 means keeping pace with roughly the fastest 8 percent of them. So an orange score doesn’t mean your site is broken.
Lab data and field data answer different questions
A PageSpeed Insights report has two layers.
Lab data: one test run
Collected by Lighthouse in one controlled test on a simulated device and network. It produces the 0–100 Performance score and the suggested fixes: useful for diagnosing problems and checking a change, but expect it to vary between runs.
Field data: real visitors
Collected from real Chrome users through the Chrome UX Report over the previous 28 days, and reported at the 75th percentile, so it reflects your slower visits rather than the average. It drives the Core Web Vitals assessment at the top of the report.
Field data appears only when there are enough Chrome visits; otherwise PageSpeed Insights falls back to your whole domain, or shows none, which is normal for a lower-traffic site.
When field data does exist, give it more weight than the lab score: it’s what your customers experienced. A page that passes Core Web Vitals in the field but scores 70 in the lab still has room to improve; it just isn’t an emergency.
The five metrics behind the score
The Performance score is a weighted average of five lab metrics; Total Blocking Time and Largest Contentful Paint alone carry more than half the weight.
| Metric | Weight | What it measures |
|---|---|---|
| Total Blocking Time (TBT) | 30% | How long the page is too busy running code to respond to a tap |
| Largest Contentful Paint (LCP) | 25% | When the largest visible element, often the top image or headline, finishes rendering |
| Cumulative Layout Shift (CLS) | 25% | How much the layout jumps around while the page loads |
| First Contentful Paint (FCP) | 10% | When the first text or image appears |
| Speed Index | 10% | How quickly the visible part of the page fills in |
LCP and CLS are also Core Web Vitals, the three metrics Google highlights for real-user experience. A good LCP is 2.5 seconds or less, and a good CLS is 0.1 or less. The third, Interaction to Next Paint (INP), should be 200 milliseconds or less, but it needs real people tapping the page, so the lab uses Total Blocking Time instead.
The usual culprits on small-business websites
The causes are rarely exotic. These are the seven we check first; the suggestions below the score in your report usually name the exact image, file, or script involved.
Oversized hero images
Spas, salons, and photographers are right to lead with strong photos; the problem is file size. A photo straight from a camera or stock library can weigh several megabytes, though a phone screen needs a fraction of that detail. Because the top image is often the LCP element, every extra kilobyte delays a metric worth a quarter of the score. Some themes also lazy-load every image (holding it back until the visitor scrolls near it), including that one, which Google’s guidance says never to do.
Render-blocking CSS and JavaScript
Stylesheets, and scripts in the page’s head that aren’t set to load later, must be downloaded and processed before the browser draws anything. On a throttled connection, each one adds a visible pause before the first words appear.
Page-builder bloat
Visual page builders make editing easy, but they often load all their styles and scripts on every page and wrap each element in extra markup. That’s more to download and more work for a slowed-down processor. Builders aren’t a bad choice (the Gen Spa site below uses one), but they need deliberate trimming.
Too many plugins and third-party scripts
Chat bubbles, social feeds, review widgets, booking embeds, video players, and tracking tags each bring their own JavaScript. All of it competes for the same processor, which is exactly what Total Blocking Time, the heaviest-weighted metric, measures. On WordPress, plugins often load files on pages that never use them.
Web fonts
Custom fonts are files too. Several families and weights, especially from an outside server, add requests before text reaches its final form. When the custom font replaces the stand-in font shown first, text can shift and push content around, which counts against layout stability.
Slow server response and no caching
Before anything else, the server has to send the first byte of the page. Overloaded hosting, and pages rebuilt from the database on every visit, delay everything that follows. Page caching and a content delivery network (CDN) are often among the cheapest fixes.
Layout shifts from images without dimensions
Without a width and height, the browser can’t reserve an image’s space, so text jumps when the image arrives. Maps, videos, and cookie banners inserted after the page loads do the same. Each jump adds to Cumulative Layout Shift, and it’s why a visitor sometimes taps the wrong button.
What to fix first
Start with the heaviest weights and the cheapest wins. For most small-business sites, that means:
- Fix the top image. Resize and compress it, save it in a lighter, modern format such as WebP, and make sure it isn’t lazy-loaded.
- Remove what you don’t use. Deactivate unused plugins, widgets, and tracking tags. A booking-calendar embed belongs on the booking page; every other page just needs a button linking to it.
- Clear the way for the first screen. Set non-essential scripts to load after the page appears, and cut styles the first screen doesn’t need.
- Reserve space. Give every image and embed a set width and height, and keep banners from pushing content down.
- Turn on page caching. Then check how quickly your host responds.
- Simplify fonts. Use one or two families and only the weights you need.
On Wix, Squarespace, and similar hosted platforms, hosting and caching are handled for you, so your levers are mainly images, embedded apps and widgets, and fonts.
Test after each change so you know what helped, and run each test more than once: lab scores can move even when nothing has changed, because network conditions, server load, and third-party scripts vary from run to run.
Steps 1 and 2 are usually manageable from your website’s dashboard; back up the site first. Steps 3 to 6 usually mean theme, code, or hosting changes, so hand those to whoever maintains your site. If that’s no one, bring your mobile report to a free website consultation and we’ll show you which fixes apply and which can wait.
Why the score isn’t the goal
A perfect 100 doesn’t book appointments. Customers do. Speed matters because a slow, jumpy page makes it harder for someone on a phone to read your services, trust what they see, and tap to book.
Google recommends good Core Web Vitals and says they align with what its core ranking systems seek to reward. Still, speed is only one of the signals SEO and local SEO work covers, and no score guarantees rankings, calls, or bookings.
So measure what the score is meant to protect: the Core Web Vitals report in Google Search Console once you have enough traffic, and whether mobile visitors reach your contact form or booking page. An 85 on a page that makes booking effortless beats a 98 on a page stripped of the photos, prices, and reviews customers want before they decide.
That balance is how we approach website design and development: properly sized images, only the scripts each page needs, and a clear path to an inquiry, planned from the start rather than bolted on after launch.
If your site is worth keeping, don’t start over. Our website and marketing audit gives you a written, prioritized plan you can follow with us or on your own, and for WordPress sites, Managed Website Care includes a basic performance review and a monthly report.
A real example: Gen Spa’s mobile score, before and after
Gen Spa, a therapeutic massage and wellness business in Florida, runs on WordPress and Elementor, the kind of page-builder setup described above. We took over its website and rebuilt it page by page. That included performance work such as reducing render-blocking resources, plus a dedicated Booking page that sends visitors to online booking for each location, so faster pages lead to a clear next step. Its homepage in PageSpeed Insights on mobile, before and after:
The after-test is dated July 29, 2026. First Contentful Paint also dropped from 5.4s to 1.8s, and Best Practices and SEO scored 100 both before and after. We publish only figures we can show and date, so traffic and inquiry numbers aren’t included here. The site is live at genspa.com, so you can run the same mobile test yourself; results vary between runs and over time.
Sources
The Google and Lighthouse documentation this guide draws on, checked on September 27, 2026. Lighthouse’s scoring and thresholds change between versions, so the current pages always take precedence.
- About PageSpeed Insights — Google for Developers
- Lighthouse performance scoring — Chrome for Developers
- Lighthouse network and CPU throttling — Lighthouse documentation
- Total Blocking Time — Chrome for Developers
- Eliminate render-blocking resources — Chrome for Developers
- Web Vitals — web.dev
- Optimize Largest Contentful Paint — web.dev
- Optimize Cumulative Layout Shift — web.dev
- Understanding Core Web Vitals and Google search results — Google Search Central