Best way to detect browser support

[talsafran]

👋 I saw #36 and had my own guestion about browser support. How do you currently recommend checking if this library is supported by the user agent?

From my reading, the recommended way to approach browser support differences is to detect the existence of an API as opposed to a particular user agent, according to this article?

Here are two snippets we're debating using, each with their own trade-offs:

Approach 1: Detect Chromium browsers

Challenges: This is error prone and will need to be updated as support changes.

function trackWebVitals() {
  const isChromiumBrowser = !!navigator.userAgent.match(/Chrome|Chromium/)
  if (!isChromiumBrowser) return
  
  ...
}

Approach 2: Check if some API exists

Is there one particular API that we could check for? Internally we were considering looking at PerformanceObserver for that.

function trackWebVitals() {
  const hasPerformanceObserver = 'PerformanceObserver' in window
  if (!hasPerformanceObserver) return

  ...
}

But the question here is – would that be enough? Browser support seems to be different for each function:

• getCLS(): Chromium
• getFCP(): Chromium
• getFID(): Chromium, Firefox, Safari, Internet Explorer (with polyfill, see below)
• getLCP(): Chromium
• getTTFB(): Chromium, Firefox, Safari, Internet Explorer

Anyway wondering what your thoughts were. I think that ultimately it would be best if the library just abstracted away the browser support question 😄

function trackWebVitals() {
  const hasBrowserSupport = webVitals.hasFullBrowserSupport()
  if (!hasBrowserSupport) return
}

Thank you! We're excited about this 😄

[Zizzamia]

Great feedback @talsafran!

Have a clear list of where the Browser does or does not support a feature is not quite simple for these APIs. In the past, we had cases like Firefox v58 that had an old issue related to using PerformanceObserver with entryTypes 'paint': https://bugzilla.mozilla.org/show_bug.cgi?id=1403027 . Which the only way to prevent that was with a try/catch, me and @philipwalton had some thoughts around this on #7

With each browser implementing fully or partially those new APIs, it is quite hard to draw a clear line where the browser does or does not support the feature. What I notice the best way is "Approach 2: Check if some API exists" mix with some old school try/catch for edge cases where the browser failed the early implementation.

Those were my quick 2cents, I am sure @philipwalton will share a better 360 overview on your question 😁

[philipwalton]

How do you currently recommend checking if this library is supported by the user agent?

I recommend not checking :)

Anyway wondering what your thoughts were. I think that ultimately it would be best if the library just abstracted away the browser support question 😄

Yep, that's exactly what it does today. If the browser does not support the API, your callback will not be fired (in that browser).

I've tried to make that clear in the documentation, but maybe what I've written is not sufficient? Any suggestions for how to make it more clear?

This code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9 (when transpiled to ES5). However, some of the APIs required to capture these metrics are only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).

[talsafran]

Thanks @Zizzamia @philipwalton ❤️

I recommend not checking :)

Okay – that's good to know 😄. I guess I was worried about some browsers reporting wrong/incomplete data, which would skew our numbers.

However, some of the APIs required to capture these metrics are only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).

So just to be clear –– a browser that doesn't support a given metric (like Safari + FID) will just not report anything, right?

[philipwalton]

Okay – that's good to know 😄. I guess I was worried about some browsers reporting wrong/incomplete data, which would skew our numbers.

I mean, if a browser is reporting bad data, there's only so much the library can do to prevent that. For obviously incorrect data, the library can simply not report those cases, but for incorrect—but not obviously incorrect :)—data, we'd likely just have to report it.

Note: the FID polyfill works around some obvious errors in older browsers, which means those won't be reported by the web-vitals library either.

So just to be clear –– a browser that doesn't support a given metric (like Safari + FID) will just not report anything, right?

Yep, exactly.