Scott Hanselman

How to simulate a low bandwidth connection for testing web sites and applications

October 29, 2015 Comment on this post [26] Posted in Open Source
Sponsored By

Facebook just announced an internal initiative called "2G Tuesdays" and I think it's brilliant. It's a clear and concrete way to remind folks with fast internet (who likely have always had fast internet) that not everyone has unlimited bandwidth or a fast and reliable pipe. Did you know Facebook even has a tiny app called "Facebook Lite" that is just 1Mb and has good support for slower developing networks?

You should always test your websites and applications on a low bandwidth connection, but few people take the time. Many people don't know how to simulate simulate low bandwidth or think it's hard to set up.

Simulating low bandwidth with Google Chrome

If you're using Google Chrome, you can go to the Network Tab in F12 Tools and select a bandwidth level to simulate:

Selecting lower bandwidth in Google Chrome F12 Tools

Even better, you can also add Custom Profile to specify not only throughput but custom latency:

Custom Profiles for Google Chrome that control throughput and latency

Once you've set this up, you can also click "disable cache" and simulate a complete cold start for your site on a slow connection. 20 seconds is a long time to wait.

Google Chrome timeline showing my site on a 2G connection

Simulating a slow connection with a Proxy Server like Fiddler

If you aren't using Chrome or you want to simulate a slow connection for your apps or other browsers, you can slow it down from a Proxy Server like Fiddler or Charles.

Fiddler has a "simulate modem" option under Rules | Performance, and you can change the values from Rules | Customize Rules:


You can put in delays in milliseconds per KB in the script under m_SimulateModem:

if (m_SimulateModem) {
// Delay sends by 300ms per KB uploaded.
oSession["request-trickle-delay"] = "300";
// Delay receives by 150ms per KB downloaded.
oSession["response-trickle-delay"] = "150";

There's a number of proxy servers you can get to slow down traffic across your system. If you have Java, you can also try out one called "Sloppy." What's your favorite tool for slowing traffic down?


There is SO MUCH you can do to make the experience of loading your site better, not just for low-bandwidth folks, but for everyone. Squish your images! Don't use PNGs when a JPEG would do. Minify! Use CDNs!


However, step 0 is actually using your website on a slow connection. Go do that now.

Related Links

Sponsor: Big thanks to Infragistics for sponsoring the feed this week. Quickly & effortlessly create advanced, stylish, & high performing UIs for ASP.NET MVC with Ignite UI. Leverage the full power of Infragistics’ JavaScript-based jQuery/HTML5 control suite today.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
October 29, 2015 3:03
90% of the delay from content is going to be in images, and I completely agree with your suggestion for compression and choosing the right type of file in the first place.

However, there is another point to make regarding approaches to content with regards to using images as layout. On this page, you use a small image and a css class to repeat that small image as the background to your header. This is a great example of using css and a very small footprint in order to accomplish a visually appealing graphic.

It is important when designing to always attempt to create graphical content using processing power when possible, and that means leveraging the rendering engine by smart use of css such as the example shown above.

Thanks for the tip on the bandwidth testing. Luckily my worst case scenario was 3 seconds at 2G which I think is acceptable. Often I use lazy loading for images, however this post made me consider the memory of loading a set of images in the background and what some of that implication may be on older devices. If only there were a way to cap the memory use of a page in chrome similar to this bandwidth tool.
October 29, 2015 4:10
Just thought I'd mention that Chrome's throttling does not influence upload speeds.

Stack overflow
October 29, 2015 5:41
If you want to do this for a non-http app and have a spare pc (or even a VM, I guess), the Linux livecd WanEm can act as a router with configurable latency, bandwidth, jitter and packet loss.
October 29, 2015 5:55
Good info here. But to be clear, Facebook Lite is 1MB(megabyte) not 1Mb(megabit). Mixing the two can be especially confusing when talking about bandwidth, where bits/second is a common measure.
October 29, 2015 7:54
I've encountered the same limitation with Chrome, it not throttling upload traffic. I have yet to find a tool to simulate a slow upload, everything is so focused on downstream that they ignore up.
October 29, 2015 14:31
Thanks for the tip.

When I first read "2G Tuesday" I thought brilliant.that was until I read the story. The title should be "Optional 1 hour 2G Tuesday".


Slow bandwidth is not restricted to developing nations. I live in Australia's capital city. The best we can get at home is ADSL2 with max 5.2 Mbps down / 0.8 Mbps up. Don't get me started on the unbelievably poor 3G coverage at home.


It would great to see all US tech companies have 2G / 3G Tuesday's at least once a year.
October 29, 2015 15:42
"What's your favorite tool for slowing traffic down?"

I just use conference Wi-Fi. Guaranteed slowness and dropped connections galore!

October 29, 2015 17:36
As pointed out, Chrome won't limit uploads. A utility I ended up using when I needed to simulate slow uploads was an open-source app called clumsy (
October 29, 2015 18:27
Wish we could convince the financial companies of this, frankly. I was on holiday in rural Scotland and only had access to 2g wireless & tried to check my bank balance. Should have been 1 click, as logging into my bank takes me straight to the balances page. However, just loading the login page took around 20 minutes, what with all of the scripts to suck down (no CDN in use), and all of the freaking banner images to pre-load (yes - they have a scrolling banner of adverts, which load no matter what). I think, all told, it took 40 minutes or so to do what should have taken 30 seconds at most.

Actually, I wish we could convince everybody to do this. If I'm looking at pictures I may expect it to be slow, but if I'm actually trying to accomplish work, I expect speed, and could care less if the website looked like crap.
October 30, 2015 1:21
Thanks for the pointer to that utility, Robert!
October 30, 2015 18:29
I've used NetLimiter to accomplish this in the past. It works on the network connection, so affects all browsers.
October 30, 2015 20:35
What is unfortunate is that Chrome's throttling setting doesn't affect real-time communication (WebSockets basically) at all. Put to an offline-mode and everything works as usual.
October 31, 2015 0:50
Thanks for the tip, Scott. I usually work with FF, since Chrome is so sluggish for me. It is good to know how Chrome can do things others cannot.
October 31, 2015 4:58
Steve Souders just revealed at VelocityConf that WebPageTest have now integrated "real mobile networks" into their stack ("real networks, but emulated devices" - I think he said).
It's worth taking it for a spin to see how your site does on a mobile in Bangalore (and weep).
October 31, 2015 17:37
I second "clumsy", tiny little executable that nicely simulates all kinds of intermittent behaviour with slowdowns and drops.Very easily configurable, without any silly scripting that you have to do for fiddler
November 02, 2015 1:26
Scott, thanks for sharing this. I am huge on web performance first and have been meaning to share this tip.

Simon you are correct WPT has all sorts of great features to do synthetic testing of sites. It is my #1 web performance tool.

TrvisJ - Images still make up most of the payload, but that does not keep the page from rendering. I research this stuff all the time. Right now JavaScript is the biggest problem. Too many poorly designed frameworks, etc. But third party scripts also cause way too many problems. Notice all the articles about big performance gains with Safari's new 3rd party script blocking feature.

And it is not all about page load it is about how your content gets rendered. And of course what triggers rerenders and page layouts? You have to be smart and know how browsers work. You MUST realize the browser is not the server and network latency plays a big role in all this.
November 02, 2015 11:16
I use the chrome dev tools a lot. The bandwidth simulator is a good tool. But you should always test with a real slow connection too. The simulator does not show the actual feeling on a real poor mobile connection, that jumps around between 2G and 4G.

If you include many js files you should always have a look at the network tab of dev tools too. Each js file is a http request. Having 5 files from a cdn and another 5 from your domain can actually be slower than serving one huge bundle.

Also you should always serve resized images. I love this component for that:

For sure you should minify, cache and gzip everything you can.

But with all those good advice I often get into situations, where I fight with caching. On the one hand I need it bon the other hand it can drive me crazy. That's why I often end up in compressing and bundling everything but supressing cache by simply add a time stamp to the query string of every static file that could change on a application update.

How do you ensure that your users get the latest js code of a SPA for example? Any better idea than adding a magic query string, that works even in older IE versions or behind proxy servers?
November 03, 2015 12:03
This is a neat trick that I sometimes use... somehow I'm reminded of how Facebook slows down their entire network once every week (apparently).
November 03, 2015 16:55
Wow never ever noticed that before. Thanks Scott will give it a try. I have always designed thinking that a user is connected with a wet piece of string. Probably because when I started, people did have a wet piece of string to connect!
November 04, 2015 18:03
For anyone reading, I thought add a little bit of context here. In India, we're facing severe network congestion on our mobile networks. So, 2G isn't 2G. 3G is barely 2G and 4G/LTE is a major joke when/if you can get a signal.

Here's what we actually get:
2G: 10Kbps average, 35-50 Kbps peaks.

3G/3.5G i.e. HSPA/HSDPA/HSPA+: 50 Kbps average, wildly varying bursts of 350-1Mbps. The operator WILL throttle you down if you watch videos too long and/or if they suspect you of using torrents.

4G/LTE: IF you get 4G on your 4G phone, expect of wildly varying bursts between 10 Kbps to 4Mbps. No averages observed because 4G is a lie, just like the cake ;-)
November 04, 2015 18:54
I have been using toxiproxy ( to simulate network conditions. You can use it between parts of your stack to simulate multiple types of network events including low bandwidth.

Perhaps a little overkill for your use case, but it is awesome for testing for issues between all the parts of your distributed system.
November 05, 2015 0:12
You can use for controlling more low level stuffs.
November 10, 2015 11:00
...just do not forget to switch it back off. It was the worst three days of my life!
November 15, 2015 22:45
Great tip! Never used that option in chrome to check my website.
December 29, 2015 3:07
VMWare Player (free for personal use) has options to control the bandwidth and packet loss for upstream and downstream traffic.
January 04, 2016 23:31
Great post Scott. Will add that for Apple Developers there's the Network Link Conditioner option. For iOS developers simply head to the iOS Settings App > Developer > Network Link Conditioner Status, and enable it. If the developer option isn't available the user must register the device for development via Xcode.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.