Testing on a Throttled Connection

Two different kinds of slow

Bandwidth is how much can arrive per second, and latency is how long it takes for anything to start arriving.

A rural or mobile connection frequently has adequate bandwidth and poor latency, which is a different problem with a different remedy.

Making files smaller helps a bandwidth problem.

Making fewer requests helps a latency problem, and most small business sites have a latency problem.

Why latency multiplies

Since this is the part that is not obvious.

Every request involves a round trip: the browser asks, and waits for the reply to begin.

On a good connection that wait is a few tens of milliseconds and on a mobile one it can be two or three hundred.

A page making sixty requests pays that wait many times over, and if some of those requests are only discovered after earlier ones complete, they add up rather than overlapping.

So the same page that loads in a second on office broadband can take eight on a connection with the same bandwidth and worse latency.

Which is why weight alone is a poor predictor of how a page behaves in the field.

What this changes about the fixes

• Fewer files beats smaller files.
• Fewer domains beats fewer files.
• Shorter chains beat everything.
• Text appearing early beats total load time.
• Compression still helps, just less.

The second is worth emphasising, since each new domain costs a full setup before any file arrives. Six files from your own server is one setup; six files from six services is six.

Throttle it properly

Since the presets in browser tools are approximations.

Most tools offer a slow connection preset, which usually models both reduced bandwidth and added latency.

The latency figure matters more than the bandwidth one for this purpose, so check what the preset is applying and adjust it if the tool allows.

Something around two hundred milliseconds of added delay is a reasonable model for mobile data in a poor area.

Test with that and watch the network view, where a latency problem is visible as many short bars each starting after a gap.

A bandwidth problem looks different: fewer, longer bars.

A worked example

A business had a light site of about eight hundred kilobytes that took nine seconds on a rural connection.

The weight suggested it should have been fine, and reducing images further changed almost nothing.

The network view showed seventy-one requests across fourteen domains, most of them small.

Consolidating scripts, self-hosting the fonts, and removing three unused services brought it to thirty-one requests across five domains.

The same connection then loaded the page in under four seconds, with the total weight almost unchanged.

Nothing had been made smaller, and a great deal had been made fewer.

Count requests and domains

Since those are the numbers to watch for this.

Open the network view and note two figures: the total number of requests and the number of distinct domains contacted.

Record those alongside the weight in your quarterly note, since they move independently of it.

For a small business page, somewhere under forty requests and under six domains is a reasonable target.

Above that, a poor connection will be experiencing the site considerably worse than any weight figure suggests.

Those two numbers are also easier to act on than a weight figure, since each one has a name attached to it and can therefore be questioned individually.

Where your customers actually are

Since this decides how much any of it matters.

A business serving a dense urban area with good coverage has a different problem from one serving a valley or a rural route.

Look at where your enquiries come from and consider what coverage is like there, which for a local business is something you probably know.

Anybody whose customers are on job sites, in vehicles, or outside built-up areas should assume poor latency as the normal case rather than the exception.

And a business whose customers are all on office broadband during working hours can reasonably weight this lower than a trade whose enquiries arrive from vehicles.

Make something useful arrive first

Which is the practical remedy when latency cannot be reduced further.

The first response should contain the heading, the opening text, and the telephone number, so a visitor has something usable while the rest arrives.

That means those things being in the page itself rather than assembled by code that has to be fetched first.

On a slow connection the difference between a usable page in two seconds and a complete page in nine is the whole outcome.

Check by throttling heavily and watching what appears in the first two seconds.

Test the form, not just the page

Since a slow connection affects what happens after the page has loaded, and nobody checks that.

Submitting a form on a poor connection can take several seconds with no indication anything is happening, so people press the button again.

That produces duplicate enquiries at your end and, at theirs, the impression that nothing worked.

Make sure the button shows something has been received the moment it is pressed, before any response arrives from the server.

Test it throttled, submit the form, and watch what the visitor sees during the wait, which is the part of the journey that actually matters commercially.

The counter-case

Connections have improved.

Coverage is considerably better than it was, and the worst cases affect a smaller share of visitors each year.

Reducing requests can also conflict with other things worth having, and consolidating files has its own trade-offs.

And for a business whose customers are all in a city on good connections, weight and requests both matter less than the content does.

Count your requests and domains, test with added latency rather than only reduced bandwidth, and get the text into the first response.

What to check

1. Count total requests.
2. Count distinct domains.
3. Throttle with added latency.
4. Watch for gaps between bars.
5. Consolidate and self-host where you can.
6. Check what appears in two seconds.
7. Record both numbers quarterly.

Step two is the figure nobody tracks and frequently the largest single lever, since each additional domain costs a full connection before it delivers anything.

Who this affects is covered in how fast your site is on rural data.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.