[Layout Shift Metrics] Full-page apps with initialization delays

[James Diebel]

We run clippingmagic.com and vectormagic.com, which both offer full-page apps for image processing. We are getting dinged on the CLS metric despite not having any undesirable layout shifts. 

The tooling for exploring the cause of the field score is poor, so we have not been able to definitively track down the root cause (it is not on page load). But we believe it stems from when a user uploads an image (the first step in opening the full-page app). This causes a progress dialog to pop up and for the app to load once the image has been uploaded and a connection has been secured with a websocket worker. This sequence can take anywhere from a few tens of milliseconds to a few seconds, depending on the input image and the user's internet connection. From what I can read, it sounds like any layout shift beyond 500ms from a user action is considered a layout shift. But in our case, this is desirable and appropriate behavior.

• Does this sound like a correct reading of the data? 
• Are any of the plans for revising this metric likely to address this obvious issue? 
• What tools would help diagnose the cause of this mistaken score? (I have the Web Vitals Chrome plugin but it has not been helpful on this matter.)
• Is this score actually going to influence search ranking? That seems aggressive given the significant diversity of web experiences and the manifest limitations of this (or any) one-size-fits-all automated score.

Thanks!

James

[Michal Mocny]

On Mon, May 17, 2021 at 10:08 AM James Diebel <james....@gmail.com> wrote:

We run clippingmagic.com and vectormagic.com, which both offer full-page apps for image processing. We are getting dinged on the CLS metric despite not having any undesirable layout shifts. 

The tooling for exploring the cause of the field score is poor, so we have not been able to definitively track down the root cause (it is not on page load). But we believe it stems from when a user uploads an image (the first step in opening the full-page app). This causes a progress dialog to pop up and for the app to load once the image has been uploaded and a connection has been secured with a websocket worker. This sequence can take anywhere from a few tens of milliseconds to a few seconds, depending on the input image and the user's internet connection. From what I can read, it sounds like any layout shift beyond 500ms from a user action is considered a layout shift. But in our case, this is desirable and appropriate behavior.

• Does this sound like a correct reading of the data?

Your understanding is correct about the 500ms window.

I just quickly looked at those two links you sent, I see 0 CLS for loading and scrolling (great work!), and yet CLS field data is high, especially for the first link.  I was indeed able to induce shifts by uploading an image (read below).

• Are any of the plans for revising this metric likely to address this obvious issue? 

Not that I am aware of.  The 500ms window is meant to give time to prepare UI for any visual updates that may take longer, such as network usage.  A useful pattern, especially for SPA, is to use the 500ms to prepare a skeleton.  Also, are can have visual updates outside of a 500ms hadRecentInput window... just as long as it does not layout shifting of existing content.

I tried to upload an image using your tool, and indeed, I see a bunch of reported shifts happen.  Some of those shifts happen within 500ms, but many happen later.  If I throttle the network, things get worse. 

The shifts happen as your UI adjusts for the download progress view, and not after the image is done downloading.  Actually, there are no reported shifts once the download is complete that I can see.  So, I don't think it's a problem with long uploads per se, but rather it seems like it may just be taking just a bit too long to switch into your image upload view.  Indeed, I can visually see plenty of shifts over a period of a few seconds.  Also, I see the first renders of this SPA UI are not the same as subsequent renders, so if you cannot load the transition UI within 500ms, maybe you can at least delay until you have the final render?  Not sure.

(I will concede that it is debatable if the shifts here are "unexpected" by the user... but I think this is similar to cases with layout inducing animations.  Since there are avenues to address these shifts, I do think you can make improvements here which would be better for UX).

• What tools would help diagnose the cause of this mistaken score? (I have the Web Vitals Chrome plugin but it has not been helpful on this matter.)

 What I find useful are 2 strategies:

1. Use the Performance api to list individual shift data, and see the scores, attribution, etc.  web.dev/cls has a short description for how to do this, but I'll paste the snippet I used personally to look at your site, below.
2. Record a trace and visualize shifts over time alongside a video/screenshots.  You can use a tool like webpagetest.org, but since here we want to record interaction, I just used DevTools performance profiling.

{

  let total = 0, max = 0, curr = 0, firstTs = Number.NEGATIVE_INFINITY, prevTs = Number.NEGATIVE_INFINITY;

  new PerformanceObserver((entryList) => {

    for (const entry of entryList.getEntries()) {

      if (entry.hadRecentInput) {

        console.log(`[CLS + hadRecentInput]`, entry);

        continue;

      };

      if (entry.startTime - firstTs > 5000 || entry.startTime - prevTs > 1000) {

        firstTs = entry.startTime;

        curr = 0;

      }

      prevTs = entry.startTime;

      curr += entry.value;

      max = Math.max(max, curr);

      total += curr;

      console.log(`[CLS] Total: ${total}, Max: ${max}`, entry);

    }

  }).observe({type: 'layout-shift', buffered: true});

}

• Is this score actually going to influence search ranking? That seems aggressive given the significant diversity of web experiences and the manifest limitations of this (or any) one-size-fits-all automated score. 

Thanks!

James

--
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/c43fa9e2-efed-46d6-a509-cc87bbf9fb90n%40googlegroups.com.

[James Diebel]

Hi Michal,

Thanks for your fast and helpful feedback. With the help of your code snippet we identified the culprit. While the app is initializing we show some help information about how to use our app in a lightbox. After the app initializes, we minimize that help dialog using an animation that disappears toward the button where the user can access it again in the future. This is similar to how desktop application minimize toward the taskbar. We consider this to be a good thing for usability, and far superior to just hiding the dialog instantaneously.

Again, however well-intentioned the CLS effort has been, it seems poorly suited to full-page apps. Which is a shame for us. We get most of our traffic from Google organic search, so we can't afford to not have the best experience scores possible. So we'll yank the animation. But that is a loss for our users, who will now have a harder time finding the help content. 

It seems to me that Google should use page content and user-behavioral signals for search rank, but leave web and app design to the web and app designers. If your other systems work, bad designs will lead to fewer clicks and shorter time on site, and your existing behavioral-ranking methods will penalize such sites. In our case, all our CLS was coming from that one animation, which can only be described as helpful for the end user. It is a small matter and we'll just pull the offending animation, but it is hard not to resent Google for having such an authoritarian approach to this otherwise well-intentioned effort.

Best Regards,
James

[Cheney Tsai]

Hey James,

For that particular animation, what were the properties being animated? We do want to make sure that transitions/animations on the web can be handled in a performant and user-centric way. To that end, I believe the desired animation should be able to be done through a transform. There has been a couple of instances I've seen where adjusting the animation implementation was enough to avoid the shifts.

Thanks,

Cheney 

To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/147cd60a-932d-473f-ad0f-f390b61bfa7bn%40googlegroups.com.