@Gerry I know Google's page speed tester https://pagespeed.web.dev isn't perfect, and I know FF and other browsers aren't either :-)
Currenty the speed test highlights that p7_STT and p7_STE uses unload listeners, which it says can slow down page speed:
"The unload event does not fire reliably and listening for it can prevent browser optimizations like the Back-Forward Cache. Use pagehide or visibilitychange events instead"
They link to this page https://web.dev/bfcache/ which suggests avoiding the unload event:
"Instead of using the unload event, use the pagehide event. The pagehide event fires in all cases where the unload event currently fires, and it also fires when a page is put in the bfcache."
They even summarize this way :
"Never add an unload event listener! Use the pagehide event instead. Adding an unload event listener will make your site slower in Firefox, and the code won't even run most of the time in Chrome and Safari."
Any thoughts?
I like the UI benefits vs known costs.... and like most PageSpeed complaints, we don't know what effect following their advice will have (if any). I thought I'd ask if it's on the p7 radar, as Page Speed tests are used critically in tech discussions that also point fingers at anything that produces a comment like this.
Thanks.
PS: after some research, I can report that this "warning" does not impact an otherwise perfect PageSpeed score (100%/100%) so "fixing it" would not get priority even on the "visible performance measures according to Google" side of webmastering.
I can also report (for those who care) that estimating vertical size of flex-grid-generated content and using it as min-width on things like fgm-section (p7_FGM) and qgm-col (p7_QGM) "fixes" otherwise too-high CLS scores.
Page with p7_HMY, p7_FGM, p7_QGM, p7_STT and many STE links now scores 100% (mobile) and 100% (desktop).
