Periodic ~80–90 ms Page Scheduling Stalls Every ~2.34 Seconds in Microsoft Edge for iOS

Summary

Microsoft Edge for iOS periodically stalls page scheduling for approximately 80–90 ms every ~2.34 seconds.

The issue is reproducible:

In a completely isolated InPrivate session

On a pure DOM test page

Without WebGL, Canvas, Vue, React, JavaScript frameworks, or third-party libraries

Without network activity being required

With a simple requestAnimationFrame loop and timer-based measurements

The same test page does not exhibit this periodic behavior in Safari or Chrome on the same iOS device.

The stalls also do not appear as JavaScript longtask entries through PerformanceObserver.

This strongly suggests an Edge-for-iOS-specific scheduling, browser/UI, WebView, compositor, or internal browser activity rather than an application-level JavaScript performance problem.

---

Environment

Browser: Microsoft Edge for iOS

Edge version: 152.0.4191.65

Device: iPhone 16

iOS version: 26.6.2

Mode: InPrivate

Network: Wi-Fi / Cellular

Reproducibility: Consistent

Comparison browsers

The same test page was tested on the same device:

Safari: No periodic stalls observed

Chrome for iOS: No periodic stalls observed

Edge for iOS: Periodic stalls consistently reproduced

---

Steps to Reproduce

Open Microsoft Edge for iOS.

Open an InPrivate tab.

Open the following minimal reproduction:

https://olki-town.xdz.me/probe-dom.html

Leave the page running without interacting with it for approximately 30 seconds or longer.

Observe the reported requestAnimationFrame intervals and timer lag.

Repeat the same test in Safari and Chrome for iOS on the same device.

The issue can also be reproduced with the WebGL probe:

https://olki-town.xdz.me/probe-webgl.html

However, the WebGL dependency is not required to reproduce the problem because the pure-DOM probe exhibits the same behavior.

---

Actual Result

In Edge for iOS, the page periodically experiences an approximately 80–90 ms gap between animation frames, with a very stable interval of approximately 2.34 seconds between these events.

Example output from the pure-DOM probe:

*ETA(DOM) t=30s hitches=13 worst=91ms
t21.03s +90ms lag105ms T-
t23.37s +80ms lag104ms T-
t25.71s +91ms lag105ms T-
t28.05s +80ms lag105ms T-

The pattern is highly regular:

~2.34 seconds
    ↓
~80–91 ms scheduling gap
    ↓
~2.34 seconds
    ↓
~80–91 ms scheduling gap
    ↓
...

The timer measurement also shows approximately 104–105 ms scheduling intervals during these events.

Importantly, PerformanceObserver with the longtask entry type does not report a corresponding long JavaScript task (T- in the probe output).

---

Expected Result

requestAnimationFrame should continue at the expected display refresh cadence without periodic ~80–90 ms stalls when the page is otherwise idle.

A simple DOM animation should remain smooth and should not experience a regular ~2.34-second scheduling interruption.

The same page behaves normally in Safari and Chrome for iOS.

---

Why this appears to be an Edge-specific issue

I initially suspected that the problem might be caused by my application, Three.js/WebGL rendering, Vue, game logic, or some other JavaScript workload.

I therefore created a minimal reproduction that removes those variables.

The pure-DOM reproduction contains no:

Three.js

WebGL

Canvas rendering

Vue or other frameworks

Third-party libraries

Game logic

NPC logic

Physics/collision logic

Complex DOM

Required network requests

Despite this, Edge for iOS still exhibits the same periodic stalls.

The issue is also reproducible in InPrivate mode, so it does not appear to depend on my normal browser profile, account synchronization, or normal browsing state.

Safari and Chrome for iOS do not reproduce the issue on the same device using the same test page.

---

Long Task Observation

The test page uses PerformanceObserver to monitor:

new PerformanceObserver((list) => {
    // inspect longtask entries
}).observe({
    type: 'longtask',
    buffered: true
});

No corresponding longtask entry is observed when the ~80–90 ms frame gaps occur.

This appears significant because the behavior looks more like a page scheduling / browser-level pause than a JavaScript task occupying the main thread for 80–90 ms.

In other words, the observed behavior is approximately:

requestAnimationFrame
        ↓
~80–90 ms scheduling gap
        ↓
next requestAnimationFrame

while the Long Tasks API does not report an 80–90 ms JavaScript task responsible for the gap.

---

Timer Correlation

The probe also monitors a periodic timer.

During the same events where requestAnimationFrame experiences an ~80–90 ms gap, the timer measurements consistently show approximately 104–105 ms scheduling intervals.

This indicates that the phenomenon is not limited to the animation frame callback itself.

Both animation-frame delivery and timer delivery appear to be affected.

---

Lock Screen / Resume Test

I also tested the behavior after locking and unlocking the device.

As expected, locking the device causes a very large apparent gap because page execution is suspended/backgrounded. For example:

worst=259986ms

That large value is expected and is not considered the bug.

The important observation is that after the device is unlocked and the page resumes, the same regular ~2.34-second / ~80–90 ms periodic stalls continue to occur.

Therefore this does not appear to be merely an artifact of the initial page startup.

---

Minimal Reproduction

The DOM reproduction is available here:

https://olki-town.xdz.me/probe-dom.html

The WebGL reproduction is available here:

https://olki-town.xdz.me/probe-webgl.html

The DOM reproduction is the more important one because it demonstrates that WebGL is not required.

The test page measures:

requestAnimationFrame intervals

timer scheduling intervals

PerformanceObserver long tasks

The periodic behavior can be observed without any application-specific workload.

---

Frequency and Timing

The observed pattern is unusually regular.

Typical observations:

MeasurementObservedPeriod between stalls~2.34 s----------------Period between stalls~2.34 sRAF gap~80–91 msTimer interval around event~104–105 msLong Task entryNoneWebGL requiredNoDOM requiredMinimalInPrivate modeReproducesSafari iOSDoes not reproduceChrome iOSDoes not reproduceThe regularity makes me suspect that some periodic Edge-for-iOS internal operation may be temporarily affecting page scheduling.

Possible areas might include browser UI activity, telemetry, IPC, compositor coordination, process scheduling, memory/resource management, privacy/security processing, or another Edge-specific periodic task.

I cannot determine the exact internal cause from web APIs, so this is only a hypothesis.

---

Additional Information

The problem was originally discovered while investigating intermittent stuttering in a real-time browser game.

The game uses animation and continuous movement, so an ~80–90 ms interruption every ~2.34 seconds is clearly visible as a hitch.

Initially I suspected the game's rendering or update loop. However, after reducing the problem to the pure-DOM reproduction above, the same periodic behavior remained.

This makes an application-level cause very unlikely.

---

Request

Could the Edge for iOS team investigate whether there is a periodic internal operation or scheduling mechanism that can cause approximately 80–90 ms page execution/scheduling stalls every ~2.34 seconds?

In particular, it would be useful to determine why:

requestAnimationFrame delivery is periodically delayed;

timers are affected at approximately the same time;

the event does not appear as a JavaScript Long Task;

the behavior reproduces in InPrivate mode;

the behavior reproduces on a minimal pure-DOM page;

Safari and Chrome for iOS do not reproduce it on the same device.

The minimal reproduction should make it possible to investigate this independently of any particular website or JavaScript framework.

Thank you.