What Is bfcache and How Do I Keep My Webflow Site Eligible for It?

Why Does the Back Button Feel Instant on Some Sites and Slow on Mine?

A client came to me last quarter with a complaint I had heard before but never taken seriously enough. Her Webflow site felt fast on the first load, but every time a visitor hit the browser back button, the page seemed to rebuild itself from scratch. On a three step funnel, that lag was costing her. People who tapped back to compare a plan lost a second or more each time, and some of them just left.

I assumed the fix would be a heavy performance project. It was not. The real issue was that her pages were not eligible for something browsers have offered for years: the back and forward cache, usually written as bfcache. One old script was quietly switching it off for the whole site. Once I removed the cause, the back button became instant, with no redesign and no new tooling.

Most site owners never think about bfcache because it works silently when it works at all. In this piece I will explain what bfcache is, why it matters for a Webflow site in 2026, what disqualifies a page, and how to test and fix your own pages this week.

What Is bfcache?

bfcache, short for back and forward cache, is a browser feature that stores a complete snapshot of a page in memory when you navigate away from it. When you press back or forward, the browser restores that snapshot instantly instead of reloading the page. Google's web.dev documentation describes the result as near instant back and forward navigation.

The key word is snapshot. With a normal load, the browser fetches the HTML, runs the JavaScript, and paints the page again. With bfcache, the browser pauses the page rather than destroying it, then resumes it exactly where it was, scroll position and all. Chrome, Firefox, and Safari all support bfcache, so this is not an experimental edge feature. It is baseline browser behavior that your site either qualifies for or accidentally blocks.

I think of bfcache as free performance. You do not build it. You simply avoid the handful of patterns that disqualify a page, and the browser does the rest. The trouble is that a single common mistake can switch it off for an entire site, which is exactly what had happened to my client.

Why Does bfcache Matter for a Webflow Site in 2026?

It matters because back and forward navigation is everywhere, especially on mobile, and because instant restoration improves the experience your visitors actually feel. Buyers compare. They tap into your pricing page, hit back, read a feature, hit back again. Every one of those moves can be instant or sluggish, and bfcache decides which.

There is a measurement angle too. Google's Core Web Vitals set the bar for a good experience at a Largest Contentful Paint under 2.5 seconds, an Interaction to Next Paint under 200 milliseconds, and a Cumulative Layout Shift under 0.1, all measured at the 75th percentile. A page restored from bfcache effectively skips the slow parts of a fresh load, which helps the experience on those repeat navigations. For a Webflow marketing site where people bounce between pages while deciding, that smoothness is not a luxury. It is part of how the site feels trustworthy.

It also pairs well with other speed wins. I have written about using the Speculation Rules API for instant Webflow navigation, and bfcache is the natural companion: speculation rules speed up forward navigation, bfcache makes going back just as quick.

What Stops a Page From Being Eligible for bfcache?

The most common blocker is an old unload event listener. If any script on your page listens for the unload event, desktop Chrome and Firefox will refuse to put that page in bfcache. The modern replacement is the pagehide event, which does the same job without breaking eligibility. Removing a stray unload listener is often the entire fix.

A second blocker used to be the Cache-Control header set to no-store, which many login and dashboard pages send. The good news for 2026 is that Chrome has been rolling out bfcache support even for no-store pages when it is safe, and Chrome for Developers reported that change reaching close to 100 percent of eligible page loads through March and April 2025. The browser still evicts a cached page if cookies or authentication state change, so sensitive pages stay safe. For a typical Webflow marketing site, which does not send no-store on its public pages, this was rarely the problem anyway. Other blockers include open connections the browser cannot pause and certain embedded content, but the unload listener is the one I find most often.

Does Webflow Support bfcache Out of the Box?

Yes. A standard Webflow site, with its native interactions and clean published markup, is eligible for bfcache by default. Webflow does not ship an unload listener or no-store headers on your public pages, so out of the box you are usually fine. The problems almost always come from things you or a past developer added.

In my experience the culprit is third party custom code in the site or page head. An old analytics snippet, a chat widget, or a hand written script that hooks the unload event will quietly disqualify every page it loads on. My client's blocker was a legacy tracking script a previous freelancer had pasted in years earlier. This is why I treat custom code as a performance liability to audit, not a set and forget addition, a theme I cover in my guide on fixing third party script performance in Webflow.

How Do You Test If Your Webflow Pages Are Eligible?

The fastest way is the bfcache tester built into Chrome DevTools. Open your published page in Chrome, open DevTools, go to the Application panel, and choose Back/forward cache. Click the test button and Chrome will navigate away and back, then tell you whether the page was restored from bfcache or list the exact reasons it was not.

That report is gold, because it names the blocker instead of making you guess. If it says an unload handler is present, you know to hunt down the script using it. I run this test on the homepage, a key landing page, and any page with custom code, since a blocker on one template does not mean every template is affected. It takes a couple of minutes per page and turns a vague feeling of slowness into a precise, fixable list.

But Does This Even Matter If My Core Web Vitals Are Already Good?

It still matters, because Core Web Vitals mostly measure the first load, while bfcache improves every back and forward move after that. You can pass all three thresholds on a fresh visit and still give people a slow back button. The two things measure different moments in the same journey.

I see this confusion a lot. A founder shows me a green Core Web Vitals report and assumes the site is as fast as it can be. Then I tap back on their pricing flow and watch it reload. Good vitals and bfcache eligibility are both worth having, and they do not substitute for each other. If you want the deeper picture on the interactivity metric specifically, my piece on Core Web Vitals and INP optimization goes further. bfcache is the piece that good vitals reports tend to hide.

How Do You Keep Your Webflow Site bfcache Friendly?

Keep it friendly by auditing custom code and replacing old patterns. Search your site and page custom code for the unload event and swap it for pagehide. Remove scripts you no longer use, since the cleanest way to avoid a blocker is to not load the thing that causes it. Then retest in Chrome DevTools to confirm the page is restored from cache.

I also keep a short rule for myself when adding anything to a Webflow site. Before I paste a third party snippet, I ask whether it hooks the unload event or holds an open connection the browser cannot pause. If it does, I look for a modern alternative or load it more carefully. This habit means new code does not silently undo the speed I worked to get. bfcache is easy to keep once you stop treating custom code as harmless.

How to Check Your bfcache This Week

Here is the plan for the week. First, open your homepage and one key landing page in Chrome and run the Back/forward cache test in the Application panel of DevTools. Second, if the report names an unload handler, find the script responsible and replace unload with pagehide, or remove the script if it is dead weight. Third, retest until the report says the page was restored from bfcache.

That is usually the whole job. No redesign, no new platform, no heavy build. Just a quick test and a small fix that makes your back button feel instant for every visitor who is comparing you against someone else.

If you want a second pair of eyes on what your custom code is doing to your Webflow site speed, I am happy to run the audit with you. Let's chat.

For the forward-navigation half of the same speed story, my newer note on Speculation Rules for Webflow instant navigation covers the prerender pattern I now ship on every site.