Indonesia Singapore ไทย Pilipinas Việt Nam Malaysia မြန်မာ ລາວ
← Back to Blog

Dark Mode Toggles, WebGPU Lighting, and UX Debt

Defaulting to binary dark mode toggles silently erodes trust — tri-state controls that respect system preferences are the technically correct default.

A developer standing at a control panel with three switches, one of which is glowing, while a shadowed and lit version of the same interface floats on either side
Illustrated by Mikael Venne

Tri-state dark mode, WebGPU image relighting, and smarter hosting: three web signals reshaping UX and performance strategy in 2026.

Binary dark mode toggles ship on roughly 80% of sites that bother implementing one at all — and almost all of them are quietly getting it wrong. The fix is already in the CSS spec. Most teams just haven’t looked.

The Binary Dark Mode Toggle Is a UX Lie

Here’s the problem Bramus van Damme lays out plainly on bram.us: a two-state light/dark toggle actively overrides a user’s OS-level preference without any graceful way back. Toggle it once to test, close the tab, reopen — and your chosen system theme is gone, replaced by whatever state the site last remembered. For a Southeast Asian user switching between a dim indoor commute on the MRT and direct sunlight at an outdoor café, that kind of state amnesia is genuinely friction-generating.

The correct pattern is a tri-state control: Light, Dark, and System Default. The third state — often rendered as an “auto” or monitor icon — defers to prefers-color-scheme and stays in sync with the OS. Implementation is straightforward: store the user’s explicit choice in localStorage, apply a data-theme attribute to the <html> element, and treat the absence of a stored preference as a pass-through to the media query. The UX win is immediate. The performance implication is also real — correctly sequencing this logic before first paint eliminates the flash-of-incorrect-theme (FOIT) that tanks Cumulative Layout Shift scores on dark-mode-heavy designs.

For teams building multilingual interfaces across Thai, Bahasa, and Vietnamese — where typography already demands careful contrast ratios — getting the theme state right from the first render isn’t optional. It’s table stakes.


WebGPU and Real-Time Relighting: Performance Implications for Visual Commerce

Dominik Fojcik’s tutorial on Codrops demonstrates something that looks like a visual effect but is actually a performance architecture decision: using depth maps, Three.js Shading Language (TSL), and WebGPU to relight flat 2D images in real time. The result is a product image that responds dynamically to a virtual light source — casting self-shadows, revealing surface texture, and behaving like a 3D object without a 3D model.

For e-commerce teams on Lazada or Shopee building web storefronts, the implication is significant. High-quality 3D model pipelines are expensive and slow. Depth-map relighting gives you 80% of the perceived depth at a fraction of the asset production cost. A single hero product image becomes interactive with a few kilobytes of depth data and a WebGPU shader.

The catch — and it’s a real one — is browser support. WebGPU is available in Chrome and Edge, with Firefox behind a flag as of mid-2026. Safari support remains partial. For Southeast Asian audiences where Chrome dominates desktop but Safari holds meaningful iOS share, you need a graceful fallback: a WebGL-based Three.js renderer for non-WebGPU contexts, with the depth-map effect degrading to a static image on older devices. TSL is designed to compile down to both targets, which makes this more manageable than it sounds, but the fallback path needs explicit QA time. Don’t let it be an afterthought.

Core Web Vitals note: depth maps are typically 8-bit greyscale images. At around 50–100KB for a hero asset, they’re cheap. The shader compilation overhead is the real LCP risk — initialise your WebGPU context off the critical path and lazy-load the effect after the initial paint.

Hosting as a Hidden Performance Variable

Geoff Graham’s piece on CSS-Tricks about the WordPress.com Student Plan surfaces something that matters beyond the education use case: hosting infrastructure decisions made early in a project’s life tend to calcify. A student picking a shared WordPress host to get their project live is making the same category of mistake as a brand launching a campaign microsite on a server configured for a quarterly traffic spike from three years ago.

Hosting is a performance variable, not an IT line item. Time to First Byte (TTFB) — one of the three Core Web Vitals inputs — is almost entirely determined by server response time and CDN configuration. A mid-tier Shopify store migrating from shared hosting to a properly edge-cached infrastructure has seen TTFB improvements from 800ms to under 100ms, with measurable lift in conversion rate. The research is consistent: Google’s own data links a TTFB above 600ms to significantly higher bounce rates on mobile.

For Southeast Asian brands, this is compounded by geography. A server hosted in Singapore serves Thai or Filipino users with meaningfully higher latency than one distributed across regional edge nodes. If your CDN configuration isn’t Southeast Asia-aware — with PoPs in Bangkok, Manila, and Jakarta — you’re leaving performance on the table regardless of how clean your code is.

Key takeaways:

  • Implement tri-state dark mode controls (Light / Dark / System) from day one — binary toggles create silent UX debt and measurable CLS issues on first paint.
  • Treat WebGPU relighting as a progressive enhancement strategy for visual commerce: build the WebGL fallback first, then layer in the depth-map effect for supported browsers.
  • Audit your TTFB before any conversion rate optimisation work — Southeast Asian users on sub-optimal CDN configurations are effectively being served a slower product than your analytics show.

The through-line across all three of these signals is the same: the decisions that look like implementation details — toggle logic, shader fallbacks, server geography — are actually the decisions that determine whether your product feels fast and trustworthy or subtly broken. Which raises the question worth sitting with: how many of your current user experience problems are actually infrastructure and defaults problems in disguise?


At grzzly, we work with digital and e-commerce teams across Southeast Asia on exactly this layer — the intersection of web performance, rendering strategy, and UX decisions that compound into conversion outcomes. If any of these signals are live debates on your roadmap right now, Let’s talk.

Diesel Grizzly

Written by

Diesel Grizzly

Core Web Vitals, rendering strategies, PWAs, and the relentless pursuit of sub-second load times. Believes that performance is the most underrated conversion optimisation lever in existence.

Enjoyed this?
Let's talk.

Start a conversation