Don't forget that bandwidth is only half (and most of time not the important half) of the story. Latency and packet losses usually have much stronger effect on website performance (see this classic paper http://www.stuartcheshire.org/rants/Latency.html or any of velocity 2010 videos).
There are a couple of free and commercial products that enable you to emulate latency, packet loss and bandwidth at the same time, just google that.
I saw precisely this in the (attempted) cross-continent deployment of some enterprise software. The amount of data being moved was relatively small, but the software was so damned "chatty" -- insisting on dozens of requests/responses for even the simplest operation -- that latency effectively killed it in this context.
I'd argued this point and that it be tested -- a simple network simulator would have sufficed. But management was willfully clueless, and the vendor wanted the sale more than an effective deployment.
Latency should be a part of any non-trivial testing.
When I was in India six months ago, I usually had a pretty bad connection and Twitter's web interface worked terribly.
- You had to wait for every single element on the page to load before you could click to use the login box - else you would jump to the login page itself and had to wait for that one as well.
- Clicking a list, clicking a saved search, basically everything with an ajax request doesn't have a really good indicator of that it's loading, so that experience was horrible.
- There were probably other issues as well.
Facebook on the other hand did amazing. Of all the websites I tried and used, Facebook was the most stable, was the quickest to load (in spite of all the JS, etc) and generally performed really well on a slow connection.
There are a couple of free and commercial products that enable you to emulate latency, packet loss and bandwidth at the same time, just google that.