Understanding Lighthouse Performance Metrics – Part 4

This is the last part of the series on understanding metrics that contribute to the Performance audit on Lighthouse. In the previous part, I discussed about the two metrics – Speed Index and Total Blocking Time (TBT).

In the first part, I wrote about what lighthouse is and how the scoring is done, while the second part deals with the first two metrics – First Contentful Paint (FCP) and Large Contentful Paint (LCP)

In this blog, I’ll write about the last metric – the Cumulative Layout Shift and will also mention what weightage does each metric carry when calculating the metrics score.

Cumulative Layout Shift (CLS)

All of us must have had this experience once in a while when interacting with web pages – particularly on a mobile screen.

You want to interact with a page element – let’s say a button , which enables you to login into the website or may be make a payment. But even before you can click on that button, the position of the button changes – it shifts its position. Or may be even worse, it completely goes off screen viewport and you end up clicking on something else, when you should be clicking on that damn button.

This is a pretty annoying user experience and that is why these shifts are also included while measuring the performance metrics in Lighthouse. But the questions arises – what are these layout shifts and are all of these shifts bad?

Layout Shifts

In order to understand CLS, it’s imperative to first understand what layout shifts are. As per the Layout Instability API, every time an element that is visible in the browser viewport changes its start position for example, its top and left position in the default writing mode), between two frames, then this API reports layout-shift entries.

Layout shifts are defined only for elements that are pre-existing on the screen- if they change their existing positions.  If a new element is added to the DOM or an existing element changes size, it doesn’t count as a layout shift—as long as the change doesn’t cause other visible elements to change their start position.

Why Do Layout Shifts Occur?

Now that we understand what layout shifts are, we have the questions – why? Why do Layout shifts occur? And the answer is quite simple. If there is an unexpected occurrence of an element on the webpage, then definitely the other elements will be impacted.

In modern day applications with frameworks like React,Angular, Vue , resources are loaded asynchronously or DOM elements get dynamically added to the page above existing content. If this async addition/deletion of elements is unexpected, then this might become the cause of a layout shift.

Now this shift in the elements on the page is what layout shift is all about and CLS is the measure of that. But are all layout shifts bad?

Are all Layout Shifts Bad?

No. A layout shift on the webpage elements might occur due to various reasons and all of them cannot be counted as bad layout shifts.A layout shift is considered bad only if it is unexpected and user doesn’t expects it.

Consider a simple user interaction – a user searches for a specific keyword in the search bar. And this triggers a network request. So in order to have a pleasant experience, create some space right away and show a loading indicator to avoid an unpleasant layout shift when the request completes. This is an example of a user interaction caused layout shift that cannot be counted as a bad layout shift.

However, if there is no loading indicator, then the user doesn’t realize something is loading, or doesn’t have a sense of when the resource will be ready, then they may try to click something else while waiting, which might cause a layout shift, that is a bad layout shift.

Also, animations and transitions may also cause layout shifts. However, if done gracefully, they are a great way to update content on the page without surprising the user. If the animation causes the layout to gradually and smoothly move from one position to another, then that would be a pleasant experience. But in case, this is sudden and abrupt, this may cause a bad layout shift, which might not be a good user experience.

So what is CLS?

Now that we’ve a bit of idea about Layout shifts, let’s see what Cumulative Layout Score (CLS) is all about.

CLS is a measure of the largest burst of layout shift scores for every unexpected or bad layout shift that occurs during the entire lifespan of a page.

A burst of layout shifts, known as a session window, is when one or more individual layout shifts occur in rapid succession with less than 1-second in between each shift and a maximum of 5 seconds for the total window duration.

The largest burst is the session window with the maximum cumulative score of all layout shifts within that window. This maximum cumulative score is the Cumulative Layout Score (CLS).

CLS is measured in pixels, and a lower score is better. A good CLS score is typically below 0.1. There is a detailed section on how the layout scoring is done here.

What is a good CLS score?

As mentioned above, the ideal CLS score for a good user experience should be below 0.1. How to ensure this? Check that you’re hitting this target for most of your users, a good threshold to measure is the 75th percentile of page loads

Why is CLS Important?

As you can read above, CLS is directly related to how stable a webpage is. If your CLS score is on the higher side, then that would mean an unstable page, which would provide a bad user experience to the end user. An unstable webpage would make it pretty difficult for user to correct interact with it , resulting in a loss of user pass and potential business.

Weightage of each metric

Now that we have seen and discussed about the 5 performance metrics, do they carry equal weight or is some metric more important that the other.

As of the Lighthouse version 10, this the weightage chart for all performance metrics

Metrics	Weightage ( in %)
First Contentful Paint (FCP)	10
Speed Index	10
Large Contentful Paint (LCP)	25
Total Blocking Time	30
Cumulative Layout Shift	25

So as you can see, couple of metrics have a higher weightage than others- but this doesn’t mean you should ignore the less weightage metric.

This brings to the end of this series. A highly knowledgeable series I would say. I’d say I had real fun while researching, reading and writing this blog since I got to know a lot more about how the various components of the page come together to provide a nice UX for the user. Got to know a lot more concepts that would be helpful in UX testing for me, and I hope anyone who reads this series gains some knowledge about the lighthouse metrics and UX for this series.