Font Scaling, Safari Fixes, and the Performance Tax on Craft

Accessibility debt and browser inconsistencies are two of the quietest performance killers in SEA front-end teams. They don’t show up in your Lighthouse score until they absolutely do. This week’s signals from Smashing Magazine and the WebKit team put both squarely on the table.

Figma Variables Just Made Font Scaling Accessibility Non-Negotiable

Ruben Ferreira Duarte’s piece in Smashing Magazine makes a deceptively simple argument: accessibility works best when it disappears into your existing workflow, not when it’s a gate at the end of it. The specific mechanism here is using Figma variables to test font size increases — WCAG requires that text scales up to 200% without loss of content or functionality — directly inside the design file, before a single line of code is written.

The practical setup involves creating a variable mode (e.g. font-scale/default vs font-scale/large) that maps your base type tokens to their scaled equivalents. Toggle the mode on a frame and you immediately see whether your 14px UI label turns into an overlapping disaster at 28px. No dev handoff required for the first sanity check.

For SEA teams building multilingual interfaces — think Thai, Bahasa Indonesia, and Vietnamese alongside English — this matters acutely. Thai script at baseline sizes often already pushes layout boundaries; a 200% scale test on a mixed-script UI can reveal structural failures that no amount of CSS overflow: hidden should be quietly swallowing.

The cost of not doing this earlier shows up in CLS. Reflowing text during load or on user-triggered zoom is a Cumulative Layout Shift event waiting to happen. Accessible typography and Core Web Vitals are, in this case, the same problem.

---

Safari Technology Preview 240: What Actually Matters for Production Teams

Safari Technology Preview 240 dropped on March 26th, and while WebKit release notes are famously dense, a few threads are worth pulling for teams shipping to iOS — which, in SEA, means almost everyone.

The preview continues iterating on CSS and JavaScript engine behaviour, with fixes touching scroll-driven animations, @property descriptor handling, and rendering edge cases in display: contents layouts. None of these are headline features, but that’s precisely the point. The gap between Safari’s implementation of scroll-linked animation APIs and Chrome’s has historically forced teams to ship heavier JavaScript fallbacks — a direct latency cost on mid-range Android and iPhone devices that dominate SEA market share.

The practical read: if your team has been avoiding CSS scroll-driven animations because Safari support was patchy, start retesting against Preview 240 builds now. The implementation window for getting this into production without a JS shim is narrowing in your favour. A JS-free scroll animation is not just cleaner code — it’s a measurable reduction in main-thread blocking time, which feeds directly into Interaction to Next Paint (INP), Google’s current Core Web Vitals responsiveness metric.

Also worth flagging: any @property fixes are relevant if your design system uses Houdini-style registered custom properties for animation or theming. Inconsistent @property behaviour across Safari versions has been a silent source of visual regressions in design token pipelines.

The Craft Overhead Problem Nobody Budgets For

Sébastien Lempens’ writeup on building the San Rita topographic web experience — 3D terrain, WebGL textures, immersive motion — is genuinely impressive work. It’s also a useful mirror for thinking about when craft becomes a performance liability.

Immersive WebGL experiences carry a real cost: GPU memory pressure, longer Time to Interactive on lower-end hardware, and meaningful battery drain on mobile. In markets like the Philippines, Vietnam, and Indonesia, where a substantial portion of users are on devices with 3–4GB RAM and mid-tier GPUs, a 3D hero experience can functionally exclude a significant audience segment before they’ve read a word of copy.

The San Rita build works because it’s a portfolio — the audience self-selects, the device profile skews creative-professional, and the experience is the product. That calculus does not transfer to an e-commerce category page or a lead gen landing. The heuristic I’d offer: if you can’t answer “what does this motion/3D element do for conversion or retention specifically,” the performance budget shouldn’t be approved.

The more transferable lesson from the San Rita approach is the use of layered texture and depth as a storytelling system — an idea that can be executed with CSS and SVG at a fraction of the performance cost, and that scales far better across the device spectrum you’re actually serving in SEA.

Key Takeaways

• Integrate Figma variable modes for font scaling now — it turns a WCAG compliance check into a five-second design QA step and catches CLS-inducing text reflow before code is written.
• Retest scroll-driven animations against Safari Technology Preview 240 — dropping JS fallbacks reduces main-thread blocking and directly improves INP scores on mobile devices dominant across SEA.
• Audit immersive craft elements against your actual device audience — WebGL and 3D motion carry GPU and RAM costs that disproportionately affect mid-range hardware; the performance budget conversation needs to happen before the design brief is approved.

---

The thread connecting all three signals this week is the same one it always is: decisions made at the design and tooling layer have direct, measurable consequences in runtime performance. The teams consistently shipping sub-second load times in SEA aren’t faster because they have more engineers — they’re faster because accessibility, browser compatibility, and performance constraints are upstream inputs in their process, not downstream fixes. The question worth sitting with: at which stage in your current workflow does performance first become someone’s responsibility?

At grzzly, we work with SEA growth teams to close exactly this gap — connecting design system decisions, front-end architecture, and Core Web Vitals into a single performance strategy rather than three separate conversations. If your team is navigating multi-language UI complexity, iOS rendering inconsistencies, or immersive design ambitions on a realistic device budget, we’d enjoy the conversation. Let’s talk