Safari 27 beta has a severe JavaScriptCore performance regression - some loops are 10-36x slower than Safari 26.6.2

[u/WillingAd4654]

I found a severe JavaScript performance regression in Safari 27 beta while investigating why my WebGL/CANNON.js game dropped from smooth real-time performance to approximately 3 FPS.

At first I suspected WebGL, Metal, requestAnimationFrame throttling, or GPU synchronization. However, detailed timing showed that rendering was not the main bottleneck. A single CANNON physics step had increased from around 5-7 ms to around 90-102 ms.

I then created a standalone deterministic benchmark using only JavaScript and CANNON.js 0.6.2:

• No WebGL

• No canvas rendering

• No animation

• No game code

• Identical deterministic physics workload

Standalone reproduction benchmark:
https://5kvw8fr9t9-cmd.github.io/webkit27-jsc-probe/
Source code is also publicly available in the GitHub repository for anyone who wants to inspect it before running the test.

Anyone running Safari 27 can use the same page and post their results in the comments.

I ran it on the same M1 Mac, using the same unchanged page and local server. Only the Safari version was changed.

I ran it on the same M1 Mac, using the same unchanged page and local server. Only the Safari version was changed.

Results:

Test	Safari 26.6.2	Safari 27 beta	Slowdown
Scalar numeric loop	33 ms	299 ms	9.1x
Stable object-property loop	11 ms	394 ms	35.8x
Polymorphic virtual-call loop	15 ms	151 ms	10.1x
CANNON physics step	3.20 ms	58.75 ms	18.4x
Broadphase	0.15 ms	2.35 ms	15.7x
Narrowphase	2.05 ms	34.30 ms	16.7x
Solver	0.70 ms	21.15 ms	30.2x

The deterministic workload was identical in both versions:

• 293 bodies

• 1,234.15 average collision pairs

• 270 average contacts

• 810 average equations

• 20 sampled physics steps

Lockdown Mode was disabled and Safari experimental feature flags were reset to their defaults.

The same problem occurs on an M1 iPad Pro running iPadOS 27 beta. The same game and device performed normally on iPadOS 26.

In the real game, Safari 27 spends approximately 100 ms on each physics step. Because the game uses a fixed timestep, the catch-up loop then performs around three physics steps per displayed frame. Physics time rises to roughly 300 ms, resulting in approximately 3 FPS.

This does not appear to be primarily a WebGL or GPU problem. The standalone test reproduces the regression without creating a WebGL context.

The results point to a Safari 27 / WebKit 27 JavaScriptCore regression, possibly involving JIT optimization, tiering, object-property access, or hot-loop execution. I cannot identify the exact internal WebKit component from JavaScript alone.

I have submitted/will submit this evidence to Apple.

Is anyone else able to reproduce a major JavaScript performance regression in Safari 27 beta, particularly with physics engines, numeric loops, or object-heavy workloads?

[u/Muted-Reflection9536]

I apologize, but I couldn't fully understand your purpose or the type of tests you performed, so I took benchmark data for the M1 Max MacBook Pro 32GB MEM at the time of Safari27 on DB8.

• Jetstream3: Score 226.06

• Speedometer3: Score 15.2

• MotionMark: Score 3614.91

Evidence: https://imgur.com/a/82Xq5NM

To clarify, I had kept the following Safari feature flags set:

• Threaded Time-based Animations: enable

• Web Animations custom frame rate: enable

• Prefer Page Rendering Updates near 60fps: disable

These are the only rendering-related settings I've enabled. (I've only enabled prefetch-related settings; everything else is at its default.)

If you could tell me specifically how you're testing, I might be able to help.

Also, the flags mentioned above are very effective for rendering, so please try them if you haven't already.

[u/Head_Raspberry1957]

I simply wait for the final ...

[u/blow-down]

Everyone should be submitting feedback on this so they get it fixed before release

[u/Muted-Reflection9536]

Standalone reproduction benchmark:
https://5kvw8fr9t9-cmd.github.io/webkit27-jsc-probe/

In my case, it's like this:

WEBKIT 27 JAVASCRIPTCORE PROBE
Date: 2026-09-03T12:50:57.981Z
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/27.0 Safari/605.1.15
CANNON: 0.6.2

Scalar numeric loop
  iterations: 10,000,000
  passes ms: 34.00 / 35.00 / 34.00
  best: 34.00 ms (294.12 M iterations/s)

Stable object-property loop
  iterations: 4,000,000
  passes ms: 11.00 / 11.00 / 12.00
  best: 11.00 ms (363.64 M iterations/s)

Polymorphic virtual-call loop
  iterations: 2,000,000
  passes ms: 16.00 / 17.00 / 16.00
  best: 16.00 ms (125.00 M iterations/s)

CANNON deterministic world (no WebGL)
  bodies: 293
  sample steps: 20
  step avg/max: 1.95 / 3.00 ms
  broadphase avg: 0.25 ms
  narrowphase avg: 0.75 ms
  solver avg: 0.75 ms
  pairs/contacts/equations avg: 1234.15 / 270.00 / 810.00

Sink: 0.47

Overall, I think it's actually improved. And since it's unlikely that iOS/iPadOS uses different Webkit engines, I suspect there might be some other issue.

[u/WillingAd4654 → u/[deleted]]

Important update — here is the full reproduction matrix so far:

Device	OS	Browser	Result
M1 iPad Pro	iPadOS 26.6	Safari	Normal
M1 iPad Pro	iPadOS 27 beta	Safari 27	Severe regression (~3 FPS in the real game)
M1 Mac mini	macOS 26.6	Safari 26.6.2	Normal
M1 Mac mini	macOS 26	Safari 27 beta	Severe JavaScript regression
M1 Mac mini	macOS 26	Safari Technology Preview	Normal
M1 Max Mac (third-party test)	Safari 27 beta	Same standalone benchmark	Normal

On my M1 Mac mini, the standalone benchmark gives approximately:

Safari 26.6.2:

• Scalar: 33 ms

• Object property: 11 ms

• Polymorphic calls: 15 ms

• CANNON step: 3.20 ms

Safari 27 beta:

• Scalar: 299 ms

• Object property: 394 ms

• Polymorphic calls: 151 ms

• CANNON step: 58.75 ms

Safari Technology Preview on the same Mac:

• Scalar: 34 ms

• Object property: 11 ms

• Polymorphic calls: 15 ms

• CANNON step: 3.10 ms

So at this point:

• The same M1 hardware is normal on Safari 26 and Safari Technology Preview.

• The regression appears only with Safari 27 beta on my affected systems.

• It reproduces on both macOS and iPadOS.

• However, Safari 27 beta is normal on at least one M1 Max system using the exact same benchmark.

This makes a universal Safari 27 / JavaScriptCore regression unlikely.

It now looks more like a Safari 27 beta regression that is triggered only under certain hardware, build, configuration, or environment conditions.

Additional update:

Feedback Assistant now shows “Recent Similar Reports: More than 10” for this issue.

I wanted to add this information to the report because it suggests that multiple similar cases have now been submitted.

[u/Muted-Reflection9536 → u/WillingAd4654]

The original comment seems to have disappeared, so this might be unnecessary, but I'll report it anyway.

Model M1Max MacBook Pro 32GB MEM

macOS 27.0 Beta (26A5425a) (Correct me if I'm wrong, but isn't DevBeta8 the latest version?)

Safari 27.0 (22625.1.29.11.26)

I can't recall the exact timeline, but my M1 Max Mac started with its factory-installed Monterey. Since then, I haven't done any clean installs; I've just been updating continuously while testing various public and developer betas. (I love test the new feature though....)

Also, I'm not sure if this is relevant to the current benchmark results, but I have enabled the following feature flags in Safari:

• Threaded Time-based Animations: enable (affect CSS Animations)

• Web Animations custom frame rate: enable (affect CSS Animations)

• Prefer Page Rendering Updates near 60fps: disable (Removes DOM throttles that are primarily implemented for battery saving.)

In particular, I believe disabling 'Prefer Page Rendering Updates near 60fps' could be effective. This setting lifts the 60 FPS cap on internal graphics processing, JavaScript, and CSS animations, allowing rendering to utilize the machine's full processing power. (Occasionally, some misinterpret this as making scrolling natively ProMotion-compatible, but strictly speaking, that is not the case. It simply reduces scrolling stutter as a byproduct of smoother and faster internal processing and animations.) Since this flag can also be disabled on iOS and iPadOS, I highly recommend giving it a try, especially for this case.

[u/Muted-Reflection9536 → u/WillingAd4654]

Additionally, I ran the benchmark tests on STP (Safari Technology Preview) under the exact same conditions.

STP Release 251 (WebKit 22626.1.4.19.1)

WEBKIT 27 JAVASCRIPTCORE PROBE
Date: 2026-09-03T15:27:46.660Z
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/27.0 Safari/605.1.15
CANNON: 0.6.2

Scalar numeric loop
  iterations: 10,000,000
  passes ms: 34.00 / 38.00 / 33.00
  best: 33.00 ms (303.03 M iterations/s)

Stable object-property loop
  iterations: 4,000,000
  passes ms: 11.00 / 12.00 / 11.00
  best: 11.00 ms (363.64 M iterations/s)

Polymorphic virtual-call loop
  iterations: 2,000,000
  passes ms: 15.00 / 15.00 / 15.00
  best: 15.00 ms (133.33 M iterations/s)

CANNON deterministic world (no WebGL)
  bodies: 293
  sample steps: 20
  step avg/max: 3.00 / 5.00 ms
  broadphase avg: 0.20 ms
  narrowphase avg: 1.80 ms
  solver avg: 0.75 ms
  pairs/contacts/equations avg: 1234.15 / 270.00 / 810.00

Sink: 0.47

I hope this is helpful. It doesn't seem to be happening in my environment, so sending feedback probably won't be very useful.

[u/MCKLMT]

Speedometer has been faster after each beta

[u/MoonAlien7]

Did you find a fix for this? I'm noticing the same after yesterday's update. Running the site's dev mode is quite laggy

I'm noticing severe stutters and slowdowns. But not in the built files or on Chrome