Close-up photograph of a Boeing 747's Air Bridge Cargo throttle controls

The trend towards larger and larger web pages – hovering at an average of just under 2MB, as of this writing – is enhanced by the fact that most sites are designed, developed, and tested on desktop computers. While responsive web design is here to stay, “mobile testing” is very often regulated to simply making the browser smaller and seeing how the site looks at various window sizes, with more extensive testing left to a device lab.

Ideally, we want to replicate mobile features on the desktop. That’s not just smaller screens and simulated touch UI, but also the limited bandwidth* of handheld devices. All of these factors have to be taken into account when building a modern site, and should be tested as the site develops.

If you are developing on a Mac, you can download XCode and use the Network Link Conditioner buried in the tools, or do achieve the same ends with the menu bar app Slowly. In Windows, you could download and install Clumsy. If you were writing a Node application, you could install stream-throttle, or if Grunt was part of your workflow, grunt-throttle.

Screenshot of network throttling in Chrome CanaryBut for all of their benefits, these applications might be accused of rather missing the point. Whatever web developers are creating, they’re almost certainly viewing in a browser. The applications above tend to throttle the entire browser, or even the compete operating system, resulting in a poor overall experience. Ideally, we want native throttling built right into the browser, available on a tab-by-tab basis.

The good news is that, as of this writing, we have just that. The bad news is that, right now, the throttling features are only present in the latest build of Chrome Canary, although I would expect them to transfer into the standard web developer tools of every browser soon.

Network Throttling In Chrome

The Developer Tools in Chrome Canary have matured and deepened significantly, making the Throttling controls just slightly tricky to get to:

  1. First, open the developer tools panel. (Right click anywhere on the page and choose Inspect Element, or press CMD+Opt+I)
  2. Click on the mobile device icon in the top left corner of the Developer Tools panel.
  3. At the top of the browser window you’ll now see options to limit network throughput in a dropdown menu in the panel: you can simulate anything from being completely offline to a good, stable 3G connection.
  4. You’ll need to refresh the browser in order to see the loading experience under the new network conditions; you also have the option to simulate different device profiles.

It’s important to note that this ability doesn’t replace actual device testing: there’s nothing that can completely substitute for the physical experience of engaging with your site on a phone or tablet. However, it does potentially delay the need to do so, meaning you can spend more time in development and less in the device lab.

*It’s a very common mistake to confuse bandwidth with throughput, a confusion I’m afraid I’m continuing here. Technically, bandwidth is the peak capacity of a communications protocol; throughput is the actual amount of data successfully received every second. For obvious reasons, ISP’s advertise the bandwidth they provide to customers; the actual experienced throughput will always be less.

Photograph of Boeing 747 Air Bridge Cargo throttle controls by Dirk-Jan Kraan, licensed under Creative Commons

Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.