How to Make Your Website Load Faster on Mobile: What We Fixed on Our Own Site

Google’s bar for a good mobile page is a Largest Contentful Paint of 2.5 seconds or less, for at least 75% of page loads (web.dev). When we tested our own homepage on a simulated slow-4G phone in October, it took anywhere from 1.7 to 5.6 seconds depending on the run, and the layout jumped while it loaded. We build websites for a living. That result was embarrassing, and it’s the reason we can tell you exactly what to fix first.

Why Your Website Loads Slowly on Mobile (and Why You Don’t Notice It)

You probably check your site on a laptop, on good Wi-Fi. Your customers open it on a mid-range phone, on mobile data, often with a dozen other apps running. Lighthouse, Google’s free testing tool, has a mobile mode that deliberately slows the connection and the processor to imitate that visitor. A page that feels instant on your desk can score 40 there. (You can see your own site’s version in about a minute with our free Website Grader.)

Our own numbers from the first round of tests, all on the mobile setting:

• Performance score: 31 to 60 on the homepage across several runs (the pricing page scored 66).
• Largest Contentful Paint (LCP): 1.7 to 5.6 seconds, the time until the biggest thing on screen appears.
• Cumulative Layout Shift (CLS): 0.24 to 0.29. Google’s “good” line is 0.1, so this was well over it.
• Total Blocking Time: 600 to 1,070 milliseconds, the time the page ignored your taps while scripts ran.
• Third-party scripts: the Facebook pixel and Google Tag Manager alone took roughly 340 milliseconds of the phone’s processing time.

The scores moved around a lot between runs on the same page. That’s normal, and it’s the first lesson: test three times and write down the range, not the best number.

How We Made Our Website Load Faster on Mobile

We changed three things. None of them needed a redesign.

Fix 1: Host Your Fonts Yourself to Load Your Website Faster on Mobile

We were loading fonts from Google Fonts. The browser showed a plain fallback font first, then swapped in the real one a moment later. The two fonts have different letter widths, so every line of text reflowed and the form in our hero section jumped down the page. That jump was our 0.24 layout shift.

Now two variable fonts load from our own server, they’re preloaded, and the fallback font is adjusted to the same size and spacing as the real one using the size-adjust and ascent/descent settings in @font-face. When the swap happens, nothing moves. Our CLS went from 0.24–0.29 to 0.

Fix 2: Delay Tracking Scripts So the Page Loads Faster on Mobile

Google Analytics, Google Tag Manager, the Meta pixel and HubSpot don’t need to run before someone can read your page. We now load all four on the visitor’s first interaction (a scroll, a tap, a keypress) or three seconds after the page finishes loading, whichever comes first.

It’s fair to worry that this loses data. It doesn’t, for visitors who stay: the analytics and pixel code queue up every event and send them when the scripts arrive, and we checked in Chrome that all four load and fire. Blocking time in our lab tests dropped to about zero. The one real cost is covered below.

Fix 3: Shrink the Small Files That Slow Your Website on Mobile

Our favicon, the tiny icon in the browser tab, was 114 KB. It’s now 7 KB. We also stopped connecting to our image host on every page and only do it on the pages that use those images (the blog, portfolio and services pages). Small files and fewer early connections add up on a slow network.

After the changes, we ran Lighthouse against the live site on 10 October: homepage 92, pricing page 99, layout shift 0.

What We Got Wrong, and What We Haven’t Measured

A speed post that only reports wins isn’t worth much, so here’s the other side.

The trade-off in Fix 2. Someone who arrives and leaves within three seconds without touching the page never triggers the tracking scripts, so they don’t show up in Analytics or the Meta pixel. If you run paid ads, those clicks still cost you money. We accepted that because a three-second bounce tells you very little, but your visitor numbers will read slightly lower than before.

Lab numbers are not real-world numbers. Everything above comes from Lighthouse’s simulated phone. Google’s field data (the Chrome User Experience Report) has no record for our site yet because we don’t get enough traffic. Our real-visitor numbers will come from our own Analytics events, which we’ve been collecting since 19 September. Until we’ve read them, “92” is a lab score.

Server speed is untouched. In the first tests our server took about 1.4 seconds to start responding. Front-end fixes don’t change that, and we haven’t moved hosting.

A Checklist to Make Your Website Load Faster on Mobile This Afternoon

Step 1: Test the way a customer sees it

Paste your homepage address into our free Website Grader. It runs the same Lighthouse engine that sits behind Google’s PageSpeed Insights, on a simulated phone, and scores your performance, SEO and mobile usability out of 100. It also ranks the failing checks by impact, so you know what to fix first. No sign-up needed.

For the detailed numbers (LCP, layout shift and blocking time), use PageSpeed Insights or Lighthouse in Chrome’s developer tools. That’s where the figures in this post come from. Whichever you use, run it three times and write down the range.

Step 2: Fix in this order

1. Layout shifts first. Fonts that swap and images without set dimensions are the usual causes. They also feel the worst to a visitor, because the button moves just as they tap it.
2. Scripts nobody can explain. List every chat widget, pixel and tag on your site. If nobody on your team can say what one is for, remove it. Then delay the ones you keep.
3. The big image at the top. web.dev’s guide to LCP says to make sure the browser can find the image in the page’s HTML, to never lazy-load it, and to mark it fetchpriority="high".
4. Your server, if it’s slow to respond. The same guide suggests about 40% of your LCP time should be the server’s first response. If yours is far above that, no amount of image work will rescue it, and the fix is better hosting or caching.

Step 3: Run it again and keep the range

If the second set of scores isn’t better, you changed the wrong thing. Undo it and try the next item.

Does Mobile Speed Actually Affect Leads?

Speed isn’t why people buy from you. It’s why some of them never reach the page where you ask them to. We go deeper on the cost in the real cost of a slow website, and our walkthrough of Core Web Vitals and speed for SEO covers how Google reads these numbers.

The Bottom Line

To make a website load faster on mobile, start with what moves (layout shifts), then what blocks (scripts), then what’s big (images), and test on a simulated phone, not your laptop. Three small changes took our homepage from a 31–60 range to 92 in the lab, and we’ll report the real-visitor numbers when we have them.

Want a read on your own site before you change anything? Run our free Website Grader for a scored report in about a minute, then work down the checklist above. If the results show work to do, our Website Launch Sprint builds mobile speed in from day one, and maintenance plans keep it from slipping later. Or talk to us and we’ll look at yours.