anniesullie / web-page-abandonment-api Goto Github PK
View Code? Open in Web Editor NEWProposal for new API which makes it easier for developers to know when page loads were abandoned.
Proposal for new API which makes it easier for developers to know when page loads were abandoned.
One scenario that has come up with a customer site, where I'd like to use the Abandonment API, is what should or shouldn't happen when an "abandon" occurs that is desirable from the site owner's POV.
I think this would only apply if the Abandonment API supported a user signal from analytics providers to note when a page is no longer abandoned, i.e. analytics is "ready" to measure the rest of the experience. If the Abandonment API only supports waiting until FCP, I don't think this scenario applies.
Imagine this scenario:
/login
), before the rest of the page has been loaded and analytics has arrivedIn this case, the Login button could be considered a good thing, i.e. a conversion, even though the user didn't wait for the page to fully load or analytics to arrive.
What would the Abandonment API do in this case? Since the analytics switch didn't happen, I assume it would report it as an Abandon. And I think it should report something, since analytics isn't there yet to report anything.
But it might be useful if the report helped indicate this may be an "OK" abandon for the site owner. Some thoughts:
destination-url
or even just a same-origin-abandon: true
flagAlternatively, in this scenario, the site owner could hook into known exit actions (e.g. Login button click) and call the "analytics-ready" API so an Abandon isn't registered, but that would take additional work to get right.
FCP's appealing because it's a clearly defined point in the page load lifecycle but I suspect it's too early to measure abandonment.
I've had a few clients lately where the menu bar has rendered by the content has taken a while to arrive and we've seen visitors abandon while waiting for the main content.
To me it feels like we should treat someone leaving before the page is useful, or usable as abandonment but aware that's probably not possible for browsers to measure without the page being instrumented.
If we use a reporting API to report abandonment, there will be an overlap with the abandoned
error in the Network Error Logging API. That API is similar to this one, but subtly different:
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.
It's not clear to me what the goal is here. Is this meant to be a web API, as specified by the link? If it is, and not meant to be a Chrome-specific tool, then I'm not sure 'Chrome User Experience Report' would be a feasible option.
As a scenario mentioned on #6 , I believe we should clarify if and when will we be enabling the measurement of abandonment for navigations.
When to enable measurement:
Will this be configurable ?
Will we be able to switch between those with a configuration parameter ?
Saw "WebPerfWG call - June 18th 2020" video and these are some thoughts about the Abandonment API.
FCP seems a good metric to use in this case but it might be too early to measure Abandonment, not all websites will have the analytics systems ready at that point. We'll have users that abandon in the time window between FCP and analytics system load.
Personally I think that TTI could be a better replacement, even if TTI is not the best metric to track in the wild as many users exit the page before that, for the API this won't be a problem though. Even if users exit before TTI, calling the "analytics-ready" API to say "my tracking system is working" will stop calculating that as abandonment.
After all, the intent of the new API is to measure untracked abandonments so the main goal is to understand if and when an analytics system is ready to track a visit.
Eventually, it would be useful to have "reasons" for abandonment such as "click on the back button", "click on --", "new destination URL", "tab close", "User aborted the resource fetch" (think it's possible to copy this from NEL), or something similar, this to help webmaster debugging and filtering those specific website behaviours that shouldn't be counted as abandonment.
If this were to be exposed via the Reporting API, what kind of data might the payload contain?
Some thoughts:
url
etc would be desiredA declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.