Breaking
Instagram Tools 2026: Scheduling, AI and Analytics ConvergeHow to Check If Your Page Shows Up in AI SearchWhat Is Agentic SEO? A Repeatable AI WorkflowWhy Most Creator Ambassador Programs Underdeliver2026 Social Algorithms: Ranking Signals That MatterInstagram Tools 2026: Scheduling, AI and Analytics ConvergeHow to Check If Your Page Shows Up in AI SearchWhat Is Agentic SEO? A Repeatable AI WorkflowWhy Most Creator Ambassador Programs Underdeliver2026 Social Algorithms: Ranking Signals That Matter

Safari 27 Rewrites Its JS Module Loader: Why Martech Cares

WebKit rebuilt Safari's JavaScript module loader in C++ to fix top-level await bugs. Here's what it means for tags, consent tools and measurement.

Safari 27 Rebuilds Its JavaScript Module Loader

Apple’s browser engine team has thrown out Safari’s JavaScript module loader and rebuilt it from scratch. If your tag manager, consent platform or measurement library ships as ES modules, this one is worth five minutes of your attention.

What WebKit actually did

On September 2, 2026, WebKit published a post by engineer Kai Tamkun describing a ground-up rewrite of the component that loads JavaScript modules in Safari. The old loader was written in JavaScript as a self-hosted builtin and based on the WHATWG Loader proposal — a document that received its final update in January 2016 and was later superseded by the ECMAScript standard’s own module section.

The replacement is native C++, translated function by function from the ECMAScript specification. It ships in Safari 27 and is testable now in Safari Technology Preview 251 and the Safari 27 beta.

The headline fix: full specification compliance for top-level await, the ECMAScript 2022 feature that lets you use await at the top level of a module. Safari’s loader had implemented it against a proposal abandoned before async/await even existed in the language. According to WebKit, the resulting bugs resisted repair for years across multiple attempts, so the team deleted the file and started over in January 2026.

The bug, in plain terms

WebKit’s post includes a reproducible test case. A main module imports the same module three times in sequence. That imported module opens with an await on a promise resolved by a ten millisecond timeout, then declares an exported function and an exported array.

Expected order: one, two, three. Under the old loader the imports finished two, three, one — and the second and third threw an exception reading “Cannot access ‘someArray’ before initialization.” The promise for the second import resolved immediately instead of waiting for the first module evaluation to complete, so the code read exports that had not initialized yet.

With the new loader, all three complete in order and print correctly.

Why performance marketers should care

Almost every piece of martech running on your site is JavaScript executing in a visitor’s browser. Consent management platforms. Tag containers. Analytics libraries. Attribution snippets. When the browser resolves module imports in an order the spec does not sanction, the failure is:

  • Intermittent — it depends on timing, so it does not reproduce reliably
  • Browser-specific — it only ever showed up in Safari
  • Easy to misattribute — your vendor gets blamed for an engine defect
  • Loud when it fires — an exception halts the rest of the script

That last point matters most. In a consent or tagging context, a thrown exception can leave a page half-configured: some tags fired, some not, consent state ambiguous. That is a data quality problem and a compliance problem at the same time.

What to do this week

Three practical moves:

1. Re-check your Safari-only bug backlog. If you have open tickets described as “only happens on iPhone” or “random tracking gaps on Safari,” pull them out and retest against Safari Technology Preview 251 or the Safari 27 beta. Some may already be closed by this change.

2. Ask your vendors. Anyone shipping ES modules with top-level await — CMPs, server-side tagging clients, personalisation SDKs — should be able to tell you whether they worked around this and whether the workaround is now redundant.

3. Do not remove your defensive code yet. Safari 27 has no published stable release date; historically it lands alongside the autumn iOS and macOS releases. Older Safari versions will be in your traffic mix for a long time.

The bigger signal

Browser parity has been quietly improving. Safari 26.2, Firefox 146 and Chrome 143 closed the remaining gaps in measuring Largest Contentful Paint and Interaction to Next Paint in December 2025, ending the era when Core Web Vitals were really a Chrome-only measurement.

WebKit says the benefit extends beyond top-level await: with the loader rebuilt on the correct foundation, ES modules as a whole become more dependable in Safari. Engineers at Bun, whose runtime is built on JavaScriptCore and inherited the same defect, contributed test cases. WebKit also fuzzed module graphs and compared output byte for byte against other engines.

For growth teams, the takeaway is unglamorous but real: a chunk of measurement noise you have been living with on Apple devices is about to disappear.

Source: PPC Land

Leave a Reply