1962817 - Deprioritizing the kameleoon.js tracker (in the interests of letting pages render faster) actually causes pages to render slower

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect, P2)

Description

[Daniel Holbert [:dholbert]]

See bug 1954927 comment 15.

I think we've got a mechanism to defer the network loads for resources that we're allowing to load but which get classified as trackers, added in bug 1358060. As I understand it, the intent is to let pages load faster, but at least in the case of https://y53sxvyp2y.kameleoon.eu/kameleoon.js , this makes pages appear to load slower, because the main page explicitly hides itself until the script is loaded and run (with a slow setTimeout-based fallback codepath that runs if the script is blocked or too slow, which is what currently happens for us).

We should probably make our tracker-script-network-request-deferring more nuanced, so that we can have some sort of allow-list of for trackers like this one that we think will not be helpful to defer (where we have reason to believe that deferring the tracker will defer the page's rendering).

Comment 1

[Daniel Holbert [:dholbert]]

To be clear, here's the reason I think that some tracker-based-tailing logic is kicking in and causing trouble here (from investigating bug 1954927):

(1) we have some documentation saying that the TailAllowed flag gets added for trackers:
https://searchfox.org/mozilla-central/rev/d65eb426c0e9f5cade6dfbf5e3f4e1b1903b6d04/netwerk/base/nsIClassOfService.idl#113-116

// Tailing may be engaged regardless if the load is marked Unblocked when some
// other conditions are met later, like when the load is found to be a
// tracker.
const unsigned long TailAllowed = 1 << 9;

(2) kameleoon does show up as an allowed tracker in the "allowed tracking content" list under the Tracking Protection shield (from the URL bar), which suggests that this tracker-based TailAllowed status might be kicking in.

(3) kameleoon's js file does show up as "Unblocked | TailAllowed" (and takes quite a long time, 5.8s) in a pageload profile there:
https://share.firefox.dev/4lNklXt
(and that slow load time directly contributes to the page rendering being delayed as discussed in bug 1954927 comment 15).

(4) Turning off network.http.tailing.enabled altogether makes the page load much faster, per bug 1954927 comment 16.

Comment 2

[Daniel Holbert [:dholbert]]

[editing to complete half-typed comment]

It looks like bug 1915866 is filed with some thoughts/observations about the current default value of this "tailing" networking pref sometimes leading to slower render times, too.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Are all pages that use this tracker made slower by deferring it?

Some type of allowlist of tuples of (site,tracker) with * being allowed would probably be most flexible. For site, *, .foo.com, and maybe .foo.com/bar/ patterns should be allowed. For tracker, maybe path and path/. I don't think we need to go to something like URLPattern, though maybe that's simpler than hand-building matchers.

If there is any sort of extensive list for these, something more performant than a list we constantly match against for every URI load may be needed. Also wildcards (especially fancy ones like URLPattern) are more expensive

Thoughts?

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #3)

Are all pages that use this tracker made slower by deferring it?

I don't know; this is the only site that I've seen using this script.

In this case, the pattern that makes the pageload slower-when-deferred is quoted in bug 1954927 comment 7, and it's in the page's own inline JS (rather than being in the external kameleoon.js resource).

I was assuming that this was some boilerplate "here's how to integrate our script" copypastable snippet which most/all usages might have, but I guess I don't know that for sure.

Comment 5

[Andrew Creskey [:acreskey]]

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #3)

Are all pages that use this tracker made slower by deferring it?

Thoughts?

Since blocking on deferred trackers loading can be pretty disruptive to the user experience I think we should continue to log cases where we see them.
We could also consider changing the deferral mechanism to be a bit more efficient.

Comment 6

[Andrew Creskey [:acreskey]]

I'm not sure what action we can take here --
In bug 2008101 we fixed an issue where content trackers were being tailed in Fenix.
In bug 1954927 I'm no longer seeing the kameleoon.js tracker being loaded.

Do we have other examples of trackers delaying navigation?

Comment 7

[Valentin Gosu [:valentin] {{ IETF until 25 July - PTO until 3 August }}]

A similar issue is in bug 1986887 - but it's actually a webcompat issue.
We could create a synthetic testcase that loads google analytics and hides the content until that is loaded 🤔

Comment 8

[Andrew Creskey [:acreskey]]

I'm working on a synthetic test case that highlights the impact of different values for network.http.tailing.delay-quantum.

But I wonder if this would be a good time to run Nimbus experiments with various settings/ disabled? i.e. bug 1915866

Comment 9

[Andrew Creskey [:acreskey]]

I've started to collect recent data on the performance impact of tailing.
Using the following variants to test a small number of live sites with trackers as well as a work-in-progress synthetic "wait for tracker tailing before rendering page".

baseline: (default, network.http.tailing.delay-quantum:600
tailing_off: network.http.tailing.enabled:false
tailing_300ms: network.http.tailing.delay-quantum:300
tailing_1200ms: network.http.tailing.delay-quantum:1200

These results haven't been reproduced; just early data.
Live pageload comparison
But the (edit: default) tracker tailing may be beneficial for visual metrics on CNN.com (although possibly hurting time to first interactive).

Comment 10

[Andrew Creskey [:acreskey]]

I think it would be useful to run Nimbus experiments that (a) disable tracker tailing, if privacy allows, and (b) tune the tailing delay constant (default: 600ms × #requests).

We can also consider adding the number of trackers encountered on a navigation to the pageloadEvent.
With that in place, we could measure tracker tailing changes for high-tracker sites (like CNN.com).

Comment 11

[Benjamin VanderSloot [:bvandersloot]]

(a) disable tracker tailing, if privacy allows

That's acceptable from a privacy perspective.

Comment 12

[Andrew Creskey [:acreskey]]

Bug 2011996 looks at adding the number tracker scripts encountered on a navigation to the pageload event

Comment 13

[Andrew Creskey [:acreskey]]

Experiment, tracker-resource-tailing, is live on Desktop nightly.
Considering this as exploratory.

Comment 14

[Andrew Creskey [:acreskey]]

Since, as far as I can tell, we are not looking at any pages with issues relating to the kameleoon.js tracker, maybe we can close this bug?
(kameleoon.js used to be present in bug 1954927)

And then we can look at the performance impact of tracker tailing in bug 1915866?

Or if we want this bug to specifically track web compat impact of tracking, then maybe we can rename it?

Comment 15

[Daniel Holbert [:dholbert]]

That seems fine, yeah. Let's close as WFM since there aren't any known issues coming from this at the moment.