Incremental Layout Shift for SPAs and CLS

[Ishan Anand]

The thread with Ilya about RUM and CLS reminded me to bring up that in our recently released RUM for Core Web Vitals we're experimenting with an alternate debugging metric we're calling Incremental Layout Shift. Here's how it's described in the interface:

Let me explain the motivation: we suspect that CLS reporting to the original page URL makes the developer's job harder. If there's an increase in CLS during a SPA transition it's likely because fetching the API data or redrawing for the destination URL (not the original) is where the issue lies. For example, suppose you're an ecommerce site SPA, and the typical workflow for the user is browsing between Home, Category, and Product pages. Let's suppose your Product page API is slower so that you exceed the 500ms to fetch the data and redraw the screen for transitions to the Product page, but Home and Category APIs are fine so those transitions are quick. Under the current CLS attribution, transitions to the problematic Product Pages would be hard to isolate b/c they'd be "randomly" attributed to whatever the original landing page the user entered the site on. By attributing the CLS to the destination URL, it's easier to isolate those transitions that are problematic.

I don't expect Google to adopt it (it could be gameable for one) but we believe it makes the developer's job easier.

Feedback and thoughts welcome.

--

Ishan Anand

Moovweb

340 Pine Street, Suite 400

San Francisco, CA 94104

Cell: +1-415-335-6094 (sms/texts are welcome)

Calendar: http://bit.ly/2jv5t0v 

[Michal Mocny]

Hi Ishan, thanks for the feedback!

On Fri, Mar 26, 2021 at 1:47 AM Ishan Anand <is...@moovweb.com> wrote:

The thread with Ilya about RUM and CLS reminded me to bring up that in our recently released RUM for Core Web Vitals we're experimenting with an alternate debugging metric we're calling Incremental Layout Shift. Here's how it's described in the interface:

I'm not sure if it's just me, but I cannot see the image.  Could you link out to it instead of embedding, perhaps?

Let me explain the motivation: we suspect that CLS reporting to the original page URL makes the developer's job harder. If there's an increase in CLS during a SPA transition it's likely because fetching the API data or redrawing for the destination URL (not the original) is where the issue lies. For example, suppose you're an ecommerce site SPA, and the typical workflow for the user is browsing between Home, Category, and Product pages. Let's suppose your Product page API is slower so that you exceed the 500ms to fetch the data and redraw the screen for transitions to the Product page, but Home and Category APIs are fine so those transitions are quick. Under the current CLS attribution, transitions to the problematic Product Pages would be hard to isolate b/c they'd be "randomly" attributed to whatever the original landing page the user entered the site on. By attributing the CLS to the destination URL, it's easier to isolate those transitions that are problematic.

This info will probably be very useful for debugging RUM data, so it seems reasonable to me.

 

I don't expect Google to adopt it (it could be gameable for one) but we believe it makes the developer's job easier.

Indeed, this is tricky.  Besides difficulty of defining SPA routing at scale, the reason why SPA transitions get the 500ms time to adjust their page structure is because unlike with an MPA hard nav, where you start with a blank canvas -- with SPA transitions it's not just the new content that is typically shifting as it loads, it's often the old content that shifts in place to make room for it.

So, while I agree with your previous paragraph that the cause of the shift was the transition to the destination URL, in practice we often see the content that actually shifts was there because of the previous, source URL.  So it's perhaps equally tricky to just always attribute to the destination URL, merged with it's hard navigation CLS scores.

That said, I'm very eager to hear more feedback on how this works out in practice.  It may well depend on the site.  It could be important to actually attribute to the transition (for transitions from A->B "Incremental LS" is X)?  Or, maybe it is fine to just merge on destination and still catch patterns in the aggregate.

 

Feedback and thoughts welcome.

Cheers. 

--

Ishan Anand

Moovweb

340 Pine Street, Suite 400

San Francisco, CA 94104

Cell: +1-415-335-6094 (sms/texts are welcome)

Calendar: http://bit.ly/2jv5t0v 

--
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/CAH5aPSCHfptXEg9_hECv3M2QSEaP2FS%2BD_-sBKnYJHCJ8H_D_A%40mail.gmail.com.