Inefficient supportsNativeFetch() check (does DOM I/O)

[AaronO]

Package + Version

• @sentry/browser @ master

Problem

The supportsNativeFetch() check takes up to 10-20ms of CPU time in the critical path. Because it does DOM I/O (appends then removes <iframe>)

I understand that we create an iframe to get a "pure" JS environment that hasn't been tampered with by polyfills, etc ...

But I'm not sure that's significantly more robust than checking window.fetch (the current indexOf check is likely to yield false-positives, but that can be improved with the regex I provided below).

Solution

Replace supportsNativeFetch() with a faster implementation that avoids DOM I/O. Such as:

function supportsNativeFetch() {
    return window.fetch && /^function fetch\(\)\s+\{\s+\[native code\]\s+\}$/.test(window.fetch.toString());
}

I tested the following regex on Chrome/Safari/Firefox:

^function fetch\(\)\s+\{\s+\[native code\]\s+\}$

Context

In profiling our app boot and thus indirectly @sentry/browser.init(), we realized that ~10-20ms of CPU time in the critical path is spent in supportsNativeFetch().

10-20ms (likely more on slower devices, mobile etc ...) may not seem like much, but since it's blocking and in the critical path it's worth optimizing