View Transitions & bfcache: The Performance Wins You're Leaving on the Table

Roughly 20% of all navigations on Chrome are served from the back/forward cache — meaning the browser resurrects a fully frozen page snapshot instead of re-fetching anything. That’s a near-instant load, for free. Meanwhile, most dev teams are still fighting over image compression settings wondering why their INP scores won’t budge.

Two browser capabilities surfacing in the wild right now — the bfcache and the View Transitions API — deserve more attention than they’re getting in sprint planning. Used together, they represent the kind of perceived performance improvement that actually registers with users, not just Lighthouse auditors.

What the bfcache Actually Is (and Why You’re Probably Breaking It)

The back/forward cache stores a complete in-memory snapshot of a page when a user navigates away. When they hit the back button, the browser restores it instantly — no network requests, no re-parsing, no re-rendering. Stefan Judis’s Web Weekly flagged it recently as one of the most impactful and least understood browser features in production today.

The catch: a surprisingly long list of things will disqualify your page from bfcache eligibility. Unload event listeners are the most common offender — they’re still present in a huge number of codebases, often dropped in by third-party scripts (analytics, chat widgets, tag managers). Cache-Control: no-store headers will also exclude a page. So will certain uses of IndexedDB connections left open on navigation.

For Southeast Asian teams running heavy martech stacks — think Google Tag Manager loading five or six vendor scripts — the odds that something in that chain is poisoning your bfcache eligibility are higher than you’d expect. Chrome DevTools has a dedicated bfcache tab under Application that will show you exactly which reason codes are blocking restoration. Run it. Fix the unload listeners first.

View Transitions: Not Just Eye Candy

CSS-Tricks published a genuinely useful collection of seven View Transitions recipes this week, covering patterns from simple cross-fade page swaps to more sophisticated shared-element transitions. The practical point isn’t aesthetic — it’s that View Transitions eliminate the jarring visual discontinuity between navigations, which directly reduces the perception of slowness even when raw load times haven’t changed.

The mechanism is straightforward: document.startViewTransition() captures a screenshot of the current state, triggers the DOM update, then animates between the two states using CSS. For multi-page apps, the CSS-level @view-transition rule landed in Chrome 126 and is now broadly available, meaning you don’t need a SPA architecture to get the benefit.

Practically, the recipes worth reaching for first are the shared-element hero transitions (useful for product listing → product detail flows on Shopee-style catalogue pages) and the slide-in navigation pattern, which maps naturally to the bottom-nav conventions Southeast Asian mobile users expect from apps like Grab and LINE. The implementation overhead is low — a few dozen lines of CSS — but the impact on perceived responsiveness is disproportionate.

---

sizes=“auto” and Lazy-Loaded Images: The Quiet Win

Also landing in browsers right now: sizes="auto" for lazy-loaded images. Previously, developers had to manually specify the sizes attribute to help the browser select the right responsive image variant — a calculation that was often wrong, defaulted to 100vw, and caused browsers to download images far larger than necessary.

sizes="auto" delegates that calculation to the browser, which uses the element’s rendered layout size instead of a developer’s best guess. The practical result is more accurate resource selection, smaller payloads on mobile, and better LCP scores — particularly for below-the-fold images that get promoted to above-the-fold on certain viewport sizes.

For teams managing large product catalogues with dynamic grid layouts — where the rendered image size genuinely varies by breakpoint, user-selected grid density, or A/B test variant — this removes a whole class of manual maintenance. The requirement is that the image must have loading="lazy" set; it doesn’t apply to eagerly loaded images, which still require explicit sizes values.

Putting It Together: A Performance Sprint That Actually Ships

These three capabilities aren’t research projects — they’re production-ready and available in current Chrome, Edge, and (for View Transitions) increasingly Safari. A focused two-week sprint could realistically ship all three:

Week one: Audit bfcache eligibility across your five highest-traffic landing pages using Chrome DevTools. Remove or replace unload listeners. Audit your GTM container for vendor tags that register unload handlers — most can be replaced with pagehide or visibilitychange equivalents without losing functionality.

Week two: Implement sizes="auto" across all lazy-loaded product and editorial images. Pick one high-traffic navigation flow and implement a View Transition on it — the slide or cross-fade recipe from CSS-Tricks is a 30-minute implementation. Measure perceived load improvement using Web Vitals field data, not just lab scores.

The uncomfortable truth is that most performance conversations in Southeast Asia still centre on hosting decisions and CDN selection. Those matter, but they’re infrastructure plays that take quarters to move. bfcache fixes and View Transitions ship in days and affect a metric that users actually feel.

---

Key Takeaways

• Audit your five highest-traffic pages for bfcache eligibility in Chrome DevTools today — unload event listeners from third-party scripts are the most common silent killer.
• Add sizes="auto" to all lazy-loaded images immediately; it requires one attribute change and reduces mobile payload without any design work.
• View Transitions on your primary navigation flow reduce perceived latency and map naturally to the app-like UX expectations of Southeast Asian mobile users.

As browsers keep absorbing capabilities that used to require JavaScript frameworks — smooth transitions, smarter resource selection, instant back-navigation — the question for engineering teams isn’t whether to adopt them. It’s whether your current sprint cadence gives you the space to notice they’ve arrived.

---

At grzzly, we help digital teams across Southeast Asia close the gap between what browsers can do and what their products actually ship. If your Core Web Vitals are stuck and you suspect your martech stack is part of the problem, we’d like to dig into it with you. Let’s talk