Why your site is slow on phones and how to fix it

Your site works fine on your laptop. That's the problem.

You built the site, or paid someone to. You open it at the office on Wi-Fi and it pops right up. Looks good. Done.

Your customers don't see it that way. They see it on a phone. Standing in a flooded laundry room in Fontana. Sitting in a hot car in Irvine waiting on an AC quote. One bar of signal, a two-year-old phone, and zero patience.

That's the version of your site that matters. And on that phone, a lot of contractor sites crawl. This article shows you how to check yours in five minutes, what the numbers mean, and the fixes that actually move them, cheapest first.

Phones really are slower. The data says so.

HTTP Archive runs the Web Almanac, a yearly study of millions of websites using real-user data from Chrome. Its 2025 performance chapter, based on July 2025 data, found a clear gap between phones and computers:

Read the first row again. More than half of websites fail Google's speed and stability checks on phones. Mobile went up from 44% in 2024, so it's getting better. Slowly.

The same group measured how heavy pages are. The median mobile home page in 2025 was about 2.56 MB. Images made up 911 KB of that, and JavaScript another 632 KB. That's a lot to push through a weak signal before a homeowner can see your phone number.

The three numbers Google cares about

Google groups page speed into three measurements called Core Web Vitals. Here's what each one means in plain English, with Google's "good" line from web.dev:

One detail matters. Google judges these at the 75th percentile of real visits, split between mobile and desktop. So it's not your best visit on office Wi-Fi. It's what most of your real visitors get, including the slow ones.

Does speed affect your Google ranking?

Short answer: it counts, but it's not the whole game.

Google's own Search Central docs say good Core Web Vitals line up with "what our core ranking systems seek to reward," and that Google highly recommends site owners hit good scores "for success with Search." Google doesn't publish how much weight speed gets compared to content, reviews or your Google Business Profile. Nobody outside Google knows that number, so don't trust anyone who quotes one.

Here's the practical way to think about it. Speed won't save a site with no service pages and no reviews. But a slow site wastes the clicks you already earned. If you're working on ranking in Google Maps, a fast site is part of finishing the job.

Check your own site in 5 minutes

1. Open PageSpeed Insights (Google's free tool) and paste in your home page URL.
2. Look at the Mobile tab first. That's the default for a reason.
3. At the top, look for the real-user data section. If your site has enough traffic, you'll see LCP, INP and CLS with a pass or fail. That's the data Google uses.
4. If there's no real-user data, you'll only see the lab test score below it. Use it as a guide, not a grade.
5. Scroll to the diagnostics. Write down the top three items. They usually name the exact image or script slowing you down.
6. Now do the gut check. Pull out your own phone, turn off Wi-Fi, and load your site. Count how long until you can see your phone number and tap it.

Run it on your home page and your main service page. Those are the pages people land on from Google.

The usual suspects on contractor sites

Most slow trade sites fail for the same handful of reasons. Here's what Google's web.dev guides point to, mapped to what we see on typical contractor builds.

1. A giant hero photo

The Web Almanac found the main element that loads (the LCP) is an image on 76% of mobile pages. On a contractor site that's usually a big truck or job photo straight off a camera. If it's several megabytes and not compressed, it's your LCP problem.

2. Lazy-loading the top image

Lazy loading tells the browser "wait on this image until it's needed." Great for photos lower on the page. Bad for the one at the top. web.dev puts it plainly: "Never lazy-load your LCP image." In an older web.dev test on a sample page, skipping lazy loading for above-the-fold images cut mobile LCP by about 18%.

3. Slow hosting

Before anything shows, your server has to answer. That wait is called TTFB. Only 44% of mobile pages had a good one in the 2025 Almanac. Cheap shared hosting, too many redirects and no CDN all add to it. web.dev's advice: minimize redirects and use a CDN.

4. Too many plugins and scripts

Chat widgets, review sliders, tracking pixels, page builders, animation libraries. Each one adds JavaScript. Some block the page from showing until they load. Only 15% of mobile pages passed Lighthouse's render-blocking check in 2025.

5. Things that jump around

web.dev lists the most common causes of layout shift: images without set dimensions, ads, embeds and iframes without dimensions, content injected after load, and web fonts. On a contractor site, that's often a review widget or a Google Map embed that pops in late and shoves your "Call now" button down right as someone taps it.

The fix list, cheapest first

Do the first five yourself or have your web person do them in an afternoon. Re-test in PageSpeed Insights after each one. Real-user data takes a few weeks to catch up, so check back in a month.

One honest note on fetchpriority: web.dev says to put it on the image most likely to be your LCP, and only one or two images. Put it on everything and it stops doing anything.

When to stop patching and rebuild

Patching works when the site is basically sound. It stops working when:

• The theme or page builder itself loads more code than your whole page needs.
• Every fix breaks something else.
• Your web person can't (or won't) touch the hosting.
• The site is slow and missing the basics: service pages, a clear phone number up top, a quote form. That's a bigger problem than speed. We cover those in common contractor website mistakes.

At that point a clean rebuild is often cheaper than another round of plugins that promise to speed up the plugins you already have.

How NOCTURNE handles it

We build contractor websites phone-first. We check them on a real phone with the Wi-Fi off, not just on a big monitor. Photos get sized and compressed, the top image loads first, and the phone number and quote form show up before anything fancy does.

If you want to see what that looks like for your business, we do a free demo: a real page on a live link within 24 hours, after a 10-minute call. If you'd rather skip the call, it's $50, credited to launch. Launch starts at $1,500, single page on your domain, live in 5 days. You own the domain, the account and the files. Prices are on the pricing page, or start with a free site audit.

Questions

Sources

• Web Vitals (web.dev, Google Chrome team)
• Understanding Core Web Vitals and Google search results (Google Search Central)
• Performance chapter, 2025 Web Almanac (HTTP Archive, July 2025 data)
• Page Weight chapter, 2025 Web Almanac (HTTP Archive)
• Optimize Largest Contentful Paint (web.dev)
• Optimize Cumulative Layout Shift (web.dev)
• The performance effects of too much lazy loading (web.dev, 2022)