Core Web Vitals — ️A Google Initiative to measure performance ⚡

photo : sketchcorp.com

Optimizing user experience is critical to any website’s long-term success. If you’re a business owner, marketer or developer, Web Vitals will help measure your site’s experience and detect areas for improvement.

Web Vitals is Google’s project to provide precise instructions on signals critical to delivering better user experience. Over the years, Google has developed tools to quantify and report on web performance. The Web Vitals initiative by Google is an attempt to make this landscape a bit simpler for everyone and help sites focus on the most critical metric Core Web Vitals.

What are Core Web Vitals?

Core Web Vitals are a set of user-facing metrics related to speed, responsiveness and visual stability, to help site owners measure user experience while surfing on the web.

The Web Vitals metrics are split into 2 area’s essentially,

The Core Web Vitals :

• Largest Contentful Paint (LCP)
• First Input Delay (FID)
• Cumulative Layout Shift (CLS)

Non-Core Web Vitals :

• Total Blocking Time (TBT)
• First Contentful Paint (FCP)
• Speed Index (SI)
• Time to Interactive (TTI)

Each metric above measures how “good” one part of the Page Experience is. The illustration below shows how a page loads and where the different metrics come into play:

Addy Osmani’s visualization of Web Vitals on a ticker : Link

But before we go through all the Web Vitals, we first need to understand why they are important.

Why should you care about Core Web Vitals?

Here are the three main reasons you why everyone should care about Core Web Vitals:

1. Visitors love fast sites that are easy to use, on any device, from any location. The bottom line is: you’ll make more profit if you’re providing a seamless user experience.
2. As we mentioned in the introduction, Core Web Vitals have become a ranking factor as of mid-June 2021.
3. Passing the Core Web Vitals assessment is likely to result in fewer users retreating back to the SERP, because you’re providing a good user experience — and Google has hinted they may start displaying a “Good Page Experience” badge in their search results.

Core Web Vitals in depth

Without further ado, let’s dive into each of the Web Vitals metrics, starting with the Core Web Vitals!

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) is a Core Web Vital that measures the time in seconds from when the page starts loading to when the largest text block or image element is rendered on the screen.

Its aim is to measure when the page’s main contents have finished loading. The lower the LCP, the better the score. A fast LCP reassures users that a page is useful, because it’s a metric that measures perceived load speed.

Important considerations

While a page is loading, the largest text block or image element may change, and the most recent candidate is used when measuring the LCP.

For example, consider when at the start an H1 heading is the largest text block, but later on a larger image is loaded. The larger image is then the leading candidate in measuring the LCP.

photo: web.dev

As currently specified in the Largest Contentful Paint API, the types of elements considered for Largest Contentful Paint are:

• <img> elements
• <image> elements inside an <svg> element
• <video> elements (the poster image is used)
• An element with a background image loaded via the url() function (as opposed to a CSS gradient)
• Block-level elements containing text nodes or other inline-level text elements children.

Note, restricting the elements to this limited set was intentional in order to keep things simple in the beginning. Additional elements (e.g. <svg>, <video>) may be added in the future as more research is conducted.

How to interpret your LCP score

Here’s how to interpret your LCP score:

• Good: <= 2.5s (2.5 seconds or less)
• Needs improvement: > 2.5s <= 4s (between 2.5 and 4 seconds)
• Poor: > 4s (more than 4 seconds)

What could be causing a poor LCP score

There could be any behind a poor LCP score, for example slow server response times, render-blocking JavaScript and CSS, and having your largest content resources be too heavy, requiring too much time to load.

Improving your LCP score

You can do lots of things to improve your LCP score — for example optimizing your critical rendering path, CSS, and images. Won’t be going in depth of it so I highly recommend checking out web.dev’s resources on optimizing LCP scores instead.

First Input Delay (FID)

First Input Delay (FID) is a Core Web Vital that measures the time in milliseconds from when a user first interacts with your site (i.e. when they click a link, tap a button, or press a key) to when the browser is able to respond to that interaction.

This can be considered similar Total Blocking Time metric, as it closely correlates with First Input Delay.

photo : www.debugbear.com

Important considerations

The FID does not measure the time it takes the browser to process an event (e.g. a tap on a button), nor the time it takes to update the user interface after that.

Interactions such as scrolling and zooming aren’t counted as actions, because they’re continuous in nature and have very different performance constraints because the scrolling action is performed by the GPU instead of the CPU, or the CPU’s compositor thread instead of main thread.

How to interpret your FID score

• Good: <= 100ms
• Needs improvement: > 100ms and <= 300ms
• Poor: > 300ms

What could be causing a poor FID score

One common reason for a poor FID score is that a browser’s main thread is busy parsing and executing JavaScript code. When the main thread is busy, it can’t yet respond to a user’s interaction.

Improving your FID score

If you want to improve your FID score, you need to look closely at what’s keeping the browser from going interactive. Examples of things you can do to improve your FID score are:

• Reducing JavaScript execution time.
• Minimizing work done in the main thread.
• Reducing the impact of third-party code.

Describing the ins and outs of improving your FID score is beyond the scope of this article. So i would recommend checking out web.dev’s resources on optimizing FID scores.

Cumulative Layout Shift (CLS)

photo : www.ranosys.com

Cumulative Layout Shift (CLS) is a Core Web Vital that measures the cumulative score of all unexpected layout shifts within the viewport that occur during a page’s entire lifecycle.

Its aim is to measure a page’s “visual stability,” as that heavily influences the user experience. The lower the CLS score, the better the visual stability.

CLS isn’t measured in seconds like most of the other metrics. It works from the viewport size, relates to elements that move between two frames — called unstable elements — and measures their movement in the viewport.

How to interpret your CLS score

• Good: <= 0.1
• Needs improvement: > 0.1 <= 0.25
• Poor: > 0.25

What could be causing a poor CLS score

Unexpected layout shifts often happen because of images or ads with undefined dimensions, resources that are loaded asynchronously, and situations where new DOM elements are dynamically added to a page, above existing content that has already been loaded. This results in content that has already been loaded being pushed away.

Improving your CLS score

You can prevent unexpected layout shifts e.g. by always including size attributes for your images and videos and by not inserting content above other content that’s already loaded. Check out web.dev’s article on optimizing CLS scores to learn the full range of improvements you can make.

Total Blocking Time (TBT)

photo : www.debugbear.com

Total Blocking Time (TBT) is a non-Core Web Vital that measures the total time in milliseconds between First Contentful Paint (FCP) and Time To Interactive (TTI) where the main thread is blocked long enough to make it unresponsive to user input.

Any task that takes more than 50ms to execute is considered a long task, and the time on top of the 50ms is considered the “blocking time”. TBT is calculated by taking the sum of the blocking portion of all long tasks. For example, if there are three long tasks:

1. Task A takes 75ms (45ms longer than 50ms)
2. Task B takes 60ms (20ms longer than 50ms)
3. Task C takes 85ms (55ms longer than 50ms)

The TBT is then: 120ms (45+20+55). The lower the TBT, the better.

How to interpret your TBT score

• Good: <= 200ms
• Needs improvement: > 200ms <= 600ms
• Poor: > 600ms

Causes for a poor TBT score and how to improve it

The section Improving your FID score above and How to Improve your TBT score(opens in a new tab) explain in detail what causes a poor TBT score, and how to improve it.

First Contentful Paint (FCP)

photo : https://raygun.com/

First Contentful Paint (FCP) is a non-Core Web Vital that measures the time from when a page starts loading to when any part of that page’s content is rendered on the screen. Having a fast FCP reassures users that something is happening. Within this context, content means text, images (including background images), <svg> elements, and non-white <canvas> elements.

How to interpret your FCP score

• Good: <= 2.0s
• Needs improvement: > 2.0s <= 4s
• Poor: > 4s

What could be causing a poor FCP score

Common causes for a poor FCP score are high server response times and render-blocking resources.

Improving your FCP score

You can do a lot of things to improve your LCP score, for example eliminating render-blocking resources, removing unused CSS, minifying CSS, and using a CDN. Check out web.dev’s resources on optimizing FCP scores.

Speed Index (SI)

Speed Index (SI) is a non-Core Web Vital that measures how quickly the contents of a page are visually populated during page load. It’s calculated using frame-by-frame analysis of your page’s load behavior, counting the visual progression between frames captured every 100ms.

How to interpret your SI score

• Good: <= 4.4s
• Needs improvement: > 4.4s <= 5.8s
• Poor: > 5.8s

What could be causing a poor SI score

Anything preventing the page from loading quickly will hurt your SI score. Some of the causes that are mentioned for the other metrics, such as for example the main thread being blocked, apply here too.

Improving your SI score

If you focus on improving overall page load performance, you’ll see your SI score improve too. We recommend checking out web.dev’s resource on this here.

Time to Interactive (TTI)

photo : crystallize.com

Time to Interactive (TTI) is a non-Core Web Vital that measures the time from when the page starts loading to when it’s fully interactive.

For it to be fully interactive, it needs to:

1. Display useful content measured by First Contentful Paint (FCP).
2. Have most visible page elements rendered.
3. Respond to user interactions within 50 ms.

How to interpret your TTI score

• Good: <= 3.8s
• Needs improvement: > 3.8s <= 7.3s
• Poor: > 7.3s

What could be causing a poor TTI score

Similarly to the Speed Index metric above, many of the things causing poor scores in the other metrics we described apply to TTI too, because it’s a metric that encompasses those other metrics.

Improving your TTI score

Check out this web.dev article for next steps on how to improve your TTI.

Lighthouse

It is a performance analysis tool which you can find inside Google Chrome’s devtools. Lighthouse uses the following color-coded ranges to “judge” your score:

• Red (poor): 0 to 49
• Orange (needs improvement): from 50 to 89
• Green (good): from 90 to 100

Playing around with the Lighthouse Scoring Calculator, which immediately updates the score when you change the metrics.

That’s it for this article hope you would have learned something useful from it. So If you have any thoughts or suggestions, feel free to leave a comment below. Don’t forget to share your love by clapping for this article as many times you feel like.

You can follow me on Twitter , Github , LinkedIn , Facebook.

Happy Coding 👨‍💻 🎊.