The effect of Firefox addons on bandwidth consumption

Date: November 27, 2011 (Updated with additional figures December 4, 2011)

Dataset: the Alexa top hosts list, with country code specific dupes (ie following removed. The top 150 sites were then opened in order and I scrolled to the bottom of each page with the mouse cursor in the middle, engaging mouseover code as in normal browsing.

Methodology: All browser setups were self-contained. I created a .mozilla-vanilla, .mozilla-noscript, and so on, independently, and began each test with e.g. rm -rf .mozilla; cp -Rp .mozilla-noscript .mozilla before starting Firefox. Only one copy of FF was ever run at a time. The DNS cache listening on was also cleared before each test, and the packet filter statistics were "refreshed" with a simple pfctl -f /etc/pf.conf. All traffic-generating software (dhclient, ntpd, etc.) was killed before beginning the experiment. Packet and bandwidth statistics were pulled from pfctl -vs rules.

Operating System: OpenBSD 5.0
Firefox: 5.0 with the default settings
NoScript: 2.2 with the default whitelist
Adblock Plus: 1.3.10 with the default Easylist, updated November 27, 2011
MVPS: updated November 23, 2011. (Not technically a FF addon.)

NB: OpenBSD does not support Flash. This means that for most users, the bandwidth savings between plain Firefox and any combination below will be greater than the figures reported here, or at least, more in line with my results given that many people will enable (temporarily or permanently) more javascript than the default NoScript whitelist.

Pre-experiment assumption: Adblock Plus would deliver the greatest independent savings. (I was wrong.)

NoScript + MVPS946487888597769899234036070039245.8798%
NoScript + Adblock Plus9728185956088420510229916190719644.8038%
Adblock Plus1589351077899182019125743810043945710.4487%
Plain Firefox 51814331287711066164214969841121586260.0%
bandwidth savings summary

Post-experiment: I was surprised by the results, although they make sense because not only is javascript used to serve most ads (and tracking/stalking), but it's also used to support bandwidth-intense operations like reloading many images to create the appearance of image morphing.

In short, NoScript plus ad blocking in some form may reduce bandwidth usage in half. Additionally, NoScript is more effective than Adblock Plus in reducing bandwidth.

December 4, 2011 Update

I wanted to revisit this test, first to try reproducing results from the first test, and second, to determine how mass-whitelisting would affect bandwidth usage. For this test, I imported the top 150 sites into NoScript's whitelist while keeping the original whitelisted entries. Thus, every site I tested had been pre-whitelisted in NoScript. This test group is the "Extended Whitelist." I then proceeded with the test as normal, and here are the results:

NoScript + Default Whitelist10246796846380838211326866494106841.8144%
NoScript + Extended Whitelist133711110228339531912866798468199824.1270%
Plain Firefox 51827611370111003420915761251116103340.0%

NoScript 2.2.1 was used in the Dec. 4 test.

The bandwidth savings of NoScript from test #2 closely mirror those in test #1.

Conclusion: Javascript blocking via NoScript results in significant bandwidth savings. NoScript is more effective than ad blocking although the two are somewhat complementary. Additionally, blocking only 3rd-party javascript may result in a 24% reduction in bandwidth usage.