Safari Tech Preview 246: What Web Teams Must Act On Now

Safari controls the mobile browser experience for roughly half of Southeast Asia’s premium consumer segment — the iPhone-carrying audience that brands fight hardest to convert. When WebKit ships a Technology Preview, most teams file it under “eventually relevant.” That’s a mistake. Preview 246 contains changes that will touch rendering behaviour, CSS layout, and JavaScript execution in ways that directly move Core Web Vitals numbers.

Here’s what deserves your attention before this lands in production Safari.

Safari Preview 246’s Rendering Changes Are a Performance Signal, Not a Curiosity

Safari Technology Preview 246, released June 17, includes a set of WebKit-level fixes and capability additions that affect how browsers parse, render, and execute page resources. The pattern across recent previews is consistent: Apple is tightening conformance with web standards while simultaneously extending Safari’s own feature surface — which creates a narrow window where your existing implementation might behave differently than expected once the preview ships to stable.

For teams running Shopee or Lazada integrations with heavy JavaScript-driven product carousels, the risk sits specifically in layout recalculation. If your rendering pipeline relies on timing assumptions baked into older Safari behaviour — particularly around how reflows are triggered during scroll — Preview 246’s changes are worth stress-testing against now. Set up a BrowserStack or LambdaTest device farm run against your staging environment using the preview build. An hour of testing now is worth days of post-release CLS firefighting.

The broader principle: WebKit previews are the earliest signal you have for upcoming Lighthouse and CrUX score shifts on iOS. Treat them accordingly.

CSS @function and alpha() Aren’t Just Syntax Sugar — They’re Architecture

CSS-Tricks’ What’s !important #13 highlights two incoming CSS capabilities worth understanding beyond their headline novelty: the @function rule and the alpha() colour function. The performance angle here is less obvious than a WebKit patch note, but it’s real.

Native CSS @function allows teams to define reusable logic directly in stylesheets — calculations, conditional values, responsive adjustments — without JavaScript. For Southeast Asian sites managing multilingual interfaces across Thai, Bahasa, Vietnamese, and English, this matters. Localised text strings notoriously break fixed-dimension layouts, triggering layout shifts that tank CLS scores. A CSS-native function that computes container sizing relative to content length — without a JS observer firing on every paint — removes an entire class of performance overhead.

The alpha() colour function is a smaller win but a real one: cleaner colour token management in design systems means fewer CSS specificity conflicts and less stylesheet bloat when themes are applied across a regional brand’s sub-markets. If you’re maintaining a shared component library for a brand operating across five SEA markets, this is the kind of primitive that compounds into meaningful stylesheet size reduction over time.

---

Thoughtful Motion and Modern CSS: The Performance Case for Constraint

Codrops published a conversation with developer and educator Cyd Stumpel this week that’s worth reading not for its inspiration value — though it has that — but for one specific technical stance: the argument that modern CSS, used deliberately, produces better motion than JavaScript animation libraries.

This is a performance position, not an aesthetic one. CSS animations and transitions execute on the compositor thread. JavaScript-driven animations — including many GSAP implementations when not correctly configured — block the main thread and contribute to Interaction to Next Paint (INP) regressions. Stumpel’s emphasis on CSS-first motion isn’t nostalgia; it’s an architectural preference that happens to align with how browsers are optimised.

For SEA teams building on mid-range Android devices — which still represent a significant share of the non-iPhone market across Indonesia, the Philippines, and Vietnam — this distinction is material. A 120fps scroll animation on a developer’s MacBook Pro becomes a janky, INP-killing experience on a Redmi Note. CSS-compositor animations degrade far more gracefully. The practical implication: audit any third-party motion library in your stack. If it’s not using WAAPI or pure CSS transforms, it’s probably costing you INP points on your highest-volume devices.

Safari Feature Parity Is Closing — and That Changes Your Cross-Browser Strategy

Stefan Judis flagged in Web Weekly #194 that the Safari feature gap — long the source of significant cross-browser compatibility overhead — is closing faster than many teams have updated their assumptions. New CSS capabilities landing in Safari previews now are often shipping within one to two stable release cycles, compared to the multi-year lag that defined the pre-2022 era.

This has a direct resourcing implication. Teams that built elaborate polyfill layers or JavaScript fallbacks for CSS features Safari historically didn’t support are now carrying dead weight in their bundles. A quarterly audit of your polyfill inventory against the current Safari stable feature set is not a nice-to-have — it’s bundle size optimisation with zero design risk. Removing an unnecessary polyfill for CSS Grid subgrid or container queries can trim 10–30KB from a JavaScript bundle, which at SEA mobile network speeds translates directly to faster Largest Contentful Paint.

The strategic shift: stop building cross-browser strategy around what Safari was and start building it around what Safari is. The two are increasingly different documents.

Key Takeaways

• Test your staging environment against Safari Technology Preview 246 now — specifically targeting CLS and INP on JavaScript-heavy product pages before changes reach stable.
• Evaluate CSS @function and alpha() as genuine architecture tools for multilingual design systems, not just syntax novelties; the performance gains in layout stability are real.
• Audit your polyfill inventory against current Safari stable support — bundle weight from legacy fallbacks is likely your lowest-effort LCP win right now.

The browser compatibility story of 2026 looks very different from 2020, and most web teams are still operating on the older mental model. The real question worth sitting with: if Safari parity continues closing at this pace, what does your cross-browser testing and fallback strategy look like in 18 months — and are you already building toward that, or waiting until the gap is obvious?

---

At grzzly, we work with digital and e-commerce teams across Southeast Asia on exactly the kind of performance engineering that turns browser updates into conversion gains rather than support tickets. If your team is navigating Core Web Vitals targets across a fragmented mobile landscape, we’re the people to have that conversation with. Let’s talk