Tactile UX and 3D WebGPU demos look stunning — but what do they cost? A technical audit of animation payloads, tracking signal, and browser reality.
The web animation renaissance is real, and it is quietly bankrupting Core Web Vitals scores across Southeast Asia’s mid-market brand sites. Two pieces published this week — Alexey Kopytin’s architectural breakdown of a Lottie-driven tactile UX on Smashing Magazine, and Francesco Michelini’s Three.js WebGPU cluster tutorial on Codrops — are worth reading together, not just for the craft, but for what they reveal about the tradeoffs most teams never finish calculating.
Lottie Is Not Free: The Payload Math Your Designer Won’t Run
Kopytin’s write-up on building a browser-based squeeze-toy game is genuinely impressive engineering. The team used Lottie animations driven by DOM events and distance-based math to preserve frame-perfect fidelity to the original motion design — no approximating easing curves in CSS, no compromise on designer intent. Architecturally sound. But the strategic question nobody in that article asks is: what does this weigh?
Lottie’s runtime library sits at roughly 148KB minified, before your JSON animation files. A single complex animation exported from After Effects can run 80–300KB. Stack three interactive states and you’re looking at a 600KB+ JavaScript and asset payload before your page has done anything else. On a 4G connection in Medan or Cebu — median mobile download speed around 20–25 Mbps with meaningful latency variance — that’s a perceptible lag window. For e-commerce or app landing pages where the animation is the conversion argument, that lag is the worst possible moment to lose attention.
The tactical fix: lazy-load Lottie only when the animation enters the viewport, use the lighter lottie-web svg renderer instead of canvas where interactivity allows, and cap JSON animation files at 100KB by simplifying After Effects compositions at export. Kopytin’s architecture is replicable — the payload discipline is the part teams need to import alongside it.
WebGPU in Production: Spectacular, Narrow, and Worth Watching
Michelini’s Three.js tutorial using TSL (Three.js Shading Language) and WebGPU to build an interactive 3D icosahedron cluster is the kind of work that ends up on Awwwards. It is also, right now, a controlled experiment with a narrow blast radius.
As of mid-2026, WebGPU has broad support in Chrome and Edge, partial support in Firefox, and a conditional rollout in Safari — which remains the dominant mobile browser across iOS devices in Singapore, Bangkok, and Manila. The practical implication: any production deployment of WebGPU-first experiences needs a WebGL fallback or a graceful degradation path, or it is functionally broken for a material slice of Southeast Asian mobile traffic.
The Three.js TSL approach Michelini demonstrates is forward-looking and the shader abstraction is genuinely cleaner than raw GLSL. But the JavaScript payload for a full Three.js scene — even tree-shaken — starts around 250KB. Add post-processing passes and noise functions and you’re past 400KB of JS before any geometry data loads. For brand campaigns running on Shopee’s in-app browser or LINE’s WebView, which impose their own rendering constraints, these numbers are not theoretical — they are the difference between a campaign that runs and one that silently fails.
The strategic read: WebGPU is where interactive brand experience is going. Invest in team capability now, but gate production usage behind browser detection and set explicit performance budgets per scene — ideally under 500KB total page weight for anything expected to run in a social or commerce WebView.
Animation Libraries as Tracking Surfaces (The Bit Everyone Skips)
Here is the angle neither tutorial touches, which is the one that should be in every technical review before a library gets approved: third-party animation SDKs and CDN-hosted runtimes are data collection vectors.
Lottie served via LottieFiles’ CDN, for instance, passes requests through their infrastructure. Three.js loaded from a public CDN exposes user IP and browser fingerprint to that CDN operator. In the context of Southeast Asia’s rapidly evolving data privacy landscape — Thailand’s PDPA, Indonesia’s PDP Law, Vietnam’s Decree 13 — any third-party asset request that could constitute personal data processing requires a legal basis and, often, a Data Processing Agreement. Most teams shipping animation libraries are not thinking about this. Most DPOs are not asking about it yet. That gap is closing.
The mitigation is straightforward: self-host animation runtimes, audit CDN usage quarterly, and document the data flow for any library that phones home. This is not a reason to avoid Lottie or Three.js — it’s a reason to operationalise them properly.
The Stakeholder Conversation Your Tech Lead Needs to Start
Beautiful, interactive, physics-driven UX sells in creative reviews. It performs differently in production across a fragmented device landscape where a Samsung Galaxy A-series on a congested network is a median user, not an edge case. The craft demonstrated in both tutorials this week is real and worth learning. The missing chapter in both is the stakeholder brief: how do you take an After Effects-perfect Lottie concept or a WebGPU cluster demo and translate it into a shipped experience that holds its performance SLA?
The answer is not to simplify the ambition. It’s to define the budget before the build — payload budget, render budget, browser support matrix — and treat those constraints as creative inputs rather than post-launch findings. The teams shipping the most impressive interactive work in Southeast Asia right now are not shipping the heaviest JavaScript. They’re the ones who audited it first.
As the browser rendering layer grows more capable, the performance discipline required to use it responsibly grows proportionally. The more interesting question is whether the next generation of design-engineering teams will treat payload audits and privacy reviews as part of the creative process — or whether they’ll keep discovering them in production analytics, one bounce rate spike at a time.
At grzzly, we work with digital and brand teams across Southeast Asia to audit JavaScript payloads, map third-party data flows, and build animation architectures that hold up in production — not just in Figma. If your team is navigating the gap between creative ambition and technical reality, we’ve been in that room before. Let’s talk
Sources
Written by
Stormy GrizzlyStress-testing email open rates, dissecting Apple's Mail Privacy Protection, and auditing the JavaScript payloads quietly leaking signal. The analyst who reads the spec, not just the summary.