View Transitions, bfcache, and the Web Features Worth Shipping Now

The browser platform quietly shipped a handful of capabilities this month that, taken together, represent a meaningful shift in what teams can build without a native app budget. Most dev teams will ignore them for six months. That’s the gap worth closing.

The View Transitions API Is Ready for Production — Stop Waiting

CSS-Tricks contributor Sunkanmi Fafowora recently published seven ready-to-use View Transitions recipes that move the conversation from “cool demo” to “drop this in on Monday.” The patterns cover the most common navigation moments: page-to-page fades, element morphs, list-to-detail expansions — exactly the transitions that make Grab and Shopee’s native apps feel snappier than their web counterparts.

The strategic case is straightforward. Perceived performance is real performance. A 300ms crossfade on a product-to-cart navigation doesn’t reduce server response time, but it measurably reduces the cognitive jolt of a hard page reload — and reduced friction at that moment has a direct line to conversion. Fafowora’s recipes use the startViewTransition() API with view-transition-name assignments, which means they layer on top of existing routing logic rather than requiring an architectural rewrite. For teams running Next.js or Nuxt on mid-market e-commerce properties across Southeast Asia, this is a progressive enhancement you can ship in a sprint, not a quarter.

One implementation note: multi-language interfaces — a daily reality for any brand operating across Thai, Bahasa, and Vietnamese simultaneously — need transition timing calibrated for text reflow. Morphing a short English label into a longer Thai equivalent without accounting for layout shift will negate the smoothness entirely.

bfcache Eligibility Is a Free Performance Win Most Sites Are Blocking

Back-forward cache (bfcache) is one of the most underutilised performance mechanisms in the browser. When it works, navigating back to a previous page is instantaneous — the browser restores a frozen snapshot rather than re-executing the entire page lifecycle. Stefan Judis’s Web Weekly flagged that many teams still aren’t systematically auditing why their pages are bfcache-ineligible, leaving this free speed on the table.

The blockers are well-documented but routinely overlooked: Cache-Control: no-store headers, unload event listeners, open IndexedDB connections, and SharedWorkers all disqualify a page from bfcache in Chromium. On mobile networks — which still account for the dominant share of sessions across Southeast Asian markets — the difference between a bfcache restore and a full reload can be two to four seconds of wall-clock time. That’s not a rounding error on bounce rate.

The audit path is concrete: open Chrome DevTools, navigate away and back, check the Application panel under Back/Forward Cache, and read the “Not Restored Reasons” list. Fix the top blocker. Repeat. Most sites can resolve the most common disqualifier — residual unload listeners from legacy analytics tags — in under a day.

---

sizes="auto" and Native Video Lazy Loading Close Two Long-Standing Gaps

Two smaller browser additions flagged in Web Weekly this week deserve attention from anyone responsible for image-heavy or video-heavy experiences — which is most e-commerce and lifestyle brands in this region.

sizes="auto" for lazy-loaded images lets the browser calculate the correct display size without requiring developers to manually author sizes attribute strings — a task that’s historically been error-prone enough that many teams skip it entirely, defaulting to images that are systematically oversized for their actual render context. With sizes="auto", the browser infers the rendered width at load time and selects the appropriate srcset candidate. For product listing pages on Lazada-style grid layouts — where image display size varies significantly between mobile breakpoints — this closes a gap that’s been causing unnecessary payload weight for years.

Native lazy loading for video via the loading="lazy" attribute on <video> elements follows the same mental model teams already use for images, removing the need for Intersection Observer boilerplate to defer off-screen video loads. On pages with multiple embedded videos — common in fashion and beauty verticals — this alone can meaningfully reduce initial page weight on first load.

Both features are progressive enhancements. Browsers that don’t support them fall back gracefully. There’s no reason to gate these behind a major release cycle.

The Craft Argument: Performance and Ambition Aren’t Opposites

Lusion’s recent Codrops feature — a studio profile documenting how one self-taught developer built a practice around ambitious, experimental digital work — makes a point that’s easy to misread as purely aesthetic. It isn’t. The underlying argument is that technical craft and performance discipline aren’t in tension; the most sophisticated interactive experiences hold together precisely because the foundational performance work was done first.

This matters for how Southeast Asian digital teams frame investment decisions internally. The instinct is often to treat performance optimisation and creative execution as sequential — first make it fast, then make it interesting. The better frame is that rendering strategy is the creative constraint. Deciding upfront whether a rich transition will use CSS View Transitions, a canvas-based animation, or a WebGL layer determines both the visual ceiling and the performance floor. Teams that conflate “ambitious” with “slow” are usually the ones who skipped that decision and paid for it at launch.

For brands operating in markets where mid-range Android devices running on 4G are the median user context — most of Southeast Asia, most of the time — that constraint is even more clarifying. Ambition has to be earned through efficiency, not despite it.

---

Key Takeaways

• Audit your pages for bfcache eligibility in Chrome DevTools this week — most disqualifiers are fixable within a single sprint and the speed recovery on mobile is immediate.
• Implement View Transitions on your highest-traffic navigation moments using ready-made recipes rather than building from scratch; the conversion impact of perceived smoothness is real and measurable.
• Adopt sizes="auto" for lazy-loaded images and native video lazy loading as default standards in your component library — both are safe progressive enhancements with no downside risk.

The browser platform keeps shipping capabilities that close the gap between web and native app experience — often faster than product teams notice, let alone ship. The question worth sitting with: is your team’s release cadence oriented around what users can already benefit from today, or what your current sprint backlog decided six weeks ago was the priority?

---

At grzzly, we work with digital teams across Southeast Asia to translate exactly these kinds of platform shifts into shipped improvements — auditing performance baselines, building component systems that incorporate new browser capabilities, and making the case internally when the numbers justify moving fast. If your web experience is leaving speed (and conversion) on the table, Let’s talk.