What we repeatedly see in ecommerce performance reviews is a team optimising the first page load while ignoring one of the most common shopping behaviours: opening a product, deciding it is not right, and returning to the list. When that return rebuilds the page, loses scroll position, or resets filters, product discovery becomes slower even though the homepage Lighthouse score looks healthy.
The browser back-forward cache, usually called bfcache, can restore a complete page snapshot almost instantly. For commerce teams, however, eligibility is only half the problem. The restored collection must preserve discovery context while price, inventory, authentication, and cart signals remain correct.
Table of contents
- Keyword decision and search intent
- Why return navigation is commercial
- Measure eligibility and real restores
- Protect shopping state
- Build a template scorecard
- Remove common blockers
- Test the complete journey
- A 30-day implementation plan
- EcomToolkit point of view
Keyword decision and search intent
- Primary keyword: ecommerce bfcache performance
- Secondary keywords: back-forward cache ecommerce, product-list back navigation, ecommerce navigation speed, bfcache cart state
- Search intent: technical informational with optimisation intent
- Funnel stage: mid-funnel
- Page type: implementation and measurement guide
- Why this angle can win: most ecommerce speed content measures cold page loads, while shoppers repeatedly move between lists and product pages and need both instant restoration and commercially correct state.
Why return navigation is commercial
Google’s updated bfcache guidance says back or forward actions represent about one in ten desktop navigations and one in five mobile navigations in Chrome usage data. Those figures describe the web, not a universal ecommerce benchmark, but they make the behaviour too important to omit from a performance programme.
A product-discovery loop often looks like this:
- land on a collection, category, search result, or campaign page;
- filter, sort, scroll, or paginate;
- open a product detail page;
- compare price, availability, media, reviews, and delivery;
- return to the previous results;
- repeat until confidence is sufficient.
If step five reloads, the customer can lose the exact product position and comparison context. On a mobile network, the cost includes data transfer, parsing, script execution, API requests, image decoding, and the cognitive work of finding the previous place.
bfcache differs from the HTTP cache. The HTTP cache stores responses; bfcache can preserve a snapshot of the page and its JavaScript heap. That is why a restore can be faster than a carefully cached reload. It is also why restored state needs deliberate freshness and privacy controls.
Measure eligibility and real restores
Do not publish a single “bfcache enabled” checkbox. Measure the journey in layers.
| Metric | Definition | Decision it supports |
|---|---|---|
| Back-forward navigation share | eligible navigation events / all navigations | commercial exposure |
| Restore rate | bfcache restores / back-forward navigations | realised browser benefit |
| Not-restored reason share | failures by reason / failed restores | engineering priority |
| Restore-to-visible time | pageshow to usable visual state | perceived return speed |
| State recovery rate | restores with correct filter, scroll, and selection / restores | discovery continuity |
| Freshness repair rate | restores requiring price, stock, or cart refresh / restores | data-control design |
| Post-restore error rate | errors after restore / restores | lifecycle safety |
| Restore conversion | purchase progress after restore / restored sessions | commercial context |
The restore rate cannot be expected to reach 100%. Browser policies, memory pressure, document state, sensitive pages, and user behaviour can make a page ineligible or evict it. Use the rate to find preventable problems, not to punish teams for browser decisions they do not control.
Instrument the pageshow event and record whether event.persisted is true. Where supported, the NotRestoredReasons API can provide diagnostic evidence. Keep browser, device, template, market, release, and authentication state so one global average does not conceal a product-template regression.
Protect shopping state
The performance win is useful only when the snapshot remains trustworthy.
| State | Preserve immediately | Revalidate after restore | Unsafe shortcut |
|---|---|---|---|
| Filters and sort | selected controls and result context | availability-dependent result counts | rebuilding defaults |
| Scroll position | exact list position | lazy-loaded items if required | jumping to page top |
| Product comparison | selected items | current price and stock | silently dropping choices |
| Cart badge | last visible value | cart session and item count | showing a stale count indefinitely |
| Wishlist | optimistic selection | authenticated server state | exposing another session |
| Price | visible value | market, customer, promotion, and currency rules | assuming snapshot price is final |
| Inventory | visible status briefly | current sellability | accepting stale availability at cart |
| Authentication | no private assumption | session validity | retaining signed-out account data |
Google recommends using pageshow to update stale or sensitive information when a page is restored. In commerce, the update should be selective. Do not erase the speed benefit by rebuilding the entire application. Revalidate the small set of states whose correctness can change the purchase: session identity, cart, price, inventory, promotion eligibility, and delivery promise.
Render an immediate preserved interface, then update changed values without stealing focus or moving the shopper. If a selected product becomes unavailable, explain the change. If the cart changed in another tab, reconcile it rather than replacing the current view without warning.
Build a template scorecard
Prioritise templates by how often customers return to them and how expensive a reload is.
| Template | Return-navigation importance | Main correctness risk | First test |
|---|---|---|---|
| Collection/category | very high | filters, sort, stock, scroll | PLP → PDP → back |
| Search results | very high | query, ranking, zero-result state | search → PDP → back |
| Product detail | medium | selected variant and price | PDP → guide → back |
| Cart | high but sensitive | quantity, promotions, identity | cart → shipping info → back |
| Account | sensitive | private customer data | sign out → back |
| Checkout | platform-dependent | payment and order state | avoid assumptions; follow platform rules |
| Editorial guide | medium | scroll and linked product state | article → product → back |
Combine restore metrics with the customer journey latency framework. A near-instant return can reduce discovery friction even if it never appears in a conventional cold-load dashboard.
Remove common blockers
The unload event is a common avoidable blocker. Google’s guidance recommends pagehide where lifecycle work is required. Audit third-party tags as well as first-party code because an embedded frame can affect eligibility.
Review:
unloadhandlers in theme, consent, review, chat, and analytics scripts;- use of
Cache-Control: no-storeon pages that do not contain sensitive data; - open connections and browser APIs reported as not-restored reasons;
- iframe permissions and sandboxing;
- scripts that assume they initialise only once;
- timers, observers, and event listeners that duplicate after restore;
- analytics that count a restore as an ordinary full reload;
- inventory or cart services that never revalidate resumed state.
Do not remove security controls to gain a restore. Account and checkout pages require stronger privacy review than public catalog pages. no-store can be appropriate for truly sensitive documents, and browser behaviour continues to evolve. Test the actual target browsers rather than copying one header policy across every route.
Test the complete journey
Chrome DevTools includes a Back-forward Cache panel that can navigate away and back, report whether restoration occurred, and surface actionable blockers. Use it as a diagnostic tool, then add repeatable journey tests.
Test at least:
- collection with filters and deep scroll;
- search results with autocomplete-origin query;
- PDP with non-default variant selected;
- cart changed in another tab;
- price or promotion changed between navigation and restore;
- item going out of stock;
- customer signing out before returning;
- consent state changing;
- embedded review, video, and support widgets;
- low-memory mobile conditions where eviction is more likely.
Validate interface state, network requests, analytics events, focus, scroll, announcements for assistive technology, and console errors. A fast restore that duplicates an add-to-cart listener is a regression, not a success.
Set release guardrails by template. A starting policy might require no new actionable not-restored reason on collection and search pages, no duplicated commerce events, and a passing stale-state test suite. These are internal controls, not published industry standards.
A 30-day implementation plan
Week 1: baseline
- Measure back-forward navigation share by template.
- Record restore rate and top not-restored reasons.
- Map preserved and freshness-sensitive state.
- Identify high-exposure discovery loops.
Week 2: repair
- Replace avoidable
unloadhandlers. - Review caching headers and third-party frames.
- Add safe
pageshowlifecycle handling. - Prevent duplicated listeners and analytics events.
Week 3: validate
- Test filter, scroll, cart, price, inventory, and sign-out state.
- Run on Chrome, Safari, and Firefox target versions.
- Segment results by mobile and desktop.
- Add regression journeys to release checks.
Week 4: govern
- Publish the template scorecard.
- Assign owners to remaining blockers.
- Connect restore cohorts to product-discovery completion.
- Recheck after tag, app, and theme changes.
EcomToolkit point of view
Ecommerce speed is not only how quickly a customer arrives; it is how little work the site makes them repeat. bfcache turns the back button into a high-value performance surface, especially for mobile product discovery.
EcomToolkit recommends starting with collection and search return journeys, preserving human context, and revalidating only commercial truth. Pair this work with the mobile ecommerce performance framework and contact EcomToolkit if your speed programme still measures pages instead of shopping loops.
