Your Site Is Fast on Your Laptop and Slow on Your Customer's Phone (Here's Why)

You open your home page on your MacBook in the office, on a fiber Wi-Fi connection, and it loads in under a second. Looks great. Meanwhile, the same site is taking six seconds to load on a customer's phone over cellular, and that customer is bouncing before they ever get to your contact form. The numbers on your machine and the experience in the field are not the same site.

The gap between those two realities is where most local-business websites quietly bleed leads. Your laptop on office Wi-Fi is, no exaggeration, the worst possible test environment for a site that's meant to convert customers on phones. The 2025 Web Almanac pegs the median total blocking time on mobile pages at 1,916 milliseconds, up 58% in a single year, while only 48% of mobile pages pass all three Core Web Vitals. The web is getting slower on phones, and the people building sites mostly don't notice because they're not the ones loading them on phones.

Why is my site fast for me but slow for my customers?

Three things separate your testing setup from your customer's reality. Your laptop has more processing power than any phone, your office Wi-Fi is faster and more stable than cellular, and your visit happens after the browser has already cached half the page. A typical home-services customer is hitting your site cold on a four-year-old phone over 4G in a neighborhood with patchy reception. Same site, completely different load.

The biggest of those three is the device gap. A 2022 MacBook Pro renders JavaScript four to six times faster than a mid-tier Android phone from the same year. The page-builder runtimes I wrote about in our post on why most local business sites are slow have to download, parse, and execute on the visitor's device, so a site that's interactive in 700 milliseconds on your laptop can take three to five seconds on a customer's phone. Their phone is just slower at doing the same work.

The second gap is the network. Office Wi-Fi typically runs 100 to 300 megabits per second with sub-20-millisecond latency. According to Opensignal's June 2025 USA report, T-Mobile leads US carriers with average 5G download speeds of 177.5 Mbps, but real-world 4G LTE in the field runs closer to 20 to 40 Mbps with 100 to 300 milliseconds of latency once you account for cell handoffs and signal loss. A 6 MB Wix page that loads in one second on fiber takes 4 to 8 seconds on real cellular, before any JavaScript starts running.

The third gap is caching. Once you've visited your own site a few times, your browser stores the fonts, images, and scripts locally. Your "this is fast" test is partly a memory test of files that already lived on your disk.

What network speed should I actually be testing on?

The realistic test target for a home-services website is Slow 4G: about 1.4 Mbps download with 562 milliseconds of round-trip latency, on a CPU throttled to 4x slower than a typical desktop. That's roughly the bottom 25% of 4G connections and represents the customer who's standing in their backyard on a hot day with two bars of signal trying to figure out who to call. If your site clears that bar, it'll clear most real-world conditions.

Why test against the worst case? Because the visitors who give up and call your competitor are the ones with the worst connections. The customer on full-bar 5G is going to load your site fine no matter what. The deal you lose is the one where your page hangs for 6 seconds and the customer hits the back button. That's the visitor your test needs to imitate.

Lighthouse, the tool inside Chrome DevTools and PageSpeed Insights, defaults its mobile audits to a 1.6 Mbps connection with 150 millisecond latency and a 4x CPU slowdown. Google's reasoning: if your site is good for the slowest 5 to 10% of conditions, it's good for everyone above them.

One nuance: field data and lab data don't always agree. The "Diagnostics" section of PageSpeed Insights is a synthetic test on one emulated device. The "Core Web Vitals Assessment" at the top is field data: actual visits from real Chrome users over the prior 28 days, pulled from the Chrome User Experience Report. Field data is what counts for ranking. Lab data is what helps you debug. You want both green.

How do I test my site like a customer would experience it?

The three tests that matter, in order: Chrome DevTools throttling on your own machine, mobile-mode PageSpeed Insights on the live URL, and an actual phone on actual cellular data with Wi-Fi off. Each of them catches something the other two miss. Run all three before you decide whether your site is fast.

Chrome DevTools throttling, step by step

This is the test that surprises owners the most because they can do it on their own laptop in 90 seconds and see exactly what their customers see.

1. Open your home page in Chrome.
2. Press Cmd+Option+I on a Mac or Ctrl+Shift+I on Windows. The DevTools panel opens.
3. Click the "Network" tab at the top.
4. Find the throttling dropdown. It's near the top of the Network panel and reads "No throttling" by default.
5. Click it and select "Slow 4G."
6. To the right of the dropdown, check the box that says "Disable cache." This forces a fresh load like a first-time visitor.
7. Now refresh the page.

Watch what happens. The page you thought was fast will probably take 4 to 8 seconds to finish loading. The Network tab will show you every file the browser has to download, in order, with the size and time for each. If you see a single image over 500 KB, that's a problem. If you see more than 3 MB of JavaScript before any content paints, that's why.

Then click the "Lighthouse" tab inside DevTools, set the device to "Mobile," and run an audit. You'll get a real Lighthouse score for your site under realistic mobile conditions, generated on your own machine with no rate limits.

PageSpeed Insights mobile mode, what to look at

Open pagespeed.web.dev, paste your home page URL, and run it. The results page is split into two sections that owners often confuse.

The top section is "Core Web Vitals Assessment." This is field data: real visits from real Chrome users over the past 28 days. Three numbers matter most: LCP under 2.5 seconds (largest visible thing finishes loading), INP under 200 milliseconds (page responds quickly when tapped), and CLS under 0.1 (page doesn't jump around as it loads). If you see "Failed" or yellow numbers here, your site is hurting your search rankings, full stop.

The lower section is the lab test. The big "Performance" score in a circle, the screenshots, the waterfall, the diagnostics. This is a synthetic Lighthouse run on Google's servers. It's useful for figuring out what to fix, less useful for judging whether you have a problem. If your field data passes but your lab data fails, you have a recent regression that hasn't shown up in the field yet. If your lab data passes but field data fails, your real-world users are hitting conditions worse than the lab simulates and you need to dig in.

Toggle between the "Mobile" and "Desktop" tabs at the top. Almost every site is faster on desktop. The mobile number is the one that matters because, since Google declared mobile-first indexing complete on October 31, 2023, Google grades your site on its mobile version no matter what device the searcher is using.

The actual-phone test

This is the one that catches everything else. Take your phone off Wi-Fi (turn Wi-Fi off in settings, not just airplane mode) so it's running on cellular. Walk outside, away from the router. Open a private browsing tab so your cache doesn't help you. Type your site's URL fresh. Time it.

That's the experience your customer is having. If it takes more than 3 seconds before you can tap "Call" or "Get a Quote," you've found the leak.

Why mobile-first indexing changes the math

When Google announced mobile-first indexing was complete on October 31, 2023, it stopped being a theoretical concern. The company's crawlers grade your site based on what a phone visitor sees, not what a desktop visitor sees. That holds true even when the searcher is on a laptop. Your desktop site can be a masterpiece, but if your mobile experience is broken, your rankings reflect the broken version.

For local home-services categories, this is the entire ball game. Plumbers, roofers, HVAC, lighting, landscaping: 70 to 85% of category traffic is mobile depending on the trade. The customer who searches "emergency plumber Cottonwood Heights" at 9pm on a Tuesday is doing it on their phone, in bed, with a problem they want solved tomorrow morning. If your site loads in 5 seconds and your competitor's loads in 1, the competitor wins that lead before you've finished painting the hero image.

This is also why Google Business Profile dominates in local categories now. The GBP listing renders inside the Google app or mobile search instantly. Your website has to compete with that experience, which means your website has to be just as fast or visitors will tap the GBP card and never reach your home page at all.

The fix is rarely the things owners try first

When owners discover their site is slow on mobile, the first instinct is to call the platform's support and ask them to make it faster. The second instinct is to swap themes or templates. Neither moves the number much. The page builder's framework runtime, which is the slowest part of the page, is the same whether you're using their basic template or their fanciest one.

The fixes that move the most speed for the least work, in order: compress every image to under 300 KB and use WebP, defer the chat widget so it loads only after a tap or a 3-second delay, cull tracking pixels you're not using, and drop custom font weights you don't need. Those four will usually pull a typical Wix or Squarespace home page from 9 seconds to 5 on Slow 4G. Meaningful, not enough.

The Web Almanac data shows the platform itself is the ceiling. After you've optimized everything optimizable, you're still shipping 800 KB of platform runtime before any content paints. That's the point where a rebuild on a static stack like Next.js or Astro starts to pay for itself. When we rebuilt TruLight SLC on Next.js to fix the mobile-speed gap, total mobile load dropped from 4,155 ms to 745 ms, page weight from 35.3 MB to 10.0 MB, and time-to-first-byte from 585 ms to 37 ms. Full numbers in our TruLight SLC case study. None of those gains came from optimizing harder. They came from changing what the visitor's phone had to do.

Frequently asked questions

Why does my site score 95 on desktop and 40 on mobile?

Because mobile testing throttles both the network speed (down to about 1.6 Mbps) and the CPU (4x slower than desktop) to approximate a mid-tier phone on a real cellular connection. Desktop testing assumes broadband and a fast CPU. The 55-point gap means your site is fine for fiber-connected office users and rough for the 70%-plus of your customers who arrive on phones over cellular.

Can I just look at my Google Analytics bounce rate to know if it's fast enough?

Bounce rate tells you something is wrong but not what. A high mobile bounce rate is consistent with slow load times, but it's also consistent with bad page content, wrong audience targeting, or a broken contact form. The cleaner signal is the Core Web Vitals Assessment in PageSpeed Insights, which uses field data from your actual visitors. If that's red and your bounce rate is high, you have direct evidence the speed is the problem.

What's the difference between field data and lab data, and which one matters?

Field data is real visits from real Chrome users to your site over the prior 28 days, pulled from the Chrome User Experience Report. Lab data is a single synthetic test run on a Google server with an emulated device. Field data is what Google uses for search ranking. Lab data is what you use for debugging. You want both to be green, but if you can only fix one, fix the field data, because that's the one that affects your business.

How fast does a home-services site actually need to be on mobile?

Aim for an LCP under 1.8 seconds and a total page weight under 1.5 MB on Slow 4G. That's well inside Google's "good" thresholds and faster than roughly 80% of local-business sites in the same category. Hit those numbers and your site stops being the reason you're losing leads to a competitor that ranks above you for the same searches.

If you've gotten this far, the next move is obvious: turn off your laptop's Wi-Fi, walk outside with your phone, and load your own site cold. Whatever you see is what your customers see. If the gap between that and your office-Wi-Fi version is wide enough that you'd lose the lead, you've already got your answer about whether the platform under your site is doing its job.