The latest release of Firefox is a quantum performance improvement over previous releases; so much so that it’s code-named “Quantum”. Mozilla programmer Honza Bambas explains the trick on his blog:

Firefox Quantum – version 57 – introduced number of changes to the network requests scheduler.  One of them is using data of the Tracking Protection database to delay load of scripts from tracking domains when possible during the time a page is actively loading and rendering – I call it tailing.

This has a positive effect on page load performance as we save some of the network bandwidth, I/O and CPU for loading and processing of images and scripts running on the site so the web page is complete and ready sooner.

Bambas separates the visible parts of the page from the invisible tracking code. He then puts the good parts in a fast lane and the bad parts in a slow lane. The tracking code all gets loaded, but it can wait up to six seconds while the parts you care about load right away.

What a Clever Idea!

Bambas deserves a medal for cracking the code on web performance, so I reward him by using his program. Like many, I was once a loyal Firefox user who switched to Safari and (horror of horrors) Chrome for performance.

I don’t care much about the Mozilla fixation on privacy, but I really like speed. Quantum is noticeably faster than Safari and Chrome and you don’t have to worry so much about privacy if that’s your thing.

This should have been obvious to other browser developers because the web has failed to keep up with broadband networks for some time. I even wrote a paper about the web’s performance issues that you’ve seen me mention if you’ve been here before: “You Get What You Measure: Internet Performance Measurement as a Policy Tool“.

How it Works

Bambas diagrams the effects of tailing  on the loading of visible page elements (blue) and tracking code (brown). With tailing turned on:

With tailing on, tracking code doesn’t slow down page code.

With tailing turned off, the tracking code slows down the page elements you want to see:

With tailing turned on, the page code has to wait for the tracking code.

It’s a Matter of Priorities

We all have priorities. We like some things more than others, value some things more than others, and pay more for some things than for others. So why can’t we tailor the behavior of the Internet around our priorities?

The one shortcoming of the Firefox Quantum approach is that it gives very little control to the user: tailing is either on or off, but we can’t tell Firefox what to delay and what to accelerate. That’s not a big deal for now, but I’d like a future release to incorporate audio/video blocking so sports sites can’t grab my speakers to abuse me with noisy ads.

There are four tunable parameters, however:

Tunable Tailing Parameters

According to Bleeping Computer: “Users can edit the first two parameters (network.http.tailing.delay-quantum-after-domcontentloaded and network.http.tailing.delay-quantum) to change the minimum delay values, the third (network.http.tailing.delay-max) for the maximum value, and the last (network.http.tailing.enabled) to disable or enable the tailing effect altogether.” Good to know.

Are the Trackers Upset?

Apparently this is all OK with the trackers, because they like the way it improves the user experience:

“From what is described here, it may actually help us. When folks throw tons of tags into their site, we’re all competing against each other as well as the site’s own loading, it makes sense to prioritize the site’s rendering,” said John Clover, an engineer for Heap Analytics. “I think Mozilla’s heart is in the right place.”

Most users often blame sketchy advertising and tracking code for delaying a site’s loading process. With Mozilla putting the focus on code needed to render the page, sites will load faster, and users will be able to use them sooner. Analytics firms don’t lose anything in the process. The tracking scripts will still load, but with fewer user complaints.

So there you are: discrimination, when done intelligently and with ones heart in the right place, improves user experience. Fast lanes are good and so are slow lanes. Browsers that apply our priorities to the websites we visit are better than those that treat all content as if it were the same. Web neutrality sucks.

Can ISPs do Tailing?

In a word, no; or at least not exactly. Now that ISPs are free of the shackles of Title II net neutrality, they could delay access from browsers to tracking and analytics domains. This is pretty easy because the browser has to issue DNS requests for them even when the web page is encrypted.

ISPs could build the same kind of blacklist that Mozilla has built and delay DNS resolution. Or they could simply buffer requests to these “bad” domains for a few seconds just as Firefox does. But it’s better to do this sort of thing with full knowledge of the page code as Mozilla does. They see unencrypted code, of course.

But ISPs can do similar things, such as ensuring low latency for Skype by delaying Netflix when traffic load is heavy. Just as the Quantum approach improves user experience, delaying an occasional Netflix packet would not degrade video quality even though it would help Skype.

Impact of Prioritization on TCP

The BITAG report on traffic management explains this (page 24):

If voice is prioritized over TCP traffic, the TCP traffic maintains the same QoE* as it would without prioritization. This is true because both the capacity used by voice traffic (sent over UDP, which does not change rate in response to congestion) and the overall capacity of the network links are independent of whether or not the voice traffic is prioritized. Simple subtraction shows that the remaining capacity available for TCP traffic – that is, the difference between the overall capacity and the capacity used by voice – is also independent of whether or not the voice traffic is prioritized. The only observable difference in the QoE of the TCP traffic is an increase in delay variation relative to the optimal delay. If the increase is relatively small TCP performance will not be adversely affected. Since TCP is insensitive to moderate amounts of relative delay variation, its QoE is not affected by the prioritization of the voice traffic.

*QoE = Quality of Experience perceived by the user.

So TCP is affected by the volume of traffic in a shared pipe, but not by the placement of individual packets. Prioritization by placement is not a zero sum game.

Are We Going to See This When the Internet is Free?

ISPs aren’t going to rush out and prioritize Skype and Vonage over video streaming, however. Comcast did that once and got no end of grief from the FCC and the pressure groups for it. They also wouldn’t have much call for it because their networks are rarely congested enough for packet placement to matter.

The takeaway from this story is that CPUs are often greater bottlenecks to web performance than networks. That tracking code is JavaScript snippets, pieces of computer code that have to be executed while pages are loading.

Some of the JavaScript starts auctions that take considerable time – on the order of seconds – to complete. That’s also a CPU-intensive activity.

So the bottlenecks in the web aren’t necessarily where you’ve been taught to think they are. Quite often, the computers themselves – browsers and servers – are causing the delays you see when surfing the web.