Clarify why user turning off abort is undesirable

[npm1]

I thought about this idea too, but it's not clear from the explainer why this is considered a worse alternative to FCP? If the intention is to let analytics providers report their metrics, wouldn't letting them specify when the load is no longer an abort be a reasonable solution? There are some potential problems with this:

• Requires intentional annotation in order to get any valuable data, whereas the FCP approach does not. In particular, I'm not sure if reporting everything as an abort as the no-op is reasonable from a performance standpoint...

• There can be multiple analytics providers or multiple performance aggregators for the same webpage, so it could be problematic if the first one says that the load is no longer an abort, and incentivizes moving the aggregation earlier. Not sure how common this is.

[igneel64]

Really good call to get a discussion for more feedback around why the analytics provider turn off might be undesirable initially.

Just my thoughts on this one:

FCP as a baseline

FCP is considered and recognized by the web development/experience community as one valid and stable metric to evaluate the experience effect initial content rendering performance has on the user.
A web applications state (as in visual state) is considered incomplete before the FCP mark, since the user is not getting enough information about what he will be presented or what is the goal of this specific page. Both of these goals are achieved at least partially when "contentful paint" is reached.
So in my mind this makes FCP a good baseline for the chance of the user initiated page abandonment due to poor performance.

Not connecting the metric to analytics provider load signal

I can think of two points that for me would make much sense on why we do not want to go that way initially.

• First is I would keep that metric as "generic" as possible, since adding 'providers' to the picture could overcomplicate the initial definition. Also due to poor analytics provider conditions or bad implementation on the website owners side, the metric might lose "credibility" in the community.
• If for web developers this metric becomes something "valuable" to collect also in their analytics database or the providers platform e.g. Google Analytics etc, I am confident that we can design a scenario that this would be possible and even have this on the release page as proposed impementation. It goes like this:

The example that comes to my mind is that in the case that we add this new metric with the Reporting API capabilities, we can provide the web developer the data in the following flow:

1. When the "abandonment" happens, there is no guaranteed way for any custom JavaScript reporting code to confidently report this incident without hacks and tons of special cases. (That is also one of the main movers of this initiative I think). With our metric, we achieve to grab that incident and add it as an entry.
2. This reporting entry, if and when chosen to be exposed to the Reporting Observers, would be stored in the Reporting cache which will then be queriable for some (to be defined) TTL time, using the Reporting Observer API. Imagine giving the web developer the ability for something like "querying" for a "user initiated abandonment" for this specific user in the past (the previously mentioned TTL) with simple JavaScript on the page. This would internally search the Reporting cache for a past entry of this incident.
3. If by design the body of the abandonment reporting entry includes the timestamp that the user left the navigation, the web developer will be able to send this data to the analytics provider. Collecting this from every user that had this entry would just be a simple Reporting API Observer code snippet. As a required and sane step for further analysis she would need to have implemented also tracking for the metrics exposed through the Performance API.
   By having these data, he is then able to conduct a simple analysis comparing the median time a user has abandoned the page before FCP (our metric) with well known metrics such as TTFB, DOM Loaded, custom measurements etc.
   Then depending on his evaluation he can move to action

The bottom line, and the point that I would like to get through with this example is that without involving the analytics vendors at all, we give the target audience (developer, experience engineer, marketeer etc), a way to query this metric and use it to get something actionable.

[andydavies]

@npm1

There can be multiple analytics providers or multiple performance aggregators for the same webpage, so it could be problematic if the first one says that the load is no longer an abort, and incentivizes moving the aggregation earlier. Not sure how common this is.

IME multiple analytics / performance tool providers on the same page isn't unusual

There were/are similar issues to this with ResourceTiming – where New Relic was calling clearResourceTimings when the buffer was full and so other products couldn't collect them

This was the issue – https://discuss.newrelic.com/t/do-not-clear-the-resource-timing-buffer/54771 – not sure if it still applies, @nicjansma might know more

[nicjansma]

From an analytics provider POV, yeah, we encounter issues like this from time to time, where multiple third-party scripts / analytics are all playing in the same playground and step on each others' toes.

In cases where there's a shared global "something" -- like the ResourceTiming buffer and clearResourceTimings() -- we need to be extra careful to only call APIs like that if the page's owner specifically approves us to. Otherwise all analytics providers are potentially reporting bad / missing data.

It's certainly possible to do this right even if there are multiple analytics scripts, but it just takes a bit more work for the site owner to know which analytics to prioritize or have the abandonment signal to wait for.

I'd be in favor of optionally allowing for abandonment to be defined by the page, via some signal like an API or JavaScript variable to be read, in addition to automagic reporting based on a specific phase being reached (e.g. FCP being proposed).