Back/forward cache use on phones by platform, Sept 2026 CrUX
| Platform | Back/forward served from bfcache | Back/forward share of page loads | Reload share | Origins |
|---|---|---|---|---|
| Wix | 74.5% | 7.3% | 3.1% | 732 |
| Squarespace | 73.8% | 10.0% | 4.8% | 361 |
| Shopify | 64.3% | 18.0% | 2.9% | 36,515 |
| WordPress (non-store) | 60.8% | 12.6% | 4.1% | 74,821 |
| Webflow | 60.4% | 8.1% | 3.9% | 2,068 |
| WooCommerce | 56.0% | 16.5% | 3.3% | 16,505 |
| Other store platforms | 22.7% | 14.0% | 2.9% | 17,429 |
| All matched origins | 43.5% | 11.4% | 6.1% | 610,762 |
Source: PageSpeed Matters, CrUX and HTTP Archive, Sept 2026. Other store platforms: Magento, BigCommerce, Salesforce Commerce Cloud, PrestaShop, OpenCart, Shopware, VTEX, SAP Commerce Cloud and Lightspeed.
Summary
Shoppers use the back button constantly: from a product page back to the category, from the cart back to the product. When a browser can restore the previous page from its back/forward cache (bfcache), that trip is instant. When it cannot, the page loads again from scratch.
We looked at how often that instant restore happens on phones, by platform. On Shopify stores, 64.3% of back and forward navigations are served from the bfcache, against 56.0% on WooCommerce and just 22.7% across nine other store platforms.
What we measured
We used Chrome UX Report (CrUX) navigation type data for phones from September 2026, matched to each site's platform in the HTTP Archive crawl. CrUX splits back and forward navigations into those restored from the bfcache and those that loaded normally. For each origin we took the bfcache share of all back and forward navigations, then averaged across origins, so every origin counts equally regardless of traffic.
The other store platforms group covers Magento, BigCommerce, Salesforce Commerce Cloud, PrestaShop, OpenCart, Shopware, VTEX, SAP Commerce Cloud and Lightspeed. WordPress figures exclude WooCommerce stores. Across all platforms, 610,762 origins matched.
Shopify and WooCommerce restore most back navigations instantly
On phones, 64.3% of back and forward navigations on Shopify stores are served from the bfcache (36,515 origins). WooCommerce comes in at 56.0% (16,505 origins). Across the nine other store platforms, the figure drops to 22.7% (17,429 origins), well below the 43.5% average across all matched origins.
A page is usually kept out of the bfcache because of something it does, not because of the platform name. Common blockers documented by Chrome include unload event handlers, a Cache-Control: no-store header on the HTML, and open connections when the shopper leaves. Platforms that get those defaults right likely give every store on them a head start.
64.3%
Share of back and forward navigations on Shopify stores that phones serve instantly from the back/forward cache.
Site builders do even better than Shopify
The highest rates come from hosted site builders. 74.5% of back and forward navigations hit the cache on Wix (732 origins) and 73.8% on Squarespace (361). Non-store WordPress sites reach 60.8% (74,821) and Webflow 60.4% (2,068).
All of these sit well above the 43.5% average across all 610,762 matched origins. On hosted builders the platform controls most of the page, which likely leaves fewer custom scripts in a position to block the cache.
Bigger stores get less out of the cache
On every store platform, the most popular stores do worse. On Shopify, 58.6% of back and forward navigations are restored from the cache on Top 100K origins (1,777) against 64.6% for the rest (34,738). On WooCommerce it is 49.6% against 56.2% (305 and 16,200 origins), and on other store platforms 17.4% against 23.3% (1,934 and 15,495).
Larger stores often run more apps, tags and custom code, and each extra script is another chance to add an unload handler or hold a connection open. The data shows the pattern, not the specific cause on any one site.
Shoppers hit the back button more on stores
Back-button speed matters more on stores than on most sites, because shoppers use it more. Back and forward navigations are 18.0% of page loads on Shopify, 16.5% on WooCommerce and 14.0% on other store platforms, against 11.4% across all origins. That fits the browsing pattern of moving between category and product pages.
Reloads go the other way. Just 2.9% of Shopify page loads are reloads, against 6.1% across all origins.
What this means for your store
If your store is not on Shopify or WooCommerce, the bfcache is worth checking early: on the other store platforms we measured, most back navigations are full reloads.
- Open Chrome DevTools, go to Application, then Back/forward cache, and run the test on your category and product pages. It lists the exact reasons a page was blocked.
- Remove unload handlers, or replace them with pagehide, in your own code and in the apps and tags you load.
- Avoid Cache-Control: no-store on pages that do not hold private data.
- Close open connections when the page is hidden.
Then watch the navigation types in CrUX or your real-user monitoring to confirm more back navigations are served from the cache.
Sources
- Chrome UX Report (CrUX) navigation types, phone, September 2026
- HTTP Archive crawl, September 2026, for site platforms
- Back/forward cache guide: https://web.dev/articles/bfcache
Frequently asked questions
What is the back/forward cache?
It is a browser feature that keeps a full copy of a page in memory when you leave it, so pressing back or forward restores it instantly instead of loading it again.
What percentage of back navigations use the bfcache on Shopify?
On phones, 64.3% of back and forward navigations on Shopify stores are served from the bfcache, against 56.0% on WooCommerce, 22.7% on nine other store platforms and 43.5% across all matched origins.
How often do shoppers use the back button?
Often. Back and forward navigations make up 18.0% of page loads on Shopify stores and 16.5% on WooCommerce, against 11.4% across all origins.
How do I check if my pages are eligible for the bfcache?
In Chrome DevTools, open Application, then Back/forward cache, and run the test on a page. It reports whether the page was restored from the cache and, if not, the reasons it was blocked.
Most bfcache blockers come from a handful of scripts and headers, so making the back button instant is often a small, contained fix. Need help with this? See our ecommerce CRO agency.

