Measuring Speed The Slow Way
By Steve
Lamm, Member of Technical StaffLet's say you figured out
a wicked-cool way to speed up how quickly your website loads. You know with great certainty
that the most popular web page will load much, much faster. Then, you remember that the page
always loads much, much faster in your browser with the web server running on your development
box. You need numbers that represent what your users will actually experience.
Depending on your development process, you may have several measuring
opportunities such as after a live release, on a staging server, on a continuous build, or on
your own development box.
Only a live release gives numbers that users
experience--through different types of connections, different computers, different browsers.
But, it comes with some challenges:
- You must instrument your site (one
example tool is jiffy-web).
- You
must isolate changes.
- The most straight-forward way to do that is to
release only one change at a time. That avoids having multiple changes altering performance
numbers--for better or for worse--at the same
time.
- Consider releasing changes to a subset of
users.
- That helps safe-guard against real-world events like holidays, big
news days, exploding hard drives, and, perhaps the worst possible fate of all: a slashdotting.
Measuring
real traffic is important, but performance should also be measured earlier in the development
process. Millions of users will not hit your development web server--they won't, right?! You
need a way to measure your pages without that.
Today, Steve Souders has
released
Hammerhead, a Firefox
plug-in that is just the ticket for measuring web page load times. It has a sweet feature that
repeatedly loads pages both with and without the browser cache so you can understand different
use cases. One thing Hammerhead will not do for you is slow down your web connection. The page
load times that you measure on your development machine will likely be faster than your users'
wildest dreams.
Measuring page load times with a real DSL or dial up
connection would be ideal, but if you cannot do that, all hope is not lost. You can try the
following tools that simulate slower connection speeds on a single
box:
Please share your own favorite tools in
the comments. Each of these tools is super easy to install and setup options to simulate
slower connections. However, they each have some caveats that you need to keep in mind.
Firefox Throttle hooks into the WinSock API to limit bandwidth and avoids
using proxy settings. (If you use it, be sure to disable "burst-mode".) Right now, Firefox
Throttle only limits bandwidth. That means it controls how much data arrives in a given time
period after the first bits arrive. It does not limit latency. Latency controls how long it
takes packets to travel to and from the server. See Wikipedia's
Relationship
between latency and throughput for more details. For certain webpages, latency can
make up a large part of the overall load time. The next Firefox Throttle release is expected
to include latency delays and other webmaster friendly features to simulate slower,
less-reliable connections. With these enhancements, Firefox Throttle will be an easy
recommendation.
Fiddler and Charles act as proxies, and, as a result
they make browsers act rather differently. For instance, IE and Firefox drastically limit the
maximum number of connections (IE8 from 60+ to 6 and FF3 from 30 to 8). If you happen to know
that all your users go though a proxy anyway, then this will not matter to you. Otherwise, it
can mean that web pages load substantially differently.
If you have
more time and hardware with which to tinker, you may want to check out tools like
dummynet (FreeBSD or Mac OS
X), or
netem (Linux).
They have even more knobs and controls and can be put between the web browser hardware and the
serving hardware.
Measurements at each stage of web development can
guide performance improvements. Hammerhead combined with a connection simulator like Firefox
Throttle can be a great addition to your web development tool chest.