Built for slow networks: making a website fast on budget phones and patchy data

The person approving your new website usually sees it on a large screen, over office internet, on a recent laptop. It looks great and it loads instantly.

Many of your customers will see it very differently: on an inexpensive phone, on mobile data that comes and goes, possibly with a data bundle they’re trying to make last. On that phone, the same website can take long enough to load that people give up before they see anything.

Nobody sees this in the approval meeting, so it’s easy to miss. This guide explains what makes a website slow in those conditions, and what can be done about it. It’s written for business owners, not developers, but you can hand it to your developer as a checklist.

Why “it’s fast on my computer” isn’t enough

Two things make the experience different on a budget phone over mobile data.

The connection. Mobile data is often slower than office internet, and it’s less consistent. Every request the phone makes to a server takes a round trip, and on a weak signal each round trip takes longer. A page that needs many separate files to load pays that cost many times over.

The phone itself. Inexpensive phones have slower processors and less memory than a laptop or a flagship phone. That matters because modern websites often ship a lot of JavaScript (code that runs in the browser). Downloading it is one cost; the phone then has to read and run it, and on a slower processor that can take much longer than on the developer’s machine.

There’s a third, quieter cost: data. On a limited bundle, a heavy page costs your visitor money. People notice which websites eat their data.

How to see what your customers see

Before you fix anything, it’s worth seeing the problem yourself.

• Use an inexpensive phone. If you don’t have one, borrow one. Turn off Wi-Fi and load your website on mobile data. Try it somewhere the signal is weak.
• Use Chrome’s developer tools. On a computer, Chrome can simulate a slower network and a slower processor. Your developer can do this in a minute.
• Run a free check. Google’s PageSpeed Insights (external site) tests a page and reports on loading speed, including Google’s Core Web Vitals measures. When your site has enough visitors, it also shows data from real Chrome users.

The Core Web Vitals are worth knowing by name, because they describe what people actually feel:

• Largest Contentful Paint (LCP): how long until the main content appears.
• Interaction to Next Paint (INP): how quickly the page responds when someone taps or types.
• Cumulative Layout Shift (CLS): how much the page jumps around while it loads, the thing that makes you tap the wrong button.

Google publishes target values for each in its Web Vitals guide (external site). You don’t need to memorise them. It’s enough to ask your developer how the site measures against them on a mobile phone, and to see the results yourself.

What makes websites slow, and what to do about it

In our experience, most slow websites are slow for a small number of reasons. Here they are, roughly in the order they tend to matter.

1. Images that are far bigger than they need to be

This is the most common cause, and the easiest to fix. A photo straight from a camera or a stock library can be several megabytes, and it’s often displayed in a space a few hundred pixels wide.

What to do:

• Resize images to the largest size they’ll actually be shown at.
• Serve smaller versions to smaller screens. A phone doesn’t need the image a wide desktop screen needs. Modern websites can offer several sizes and let the browser choose.
• Use modern formats such as WebP or AVIF, which are much smaller than older formats at the same quality.
• Load images only when they’re needed. Images further down the page can wait until someone scrolls near them (“lazy loading”).
• Reserve the space. Tell the browser each image’s size in advance, so the page doesn’t jump when it arrives.

2. Too much JavaScript

Many sites send far more code to the browser than they need, because they’re built with heavy frameworks, templates, page builders or plugins that each add their own.

What to do:

• Render pages on the server where possible, so the phone receives ready-made HTML it can show immediately, rather than code it has to run first.
• Only send the code a page actually uses. Interactive pieces can be loaded separately, when they’re needed.
• Question every script. Each chat widget, tracker, pop-up and social feed adds code, and often slows things down more than it helps. Keep the ones that earn their place.

3. Third-party scripts

Analytics, advertising tags, chat widgets, embedded videos and social media buttons all load code from other companies’ servers. You don’t control how big or slow it is, and each one is another set of round trips.

What to do:

• Audit them. List every third-party script and what it’s for. Remove the ones nobody uses.
• Load the rest after the page. Most don’t need to be there the instant the page appears.
• Replace heavy embeds with light previews. For example, show a still image of a video with a play button, and only load the video player when someone presses it.

4. Fonts

Custom fonts give a site its character, but each weight and style is a separate file.

What to do:

• Use fewer font files. Variable fonts can cover many weights in one file.
• Subset them. Remove characters the site never uses.
• Host them yourself rather than loading them from another service, and tell the browser to show text immediately in a fallback font while the custom font loads, so nobody stares at a blank page.

5. Slow servers and no caching

If the server takes a long time to produce each page, nothing else can start.

What to do:

• Cache pages that don’t change for every visitor, so they can be sent instantly.
• Use a content delivery network (CDN), which keeps copies of your files on servers around the world, close to your visitors.
• Compress what’s sent (most modern hosting does this automatically).

6. Pages that do too much

Sometimes the page itself is simply overloaded: autoplaying video backgrounds, carousels, animations on every section, popups on arrival. Each adds weight and competes for attention.

This is a design decision as much as a technical one. A page with one clear job, and the space to do it, is usually faster and more effective.

Designing for bad connections, not just slow ones

Speed is only part of it. On mobile data, connections also drop. A website built with that in mind:

• Shows something useful immediately. Text and layout first; extras later.
• Doesn’t lose people’s work. If someone is filling in a long form and the connection drops, what they’ve typed should still be there when it comes back.
• Tells people what’s happening. A clear message when something fails (“You seem to be offline. We’ll try again when you’re connected.”) is far better than a spinner that never stops.
• Makes the important actions light. The contact form or the “book now” button shouldn’t depend on loading a heavy script first.

For tools people use every day, it can go further: an app that works offline and syncs when it can. We cover that in Offline-first apps.

Forms, checkouts and sign-in

The pages that matter most to your business are often the ones that suffer most on a slow connection: the contact form, the booking form, the checkout. A few things make a big difference:

• Keep them short. Every extra field is more typing on a small screen. Ask only for what you need now; you can ask for the rest later.
• Make them work before the scripts arrive. A well-built form can be submitted as plain HTML even if the page’s JavaScript hasn’t loaded yet, or failed to load. That’s the most reliable kind of form there is.
• Use the right keyboards. Fields marked as phone numbers, emails or numbers bring up the matching keyboard on a phone, which saves time and mistakes.
• Let browsers fill things in. Correctly labelled fields let the phone fill in names, addresses and card details automatically.
• Don’t send people back to the start. If a payment or submission fails because the connection dropped, keep what they entered and let them try again with one tap.
• Be careful with double submissions. On a slow connection, people tap “Pay” twice. The system should recognise the second tap and not charge twice.
• Make sign-in light. One-time codes by email or text, and “Sign in with Google”, can be easier than passwords on a phone. Either way, keep people signed in on their own device so they don’t have to sign in every visit.

Myths worth letting go of

“A new framework is fast by default.” Modern tools can produce very fast websites, but they can also produce very heavy ones. Speed comes from decisions made while building, not from the name of the tool.

“A CDN will fix it.” A CDN helps files arrive sooner, but it can’t make a heavy page light. If the page sends too much, it’s still too much.

“Our customers all have good phones.” Maybe some do. But if you haven’t checked, you’re guessing, and the customers with slower phones are the ones who quietly leave.

“We’ll optimise it after launch.” Speed is much easier to keep than to recover. Once a site is built around heavy components, making it light can mean rebuilding large parts of it.

“It scored well once, so it’s fine.” Sites get slower as people add images, scripts and features. Check it regularly, or better, check it automatically.

Keeping an eye on it after launch

Testing before launch tells you how the site behaves in a lab. After launch, you can see how it behaves for real people.

• Check PageSpeed Insights now and then. Once a site has enough visitors, it reports how real Chrome users experienced it over the previous weeks, not just a single test.
• Look at Google Search Console, which has a report on Core Web Vitals across your site, grouped by page type.
• Consider real-user monitoring, where the site itself reports how fast pages load for visitors. Choose a lightweight tool, or it becomes one more script slowing things down.
• Watch what’s added. New plugins, tracking codes and widgets are the most common reason a fast site becomes slow. Agree that anything new is checked for its cost first.

Setting a budget

The most reliable way to keep a site fast is to agree limits before it’s built, the way you’d agree a budget for money. For example:

• A maximum size for each page on a first visit.
• A maximum amount of JavaScript.
• A target for each Core Web Vital on a mid-range phone.

Your developer can check these automatically every time the site changes, so the site doesn’t slowly get heavier over the years as features are added. It’s much easier to stay within a budget than to diet later.

Questions to ask your developer

1. What phones and connection speeds will you test on?
2. How will the site score on PageSpeed Insights on mobile?
3. How are images resized and compressed? Will the site serve smaller images to phones?
4. How much JavaScript will each page load?
5. What third-party scripts will the site use, and when will they load?
6. What happens if the connection drops while someone is filling in a form?
7. Will you set performance limits and check them automatically?

Why it matters

A fast site isn’t a technical nicety. It’s the difference between someone reading about your business and someone giving up before the page appears. It’s also a matter of respect: for your visitors’ time, their data and the phone they can afford.

At Variance, we design and test on an inexpensive phone and a slow connection first, because if a website works there, it works everywhere. If your current site feels slow on mobile, tell us about it. We’ll tell you what’s slowing it down.