Intersection observer and INP during page load

[Peter Warman]

I have (what I think is) a fairly common UI pattern with an image gallery carousel. The carousel is basically a horizontal scrolling area that uses CSS scroll-snap points and an intersection observer to update the UI when a new image has been scrolled in to view.

The problem is that we are detecting many slow interactions while the page is loading (specifically in the DOM Interactive state). I think what is happening here is the user scrolls before the JS has loaded, then there is a delay waiting for the network/execution time, then the intersection observer is registered and callback fires before the DOM is updated and the paint can happen.

My question is what is the best way to handle the slow interaction here since it is dependent on the network? I could prevent the user scrolling until the JS has loaded but that would be a worse user experience overall.

Thanks in advance for any help.

[Barry Pollard]

INP does not wait for network resources as those are (or at least should be!) async so there is an opportunity to paint in between.

INP really is "Interaction to Next (opportunity to) Paint". i.e. when is the easiest we can give feedback for the interaction.

So it sounds more like the page is just very busy during load, so interactions are blocked behind that load.

I'm confused as to how the JS (which has not yet loaded) is able to detect scrolls that happened before it was loaded. Intersection Observer does not (AFAIK!) reply historical intersections prior to the observer being registered so that shouldn't happen. In which case the scroll will happen, a paint will be queued for the scroll and the JS will not be executed. In that case INP is all dependent on what's blocking the paint (loading JS needed by the page?). Even if Javascript then runs after it loads to deal with the fact the carousel is scroll, that should be independent of that earlier interaction so not related to it's INP (though of course it can block any other interactions the users is trying to do while it's running).

It might be easiest to share a trace if you can reproduce this so we can understand what's going on. You can use https://trace.cafe to upload a Performance Panel trace for sharing if you're comfortable doing that.

[Jeremy Wagner]

Note: I replied directly to the author the first time instead of replying all—so now doing so that anyone else can follow along here.

Thanks for your question! It's worth pointing out that scrolling is not factored into INP—only click, tap, and click interactions are. However, I've not seen an example of what you're describing, so I'm not sure if you're relying on scrolling alone, or requiring the user to click a button to force it to happen using JavaScript.

However, it sounds like the work the intersection observer callback is doing may kick off tasks long enough to cause long input delays, which could be affecting other interactions on the page—but this is only a guess. Do you have a URL or demo of this in action? It might help to narrow things down a bit further.

[Peter Warman]

Thanks for coming back to me so quickly. Here is a trace for you: https://trace.cafe/t/8DKRzoyQhF. Hopefully you can see - I manually swipe the carousel around the 1.3s mark and the UI finally updates to display "2/8" and show the left arrow around the 10s mark

We're using the web-vitals.js lib to monitor the page and get a lot of slow interactions with the following data:

interactionTarget - the first image in the carousel (an <img /> element which has no event listeners registered to it - it's inert aside from being inside a scrolling area).

interactionType is "pointer"

loadState is "dom-interactive"

inputDelay is very high

**********************************************************************
This email is confidential and may contain copyright material of the John Lewis Partnership.
If you are not the intended recipient, please notify us immediately and delete all copies of this message.
(Please note that it is your responsibility to scan this message for viruses). Email to and from the
John Lewis Partnership is automatically monitored for operational and lawful business reasons.
**********************************************************************

John Lewis plc
Registered in England 233462
Registered office 171 Victoria Street London SW1E 5NN

Websites: https://www.johnlewis.com
http://www.waitrose.com
https://www.johnlewisfinance.com
http://www.johnlewispartnership.co.uk

**********************************************************************

[Barry Pollard]

Could you confirm the conditions the trace was taken under?

Particularly if any of these setting were enabled:

(particularly keen on the ones on the left)

And whether on a mobile device or a desktop machine? And was what throttling you did it on and if it was a reasonably high-end machine (e.g. an M1 Mac or above)?

Seeing some weird gaps in the main thread where there's long, blocking tasks, but no main thread activity not network requests in action. I have seen that before when the two (slow) settings are enabled so I wonder if it's that. If so I'd suggest turning those off and profiling with just CPU throttling. The two (slow) settings are (as their name suggests!) quite slow as do a lot of extra profiling and really only are for looking at the paint and CSS selector data in isolation.

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/d0dc9d6d-f065-44fb-bef8-9cc6408d32c6n%40googlegroups.com.

[Peter Warman]

No CPU or network throttling, but the “Enable advanced paint instrumentation" box was checked. I’m running on an M2 MacBook.

I’ll try and put together a reduced test case for you.

On 18 Jun 2024, at 18:51, 'Barry Pollard' via web-vitals-feedback <web-vital...@googlegroups.com> wrote:

Could you confirm the conditions the trace was taken under?

Particularly if any of these setting were enabled:

You received this message because you are subscribed to a topic in the Google Groups "web-vitals-feedback" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web-vitals-feedback/s6yDh7teQC4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/CAH6JyLS6qV7x9%3D6uXgdZ9r_71ET5Uf7RRjZhcbQdzdzDgDYPpw%40mail.gmail.com.