 I love browsing the web, but sometimes the experience can be frustratingly slow. I wish the browser could help with that. The BF Cash should help with that. The what? The BF Cash, or Back Forward Cash. When you navigate away from the page, the browser keeps the old page around in the background for a short period. So if you need to go back, it's available instantly. Oh nice, so how does that work? By restoring the fully rendered page from memory, you see if having to re-render the page from scratch. Or, worse still, having to go back to the network to re-download some resources that aren't cached. Here's a video of the BF Cash in action to help you understand the speed up it can bring to navigations. And you'd be surprised how often you do this when navigating the web. 10 to 20% of navigations are Back Forward Navigation for many websites. Would you like to make up to 20% of your page visits load faster? Instantly even? Definitely. So does the BF Cash get used automatically? Almost. The BF Cash is used by default without websites needing to do anything to enable it. However, websites can use certain features or APIs that prevent it from being used. And that's where DevTools can help. Oh, great. We love hearing DevTools tips. Tell us. When Chrome introduced the BF Cash, we also gave you a number of tools to help you understand it. First up, we added a test to DevTools in the application panel. Click on that inviting blue button and you'll see a brief flash as Chrome navigates away to a terms of service page and then back. It will check if the page was restored from the BF Cash or had to be loaded again from scratch. Here you can see it was restored. Great. Your users are getting an instant experience as they navigate back and forward around your site. However, if we try this other site, you can see there's a problem. And the DevTools test helpfully lists the reasons why. In this case, the problem is that the page uses an unload handler. That means the page executed some code when the page is being unloaded. And so Chrome decides it's best not to restore the page from the BF Cash afterwards, as the page might not be expecting to be restored. There are a number of other APIs like this that prevent the browser from using the BF Cash. Nice. That is a great testing tool. Yes, it is. And it only takes a second to run. Try it on your website now and see if you have any reasons preventing you from using this great browser optimization. Hmm. It seems so simple. Are there anything else we should know? Well, extensions can also add unload handlers to a page or other APIs that can block BF Cash usage. So best test this in a guest profile or using incognito mode. Good to know. So is that it? Well, we're just getting started. There are more tools by the Chrome team as added. Lighthouse also includes this test. When you run a Lighthouse audit from DevTools, you may also recently have noticed that flash to the terms page. That's because Lighthouse also does the same test and warns you if it fails. And as well as these lab tools, we have a not restored Reasons API, which allows you to collect all the reasons for all your pages in the field from actual users. That's fantastic. Thanks, Barry. So tell me, what are the common reasons that prevent the BF Cash from being used? The two main reasons are pages using Cash Control No Store or unload handlers. The Chrome team are looking at both to see if they really should prevent BF Cash usage in future. But in the meantime, sites can fix this themselves. Setting No Store in your Cash Control header is a strong directive to the browser not to store it. This should be used for pages that contain personal and private information. For pages that you just want to be reasonably fresh, use Cash Control No Cash, or even better, a short cash time, both of which still allows the BF Cash to be used. Unload handlers are the other most common reason preventing BF Cash usage. Unload handlers have a lot of other problems as well, especially on mobile. So Chrome is looking to deprecate unload handlers and allow the BF Cash to be used in these cases. We already do this on mobile, as do all other browsers. And we're looking to do the same on desktop in the future. For sites that don't use unload handlers, they can enforce this with their permission policy, which is an HTTP response header sent with a document response. If you try and add an unload handle to this site, even in the console, the page won't let you. This is a good way of locking in the fact that you don't use unload handlers and also prevents extensions from adding them and thus slowing down your website. A quick tip for this one, you can overwrite HTTP response headers to test this out. Let's add a permission policy header to prevent accidental use of unload handlers on our site. Now, when we try to add an unload handler in the console, we can't. That's really neat. Permissions policy is a great way of preventing unload handlers creeping back onto your site, or from extensions adding them and slowing your website down. Oh wow, what a great review of BFcache and how you can use DevTools to debug them. Thank you, Barry. No problems. You're welcome. And I hope that helps. And please comment below if you have any questions on this. Alright, that's all. Go to this link to learn more. See you for the next DevTools Tips. Ciao!