Create a Performance audit for avoiding the unload event
See original GitHub issueFeature 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?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:6 (3 by maintainers)
Top Results From Across the Web
Performance Audit - IDI
How do you develop a performance audit report? ... and conventions, and avoid any conduct that may discredit your SAI. • Confidentiality and...
Read more >Lighthouse: Reduce the impact of third-party code - GTmetrix
It is vital to review your website code for third-party scripts and reduce their impact as much as possible in the interest of...
Read more >Government Auditing Standards 2018 Revision
The 2018 revision of Government Auditing Standards is effective for financial audits, attestation engagements, and reviews of financial statements for periods ...
Read more >Understand how effects work - Azure Policy | Microsoft Learn
For example, policy definitions with effect AuditIfNotExists require ... Audit is used to create a warning event in the activity log when ...
Read more >Cloud Audit Logs overview
Admin Activity audit logs; Data Access audit logs; System Event audit logs ... but you can use exclusion filters to prevent Policy Denied...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@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
@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).