search

GoogleChrome / web-vitals

Essential metrics for a healthy site.
https://web.dev/vitals
Apache License 2.0
7.59k stars 415 forks source link

INP may be a bit extreme for content that has a slower reaction time by design #347

Closed simonferndriger closed 1 year ago

simonferndriger commented 1 year ago

Just wanted to offer for consideration that there is some content out there that react slower by design, for example webcam livestreams. I recognized by playing around with the extension a bit that the INP was exploding the second a webcam took a bit longer to load.

Of course this is not good, but on the other hand, it won't get better in the near future no matter what.

tunetheweb commented 1 year ago

This repo is for the web-vitals.js library rather than general feedback on the web vitals programme, or individual metrics. For that you're better reaching out to: https://groups.google.com/g/web-vitals-feedback.

However my feedback on this, without having the full context of what this is, is that it's doubtful that that is "slower by design" and regardless it IS impacting the users - hence it should be measured. Just because it won't get better in the near future is not a reason to give such an interaction a "free pass".

INP measures how long after an interaction a paint can happen. If this is a long, synchronous transaction, that is blocking the main thread, then yes that will result in a bad INP measure as it's bad for that interaction and also could hold up other interactions on the page. And that definition of INP entirely intentionally.

If it can be made asynchronous, so it doesn't block the main thread, then this should not result in a bad INP measure, even if it still takes some time to actually complete the full action (e.g. start up the webcam). It is also advisable to give some feedback to the user (e.g. "Waiting for webcam...") which is why having the ability to do a "next paint" and not blocking that is so key. But technically INP does not need a paint - it just needs you to ensure a paint is not blocked (i.e. the main thread is not blocked).

simonferndriger commented 1 year ago

Thank you. Sorry for misplacing this question.

Can you perhaps provide me some more reading material regarding the difference between asynchronous and synchronous (blocking) paints? For example, if I include an iframe with a webcam player and set a loading animation as background, would that count as asynchronous? Or should I ask this in the forum directly?

tunetheweb commented 1 year ago

It's more about what the webcam player is doing. I don't know what webcam software you are using and if it works in a synchronous fashion, or if it's just a heavy JavaScript library that blocks the main thread regardless, but this should be followed up with that software provider.

Just doing this natively in simple JavaScript does not cause high INP: https://www.tunetheweb.com/experiments/webcam/

simonferndriger commented 1 year ago

Thank you for taking the time to create a sample page! However, sorry about the confusion. I was talking about landscape webcams (not streaming a laptop/mobile cam). They have many different software solutions. And in general, they don't perform that well. However, in my experience, the value for the user is much greater if he can see a live stream of a specific location which takes a bit longer (1+ seconds) to load, than a still picture which is loaded within 200ms. That was my main point actually 😊.

tunetheweb commented 1 year ago

And that's fine. But if it blocks the main thread for that second then INP will still (correctly) say this is a poor experience. The site will continue to work as previously, but if you use the Core Web Vitals, it will report on what the experience is.

BTW it is NOT reporting that the image is not coming in for 1+ second. We recognise that not ALL paints can happen within 200ms, but it should not block ANY paints from happening by holding up the main thread with a lot of processing. This has been a source of confusion before - it's more "Interaction until it could paint" (i.e. the main thread was free to do a paint for this, or any other interaction, if it needed to) rather than "Interaction until it did paint".

The key point is that if you click anywhere else on the page while that camera is loading does that work? If not, then that is a bad experience. And that is what the metric is measuring.

Assuming it IS blocking the browser thread as you appear to show it did with the Web Vitals extension, I'm not sure exactly what the ask here is? Should we NOT report the fact that it's blocking the main thread for this specific instance because the software provider doesn't want to fix it (the software could be coded to not be as blocking or as intensive)? Should we pretend it's not a bad experience?

simonferndriger commented 1 year ago

Got it. Thanks 😊