search

WICG / pending-beacon

A better beaconing API
Other
43 stars 8 forks source link

Pending requests in cancelled prerendering pages #82

Open mingyc opened 11 months ago

mingyc commented 11 months ago

There are some discussion about whether a pending (or deferred) fetchLater request should be sent if a prerendered page is cancelled, i.e. not actually visited by users.

Do developers expect such requests be made or not?

tunetheweb commented 11 months ago

My opinion is no. A non-activated prerendered page basically never happened from a user perspective as far as I’m concerned.

In fact for prerender we advise to prevent any analytics firing until the page is activated: https://developer.chrome.com/blog/prerender-pages/#impact-on-analytics. Google Analytics does this by default as of this month.

I can raise this with some RUM providers for their opinions.

nicjansma commented 9 months ago

For Akamai's mPulse RUM (which uses boomerang.js), we plan on stopping any beacon from being sent until a page is activated.

So for our case, fetchLater() not firing a beacon if the page isn't activated, seems appropriate.

tunetheweb commented 9 months ago

So chatted with a few RUM providers (including @nicjansma above!) and general consensus seemed to be that they likely wouldn't fire beacons on non-activated pages anyway so don't need the API to support this.

However, one did raise the point that, while they didn't see a use case for it right now, other JavaScript APIs work on prerendered pages (though some user-facing ones are delayed until activation) so there should be a good reason why this one (which is specifically there to be reliable), wouldn't in case anyone did want to use it (e.g. to more easily track the number of prerendered pages that were not activated). Which I think is a fair point.