Capturing metadata with events

[OliverJAsh]

(Apologies if this has already been discussed before. I did try to search for existing issues but I couldn't find anything matching this.)

We would like to track the current URL for each event. Our initial implementation was something along the lines of this:

import {onLCP, onFID, onCLS} from 'web-vitals';

onCLS(metric => {
  const currentUrl = window.location.href;
  console.log({ currentUrl, ...metric });
});

As you might expect, the problem we encountered with this is that the current URL may have changed by the time the event is dispatched by the library because events are reported asynchronously.

I understand this library has experimental support for SPAs and soft navigations (#119) so perhaps we should just try using that, but I can imagine this problem could arise for other things too. For example, imagine if we wanted to track the current screen size or whether the user is logged in.

I believe we could workaround this issue by using reportAllChanges but it seems a shame to lose the built-in reporting strategy.

As an idea, perhaps the library could expose an additional callback so extra data can be captured at the time the event occurs. Then this data would be reported along with the original metric data. Pseudo code:

import {onLCP, onFID, onCLS} from 'web-vitals';

onCLS((metric, captured) => {
  console.log({ ...captured, ...metric });
}, {
  capture: () => ({ currentUrl: window.location.href }),
});

Alternatively, the library could provide an API to synchronously flush buffered events, then we could use this ahead of soft navigations.

Do you think it makes sense for the library to support something like this?

[tunetheweb]

I presume your implementation is some sort of SPA then, since with a full page transition the URL cannot change without unloading the library (and flushing all the events)?

In that case, the event can still be emitted after a soft navigation anyway (e.g. think of clicking on a next button, which will immediately navigate and then emit the INP event) so capturing the current window.location.href at the time the event is emitted would not always be sufficient.

What is needed is for the browser to emit the URL with the event so this is captured at the time the event happens, rather than when it is reported to the library (and then when the library passes that on to the onXXX callback). This is what the navigationId property does which is currently part of the soft navigations proposal.

Additionally, I'm not sure of the value of attributing the metrics to particular soft nav URLs since, without the soft nav experimental branch, the metrics will be reported incorrectly (e.g. LCP will be reported on the first URL only, CLS and INP will be across all the soft navs). Again, this is what the soft navs branch (and corresponding Chrome feature) is designed to solve.

[OliverJAsh]

I presume your implementation is some sort of SPA then, since with a full page transition the URL cannot change without unloading the library (and flushing all the events)?

That's right. Apologies for not mentioning that before.

In that case, the event can still be emitted after a soft navigation anyway (e.g. think of clicking on a next button, which will immediately navigate and then emit the INP event) so capturing the current window.location.href at the time the event is emitted would not always be sufficient.

Good point, I hadn't thought of that.

In that case it sounds like we need to give the soft nav branch a go. There's potentially still an unsolved use case for capturing other metadata at the time of the event like I mentioned above, but that's just an imaginary use case.

Thanks for your help!