Create a Performance audit for avoiding the unload event

[kaycebasques]

Feature request summary

Warn web developers that they should avoid unload events and use visibilitychange instead.

I am willing to work on this. Seems like a relatively easy audit to implement.

What is the motivation or use case for changing this?

https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid

How is this beneficial to Lighthouse?

It's an easy-to-detect change that could help improve the reliability and performance of websites.

P.S. How is this beneficial to Lighthouse? is a strange phrasing. Seems like it should be How is this beneficial to the web?

[addyosmani]

I think this is interesting to consider if we can get detection heuristics on when to recommend visibilitychange right (always?).

Developers should be careful using unload and beforeunload generally:

• Pretty unreliable on mobile browsers. Sometimes if a page is evicted by the OS due to memory pressure there isn't a guarantee these events will fire.
• Not great to rely on them unconditionally as they can break the back/forward cache

That said, in previous years both Chrome and Safari have had bugs where they won't fire visibilitychange in certain scenarios during page unloading, but I believe are mostly reliable.

Would be good to get @philipwalton's opinion here.

[philipwalton]

I actually discussed this idea with @patrickhulce and @brendankenny a few years ago. At the time I was hoping to implement the audit myself, but I never got around to it.

Now that Chrome is about to ship bfcache, I think something like this would be super useful. Brendan, do you think you'd have bandwidth to take this on?

[connorjclark]

FYI for those who haven't heard of bfcache:

https://www.chromestatus.com/feature/5815270035685376
https://developers.google.com/web/updates/2019/02/back-forward-cache
https://bugs.chromium.org/p/chromium/issues/detail?id=511340

I don't see any indication of when it'll land.

[brendankenny]

I actually discussed this idea with @patrickhulce and @brendankenny a few years ago. At the time I was hoping to implement the audit myself, but I never got around to it.

we also had the ancient #871 for beforeunload, which is somewhat related (though that issue was more focused on the sendBeacon migration aspect).

Now that Chrome is about to ship bfcache, I think something like this would be super useful. Brendan, do you think you'd have bandwidth to take this on?

sure, though @kaycebasques called it :) I'll make it your call Kayce.

I guess one question is while this is a good practice in isolation, would it be more helpful to users to have a bfcache-able audit with the requirements rolled up into a single place?

[rockeynebhwani]

@kaycebasques - Thanks for implementing this audit. Most of our sites are being flagged now by this audit. In our cases, these unload events are coming from third party scripts (like bot detection / marketing etc). For example, In screenshot attached, we see it coming from PerimeterX (Bot Detection) / Facebook / Dynatrace (RUM)

In this case, does it really impact backward/forward cache OR this audit should be more about unload events from first party scripts.. ? Sorry.. I am not very familiar with this but this got my attention when I was going through latest lighthouse audits.

@philipwalton / @addyosmani

[patrickhulce]

@rockeynebhwani they may confirm but AFAIK the origin of the script that installed a listener has absolutely no impact on whether the page is eligible for bfcache (and I would be shocked if this were the case).