Feature Request for the new Performance Report: Web Vitals

[gu-stav]

First of all my apologies, for opening this issue here. I've tried at the forum but my account got closed for an unknown reason.

I saw that 4.0.0 will bring a great new performance report page. Great news, thanks for that in advance already!

I was wondering whether you considered including the recently proposed web vitals for these reports or whether it's easy to track these from the JS client?

Why would Web Vitals be helpful?

• they are user centric
• google announced they'll become a ranking factor, which makes them quite important for businesses
• they are helpful for developers

What are the Web Vital metrics:

• Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.
• First Input Delay (FID): measures interactivity. To provide a good user experience, pages should have a FID of less than 100 milliseconds.
• Cumulative Layout Shift (CLS): measures visual stability. To provide a good user experience, pages should maintain a CLS of less than 0.1.

[Findus23]

I've tried at the forum but my account got closed for an unknown reason.

That really shouldn't happen. There has been a large amount of new spam accounts I deleted, so there is a chance yours was in this list in which case I am sorry. But I also can't find any account containing your last name in the recent logs. In case you are still interested in the account, please create a new one or contact per E-Mail me (lukas at the domain of Matomo).

On the topic: It seems like the web vitals library just fetches the data from the newly proposed Event Timing API (https://wicg.github.io/event-timing/) which is supposed to give google-lighthouse-like data on page loads.

I'd say as the Event Timing API is a pretty new draft for a new standard and only Chrome has yet implemented it* we could wait a bit to see how it turns out and how many browsers will support it (in the meantime it could be a Matomo plugin on the marketplace)

* I know that Chromium has a huge market share, but I'd still like to imagine that the web is an actual independent set of standards with multiple independent implementations together forming new standards in a democratic way instead of just Google implementing an idea (even if it is a good idea) in Chromium, documenting it as a standard draft and passively forcing all other browsers to implement it or major websites will be broken in them.

See also:

• https://github.com/mozilla/standards-positions/issues/283
• https://github.com/GoogleChrome/web-vitals
• https://github.com/GoogleChromeLabs/first-input-delay (a polyfill for FID)

[tsteur]

Didn't know that event timing existed. Too bad we can't get this information from existing performance API yet it would have been really great to have these metrics.

Here are currently supported browsers https://caniuse.com/#feat=mdn-api_performanceeventtiming (Chrome, Edge, ...)

I see Firefox is currently implementing the Frame timing api but can't find anything re "event timing".

There maybe ways to calculate this already:

• LCP: https://web.dev/lcp/#measure-lcp-in-javascript. (works in most browsers)
• FID: https://web.dev/fid/#measure-fid-in-javascript requires event timing API
• CLS: https://web.dev/cls/#measure-cls-in-javascript

[gu-stav]

Thanks for the quick replies!

@Findus23

I'd say as the Event Timing API is a pretty new draft for a new standard and only Chrome has yet implemented it* we could wait a bit to see how it turns out and how many browsers will support it (in the meantime it could be a Matomo plugin on the marketplace)

I agree with you on that. I don't know what your policy with these new APIs are, but I think to wait till at least two engines have implemented something is a sensible thing to do. I don't think it will take Mozilla very long to build this in, since saying "it will be a ranking factor" usually speeds things up.

On the other hand: Progressive Enhancement is a good way to implement new features. Had a quick look at the github repository for web vitals and it seems that's the way they do it. Of course it's different for Matomo, since it would also skew the performance metrics page a bit of only Chromium Browsers would contribute to the data.

I'll keep an eye on things and come back to this issue as soon as I see some other public signal around the implementation :rocket:

[DevDavido]

@gustavpursche I've been working on such a performance measuring functionality for Matomo and if you like you can try it: https://github.com/DevDavido/performance-audit-plugin

[gu-stav]

@DevDavido Thanks for the hint. I'll try it out first thing after my vacation! ✨

[scarabcoder]

Is there currently support for using the web-vitals JS library for tracking Core Web Vitals, rather than Lighthouse? Often times Lighthouse tests do not show the same results that web-vitals (and because of that, Google's SEO algorithm in May), for example many ad scripts do not get executed until after a Lighthouse or other scan ends.

https://web.dev/vitals-field-measurement-best-practices/

It would be great to get field data from actual users, so (with enough visitors) I could see the results of optimization changes within a few days rather than a month in Google Search Console or a similar tool.