Firefox 57 sped up page loads by delaying tracking-domain scripts instead of blocking them

By 2017 a typical page loaded dozens of third-party scripts, and the tracking ones sat in the same network queue as the content the user was actually waiting for. Firefox Quantum (version 57) rewrote its network request scheduler, and one of the changes used the Tracking Protection database to delay loads of scripts from tracking domains while a page was still actively loading and rendering. Mozilla engineer Jan Bambas called the technique tailing.

The blunt option was to block trackers outright, but Firefox already had Tracking Protection for that, and blocking breaks sites whose rendering or business depends on those scripts. The other obvious option was to do nothing and accept that analytics and advertising payloads competed with real content. Tailing split the difference: nothing was disabled, only deprioritized.

Requests to tracking domains were held only while the site's own sub-resources were still loading, and only for up to about six seconds. Scripts added dynamically or loaded async could be delayed, while tracking images, XHRs and anything a tracking script requested were always delayed. Because the HTML specifications leave download scheduling and prioritization to the browser, the change was legal by the rules of the web, and well-built sites saw no functional difference because nothing they showed depended on a tracker.

The gain in page-load performance came from saving network bandwidth, I/O and CPU for the images and scripts the site itself needed. The visible cost landed on poorly built sites: Google's A/B testing snippet, which hid a page with opacity zero until a script from www.google-analytics.com unhid it, could leave the page blank for four seconds, and a site like L'Équipe that called Twitter's API from a sync script failed when the delayed async script was not there yet. Bambas argued those sites had only worked by luck, since the same races broke them under private browsing or tracking protection.

Delay instead of block: hold tracking-domain requests until the page's own resources finish, then release them

Trackers are rarely needed to render a page, so delaying them frees bandwidth, I/O and CPU for the site's own resources without visibly changing what the user sees.

Delaying instead of blocking keeps the feature within the HTML specifications and does not destroy analytics or ad economics, only postpones them.

The Tracking Protection database already classified third-party domains, so the scheduler gained a priority signal without building or maintaining a new list.

Sites that broke were depending on trackers to render or on a race that won only because tracker servers answered fast, so the regressions exposed real fragility rather than a wrong tradeoff.

When you cannot remove a cost, reschedule it: hold low-value work until after the user-visible load finishes, and you capture most of the benefit without the fight

Tailing shipped inside Firefox 57 (Quantum). Bambas's December 2017 explainer drew a 472-point, 261-comment Hacker News thread plus coverage from Bleeping Computer and gHacks. The regressions Mozilla logged, including Google's page-hiding snippet blanking pages for up to four seconds, went to Bugzilla, and Bambas argued affected sites needed fixing to adopt the new scheduling. He added that broader measurement was still on its way and local tests had shown the gain buried in noise, so the full payoff was not yet quantified.