Add isSupported metric property

[stefanjudis]

I'm currently trying to wrap the web vitals lib into a custom <web-vitals /> element.

It would be great if there would be a way to get information about the support of a particular metric. E.g. in Firefox the reporters are just not called. I could imagine to include an isSupported property or similar in the metric object that is passed to the particular reporter. Could this be a valuable addition?

Thanks a bunch for this project, it's great!

[philipwalton]

It would be great if there would be a way to get information about the support of a particular metric. E.g. in Firefox the reporters are just not called. I could imagine to include an isSupported property or similar in the metric object that is passed to the particular reporter. Could this be a valuable addition?

An isSupported property on the Metric object would not work since the Metric object would only ever be delivered to callbacks if the browser supported the API, i.e. it would always report true.

In general, if you want to know if a metric is supported you can use the PerformanceObserver.supportedEntryTypes API, which is how this library detects support. Is that sufficient for your use case?

[stefanjudis]

Thanks for answering Phil. In the best case, I wouldn't want to feature-detect outside of web-vitals because I believe it's valuable information if people want to build widgets on top of web-vitals. :)

The feature detection code you linked is exactly what I had in mind to tweak it a little bit.

export const observe = (
    type: string,
    callback: PerformanceEntryHandler,
): PerformanceObserver | undefined => {
  try {
    if (PerformanceObserver.supportedEntryTypes.includes(type)) {
      const po: PerformanceObserver =
          new PerformanceObserver((l) => l.getEntries().map(callback));

      po.observe({type, buffered: true});
      return po;
    } else {
      // give information that `type` is not supported here
      // by calling the callback with support information (in any format)
      // -> callback({ isSupported: false })
    }
  } catch (e) {
    // do nothing
  }
  return;
};

Feel free to close if you don't consider adding something along these lines. :)

[philipwalton]

I left this open because I wanted to think about whether it made sense to expose this in some way.

My initial inclination was to return the PerformanceObserver object if one was created, but there are a few reasons why that might not work for feature detection:

1. If the site is using a polyfill (e.g. the FID polyfill) then there won't be a PerformanceObserver instance to return, but a metric will still be reported.
2. The getTTFB() function (for maximum browser compat) does not use PerformanceObserver so it won't work for that case either.

callback({ isSupported: false })

I'm also hesitant to change the callback signature since lots of code out there is already written with the expectation that the callback is only invoked if the metric was successfully captured as is ready to be reported.

All in all, I think I want to stick with the original principle that the library should run in all browsers, but the callback will only be invoked in the browser supports the metric.