Designing for visitors on slow networks and old phones

Who is on a slow connection

Not everyone browses on fast fiber and a new phone. The 2025 Web Almanac makes the point about money as well as speed. In many parts of the world, data is metered, so a heavy page is not only slow but costly, and a visitor who cannot afford the data cannot use the site. It also notes that a heavy page works against people on older, less powerful devices and slower or capped connections.

You do not have to look far for such visitors:

• People on a weak or crowded mobile signal, on a train, in a basement, in a rural area or at an event.
• People on older or cheaper phones with slower processors and less memory.
• People on a plan with a data cap, or in a market where data is expensive.
• People on a shared connection, or one that other devices are using.

Your own analytics can tell you how many of your visitors are in this group. See real user monitoring.

What slow networks punish

The Almanac's page weight chapter describes where the cost falls:

• Bytes. More data takes longer to arrive and costs the visitor more.
• Round trips. Each separate file needs a trip to the server, and each trip pays the connection's delay.
• Lost packets. On mobile connections, signal interference can drop packets, and the heavier the page, the more likely a loss is to make the page hang while data is sent again.
• Processing. Once a file arrives, the device must unpack and run it. The Almanac's rule of thumb is that 100 KB of an image is just pixels but 100 KB of JavaScript is work, and on a low-end phone it can freeze the screen for several seconds.

Each of the four has its own fixes, and none of them works if you only look at the total size. See page weight and requests.

How the Lighthouse test compares

Lighthouse's documentation describes its default mobile settings:

• Network: a latency of 150 ms and a throughput of 1.6 Mbps down and 750 Kbps up. These figures are meant to represent roughly the bottom 25% of 4G connections and the top 25% of 3G connections. The documentation says Lighthouse uses them to emulate about the 85th percentile of mobile connection speeds. The preset used to be labeled "Fast 3G" and is now called "Slow 4G".
• Processor: a constant 4× slowdown, which moves a typical high-end desktop into the range of a mid-tier phone.

So Lighthouse is already a slow test, and about one connection in seven is slower than it. A page that only just passes in Lighthouse will be slow for the slowest visitors. The aim of a page that serves everyone is to pass with room to spare.

The slowest quarter

web.dev explains how Core Web Vitals are judged. A page or site is classified by the 75th percentile of all visits. If at least 75 percent of visits meet the "good" threshold, the metric counts as good. The 75th percentile was chosen so that most visits get the target experience while a few visits on flaky connections do not decide the result.

For you this means two things. A score of "good" can hide a quarter of visits that were not. And the visitors who are in that quarter are often the ones on slow networks and old phones, who are the easiest to lose. Looking only at the pass or fail result misses them. Look at how the distribution is spread, and at the slow end in particular. See the Chrome UX Report and how to improve Core Web Vitals.

What helps

Send less.

• Images are the biggest part of a typical page. Resize them to the size they are shown, use a modern format, and load the ones below the first screen later. See image optimization.
• Remove the JavaScript that the page does not need. See reduce unused code.
• Do not autoplay a heavy video. See video and speed.

Make fewer trips.

• Fewer files and fewer hosts mean fewer connections to set up. See DNS, TLS and connections.
• Keep critical resources on your own host when you can, so the connection to it is already open.

Cache well. A file a visitor already has costs nothing on the next visit. Long cache lifetimes on versioned files turn a slow first visit into a fast second one. See HTTP caching headers.

Load in the right order. Put the content first, and defer what is not needed to read or use the page. See defer, async and modules.

Keep the page working. On a slow or unreliable connection a script can arrive late or fail. If the main text, the links and the form still work without it, the visitor can use the page while the rest loads. This is the case for server-rendered pages. See hydration.

Avoid surprises on late arrival. Reserve space for images, ads and embeds so the page does not jump when they appear. See how to fix layout shift.

Respect the visitor's data choice

Some browsers let visitors turn on a data saver. MDN describes the Save-Data request header as a client hint that shows a preference for reduced data use, for reasons such as high transfer costs or slow connections. When it is on, MDN says, a site can deliver alternatives: smaller images and video, different markup and styling, and no polling or automatic updates. The same setting is available in script as navigator.connection.saveData, which is true when the user has chosen a reduced data usage option. MDN marks the header as experimental, so support is not guaranteed, and the prefers-reduced-data media query is not supported by any browser at the time of its page.

A cautious way to use it is to skip extras and leave the essentials alone:

const saving = navigator.connection && navigator.connection.saveData;
if (!saving) {
  // Start the background video, load the chat widget, and so on.
}

I ran this check in headless Chromium with the setting stubbed on and off. With it on, the extras were skipped, and with it off they ran.

How to test

1. Throttle the network in DevTools and reload. Watch the page build. Add the CPU slowdown. See the Network panel.
2. Run Lighthouse in mobile mode and read the metrics, remembering that its settings are a mid-range case.
3. Try a real, older phone on a real connection, away from the office. See testing on real phones.
4. Look at the slow end of your field data. The Chrome UX Report shows the share of visits that were slow, not only the 75th percentile. Real user monitoring can add the connection type: MDN lists effectiveType values from slow-2g to 4g in browsers that support it.
5. Turn JavaScript off and see what remains. See JavaScript and SEO.

Mistakes to avoid

• Testing only on a fast office connection.
• Treating "passes in Lighthouse" as "fast for everyone".
• A first screen that needs a large script before it shows anything.
• Autoplaying video for visitors who may be paying by the megabyte.
• Ignoring the slow tail in the field data.
• Building a page that fails if one script fails.

Check your own page

Run the free audit and note the page weight and the number of requests. Then open the page in DevTools with the network slowed down, and note how long it takes before you can read the main text and use the main button.

Sources

• Page Weight chapter, Web Almanac 2025: the cost of weight in transmission and rendering, and why weight is an access issue.
• Lighthouse throttling in the Lighthouse documentation: the mobile network and CPU settings and what they represent.
• Defining the Core Web Vitals metric thresholds on web.dev: the 75th percentile and why it was chosen.
• MDN: the Save-Data header, saveData, prefers-reduced-data and effectiveType.