Why a site can be fast on your laptop and slow on your phone
Three things change when the same page loads on a phone, and none of them are in your head.
The processor is weaker. A modern website isn’t just files that download. It’s code the browser has to run. JavaScript that a laptop gets through in a blink can tie up a mid-range phone long enough that the page looks loaded but doesn’t respond when someone taps.
The connection is less forgiving. Cellular connections add latency, which is a delay on every trip between the phone and your server. A page that needs the HTML, then a stylesheet, then a font, then an image pays that delay at each step.
You’re sending the phone the same heavy page. Most small-business sites are designed on a big monitor and then squeezed to fit a phone. The layout shrinks, but the downloads stay the same size. The phone still pulls the full-size hero photo, the slider, the background video and every plugin script.
Google’s mobile test makes the gap look even bigger, and that’s deliberate. PageSpeed Insights runs Lighthouse with these default settings:
| Setting | Mobile test | Desktop test |
|---|---|---|
| Device | Emulated Moto G Power, a mid-range Android phone | Desktop browser |
| Network | Simulated “Slow 4G”: about 150 ms latency, 1.6 Mbps down | About 40 ms latency, 10 Mbps down |
| Processor | Slowed down about 4x | No slowdown |
| Screen width | About 412 px | About 1,350 px |
So scoring 95 on desktop and 50 on mobile is common, and on its own it doesn’t mean something is broken. It means your page is heavy enough that an ordinary phone on an ordinary connection struggles. Plenty of your customers are on exactly that kind of phone.
First, check whether real visitors are actually waiting
A PageSpeed Insights report has two halves, and they measure different things.
- The top section is field data. It comes from real Chrome users who visited your site over the last 28 days. This is what Google uses when it looks at page experience.
- The bottom section is lab data. That’s the 0–100 score: one simulated page load on the throttled phone described above. It’s useful for finding problems, but it’s a test, not a measurement of your customers.
If the top section says “No Data,” your site doesn’t get enough Chrome traffic to have field data. That’s normal for a lot of small businesses. In that case, go by the lab report plus your own phone.
Field data is graded on three Core Web Vitals:
| Metric | What it means in plain terms | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | How long until the main content, usually the hero image or headline, shows up | 2.5 s or less | 2.5–4 s | Over 4 s |
| INP (Interaction to Next Paint) | How long the page freezes after a tap | 200 ms or less | 200–500 ms | Over 500 ms |
| CLS (Cumulative Layout Shift) | How much the page jumps around while loading | 0.1 or less | 0.1–0.25 | Over 0.25 |
Google grades these at the 75th percentile. In practice, three out of four visits need to hit the “good” number, not just the average visit. Search Console’s Core Web Vitals report shows the same metrics with mobile and desktop listed separately, which makes it easy to see whether the problem really is mobile-only.
The lab score is weighted too. Total Blocking Time (time the page is busy running scripts and can’t respond) counts for 30%, LCP for 25%, CLS for 25%, and First Contentful Paint and Speed Index for 10% each. A bad mobile score usually comes down to three things: too much JavaScript, a slow main image, or content that jumps.
Then do the test that matters most. Turn off Wi-Fi on your phone, open a private browser tab and load your homepage. Count how long it takes until you can read the headline and tap your main button. Do the same on your contact or booking page.
If your site fails, you have plenty of company. The 2025 Web Almanac from HTTP Archive found that 48% of mobile sites passed all three Core Web Vitals, compared with 56% on desktop.
The usual causes, roughly from most to least common
1. Oversized images, especially the first one
According to the 2025 Web Almanac, the median mobile homepage weighs about 2.56 MB, and images make up about 911 KB of that. On small-business sites, one image is often the worst offender: a hero photo uploaded straight from a camera or stock site at several thousand pixels wide. It’s usually also your LCP element, so it directly sets your score.
Fix: resize images to the size they’re actually displayed at, convert them to WebP or AVIF, and use responsive images (srcset) so phones download a smaller version. Lazy-load images further down the page. Don’t lazy-load the hero image, because that delays the one thing visitors are waiting for.
2. Third-party scripts you forgot you added
Chat widgets, ad pixels, a tag manager full of years-old tags, review carousels, heatmap tools, booking embeds, cookie banners. Each one is code from someone else’s server that your visitor’s phone has to download and run. These scripts are the main cause of high Total Blocking Time and poor INP.
Fix: list every script on the site and delete the ones nobody uses. For the ones you keep, delay them until after the page loads or until someone needs them. For example, load the chat widget only when a visitor taps the chat button. If you’re adding an AI assistant to your site (we cover what those do in AI agents for small business), make sure it loads this way and doesn’t block the page.
3. Theme, page builder and plugin bloat
Heavy themes and page builders often load the CSS and JavaScript for every feature on every page, even features the page doesn’t use. Add 20 or 30 plugins and a phone ends up doing a lot of work before anything shows up.
Fix: deactivate and delete plugins you don’t need, and check whether a caching or optimization plugin can strip unused code. If the theme itself is the weight, plugins can only help so much. More on that below.
4. Slow hosting, no caching, no CDN
If your server takes a long time to send the first byte, everything else waits, and phones with high latency feel it most. In PageSpeed Insights, look for “Reduce initial server response time.”
Fix: turn on page caching, put the site behind a CDN (which serves files from a location near the visitor), and if response times are still slow, move to better hosting.
5. Fonts and CSS that hold up the page
Several custom font families in multiple weights, loaded from another server, plus large stylesheets, can keep the browser from showing any text until they arrive.
Fix: stick to one or two font families and only the weights you use, host the fonts yourself, use font-display: swap, and preload the main font.
6. Sliders, popups and content that jumps
Hero sliders load several large images and a script to rotate them. Popups and banners that appear after the page loads push content down, which hurts CLS and annoys people right when they’re trying to tap something.
Fix: swap the slider for one strong image, set width and height on every image and embed, and reserve space for any banner so it doesn’t shove the page around.
7. Video backgrounds and embeds
An autoplaying background video is one of the heaviest things you can put on a phone. A standard YouTube or map embed also brings in a lot of script.
Fix: show a still image on mobile instead of the video, and use a click-to-load preview for YouTube and map embeds, so the heavy part loads only when someone actually wants it.
Match the symptom to the likely cause
| What you notice on your phone | Likely cause | Where to look in PageSpeed Insights | Can you fix it yourself? |
|---|---|---|---|
| White screen for several seconds | Slow server, or CSS and fonts holding up the page | Server response time, render-blocking resources | Partly |
| Text appears, main image takes forever | Oversized or lazy-loaded hero image | LCP element | Usually |
| Page looks ready but taps don’t work | Heavy JavaScript, third-party scripts | Total Blocking Time, third-party code | Partly |
| Content jumps while you read | Images without set sizes, late banners or fonts | Layout shift warnings | Usually needs a developer |
| Every page is slow | Hosting, caching, heavy theme | Server response time | Host or developer |
| Only one page is slow | That page’s video, map or booking embed | Third-party code on that page | Usually |
Does mobile speed affect Google rankings and leads?
Yes, but keep it in proportion. Core Web Vitals have been a Google ranking signal since 2021, and Google says good scores line up with what its ranking systems try to reward. They don’t override relevance, though. A fast page with thin content still loses to a slower page that answers the search better.
For most small businesses, the bigger cost is lost customers. Many people find you on a phone, through Maps, an ad or a social post, and want to call, book or get a quote. If the button takes several seconds to respond, some of them leave. A 2020 study by Google, Fifty-Five and Deloitte found that a 0.1-second improvement in mobile site speed went along with up to 8.4% more conversions for retail sites and 10.1% more for travel sites. Those were large brands, so don’t treat the numbers as a forecast for your business. The direction is still clear.
A fix order for this week
- Run PageSpeed Insights on mobile for your homepage and your main lead page (contact, booking or quote). Write down the field data, if you have any, and which element it lists as your LCP.
- Test on your own phone over cellular, in a private tab.
- Fix the LCP image: resize it, compress it, use a modern format, and make sure it isn’t lazy-loaded.
- Audit third-party scripts. Remove dead ones and delay the rest.
- Cut the extras: unused plugins, the slider, autoplay video.
- Turn on caching and a CDN, and ask your host about server response time if it’s flagged.
- Test again. Lab scores change right away. Field data covers the last 28 days, so it catches up over the following month.
When a tune-up is enough and when to rebuild
A tune-up is usually enough when the problems are a handful of images, a few scripts and caching. That’s often a few hours of focused work.
A rebuild makes more sense when the theme or page builder is itself the weight, when you’ve already stacked optimization plugins and the mobile experience is still slow, or when the site is falling short in other ways too, like no online booking, no lead capture or a dated design. Then you’re paying to patch something you’ll replace anyway. If you’re weighing that, our breakdown of what a website costs in 2026 will help you set a budget.
At BLVSTACK, that’s the kind of call we help Chicago businesses make. We build sites with lead capture, booking and follow-up built in, usually in 2–3 weeks, and can host and maintain them monthly. You own everything. If you want a second opinion on why your site drags on phones, start with a free project assessment, or see our services.