Does bfcache influence Onload?

[Brendan Murray]

Hello,

We started passing Lighthouse audits for problematic unload listeners that interfere with bfcache on September 22nd. I was also able to see our site passing the chrome devtools "Back/forward cache" test as recently as October 5th, although we're actually failing it again at the time of this writing (a third party vendor which removed their unload listener for us seems to have put it back in, hopefully by accident). 

I have been working with stakeholders to set expectations that we're going to see metrics like page load speed artificially decline as mentioned here: https://web.dev/articles/bfcache#performance_measurement

I was hoping to offset this by showing an improvement in Onload, as that same page says:

> Tools like the Chrome User Experience Report, that collect and report on the Core Web Vitals metrics treat bfcache restores as separate page visits in their dataset.

We did see our page load speed grow in Google Analytics as expected, but our Onload metric in CrUX seems to have gotten worse as well. I'm trying to parse at the moment if this decrease in Onload is an expected result of enabling bfcache.

Our Mobile Onload only slightly declined, and the biggest hit seems to be from Desktop Onload.

If anyone who has enabled bfcache before has seen anything like this I'm all ears, we collect lab metrics and they seem to suggest we haven't had any significant performance regressions so I'm not sure where to look next.

I would also love any feedback about what user centric performance metrics are best to champion in a bfcache enabled world, as historically page load speed has been seen as an authoritative catch-all metric for us. I have been trying to treat Onload as a good proxy for it, this may be misguided though.

I'll attach some screenshots of our CrUX report, thanks for reading

-Brendan

[Barry Pollard]

Hi Brendan,

Did you know you can add a Permissions Policy to your website to block unload handlers to prevent third-parties impacting your bfcache usage by adding unload handlers? Sending this HTTP Header for your pages will do that:

Permissions-Policy: unload=()

Now on your main question, onload is not a good metric for this as that does not include bfcache navigations.

When the bfcache is used it isn't actually a real navigation - it's actually a restore of a previous page from an in-memory saved version of the page. Therefore, the web performance metrics often don't fire (and in some cases don't make sense!) for bfcache page views.

However, CrUX takes the view that this is a technical issue and to the user it IS a navigation. This however requires us to decide on what metrics to report.

For FCP and LCP we measure the restore time.

For CLS, FID, and INP we reset these and measure any future CLS, FID, and INP.

So for the Core Web Vitals metrics we handle these in CrUX as per the piece you quoted.

For other metrics we haven't defined how these should be measured for bfcache restores. This includes the older metrics like TTFB and onload. There is an argument that they should be reported as 0 (that's what the web-vitals.js library does for TTFB btw) but this is not something CrUX currently does.

In fact with more bfcache restores, that means you are not getting actual page loads which for a back or forward navigation would likely be very fast ones as all the resources are likely in the cache. So metrics like onload may well regress because they are losing some of their faster loads to the bfcache loads (which are no included in onload measurements). Sp what you're seeing is not unexpected.

So your best bet to measure bfcache impact is to look at LCP times. Ideally using RUM so you can measure how many bfcache page restores you get and also the different LCP times for those compared to other page restores.

Thanks,

Barry

[Brendan Murray]

Thanks Barry!

I will look into that permissions policy--I was unaware we had that option.

We're currently piloting a RUM solution on a subset of our pages and I think we'll find the budget to expand it soon. I've also used the CrUX History API a bit; really looking forward to the granularity that in house RUM collection offers though.

I'm going to add virtual pageview events for bfcache loads and try to get a sense of how much our users are restoring pages with it on our site.

I'll keep LCP in mind and see about expanding our RUM coverage ahead of enabling bfcache again, whether that is with our third party's explicit support or leveraging the permissions policy.

Thanks for your response, I've found the contributions from you and your colleagues to web.dev enormously helpful to us.

Best,
Brendan