Home > Technical SEO > Google’s Core Web Vitals – Explained

Google’s Core Web Vitals – Explained

Reading Time: 10 minutes

There’s been a lot of talk about Google Core Web Vitals metrics. The value of these metrics is now more critical than ever. Google has now revealed that it will be considered as a ranking signal, which will be integrated into its newest algorithm. This means that the Core Web Vital metrics for your website will play a significant role in its rankings. So buckle up, we are going to cover everything you need to know about Google’s Core Web Vital metrics.

What are Core Web Vitals?

Core Web Vitals help Google understand how well a website is optimised for user experience. Note that these metrics are continuous evolving.  For the year 2020, the chosen set of metrics are Largest Contentful Paint (LCP), First Input Delay (FID) and Cumulative Layout Shift (CLS). These metrics measure three of the most important aspects of user experience

  1. How fast a page loads 
  2. How quickly the user can interact with the page
  3. How fast the website attains visual stability

Tools to measure Core Web Vitals

Here are some tools that can help measure Core Web Vitals

  1. Google Search Console (You can find it under Enhancements-> Core Web Vitals)
  2. PageSpeed Insights
  3. Lighthouse
  4. WebPageTest
  5. Chrome DevTools (which can be accessed by first opening the Web page and then pressing Control+Shift+C (Windows) or Command+Option+C (Mac)). 
  6. Chrome User Experience Report

You can refer to the article on how to measure Core Web Vitals for more information.

Largest Contentful Paint (LCP)

What is LCP?

LCP indicates the time taken for the server to render the largest visible element in the viewport. This visible element could be an image or a text block. In simple terms, LCP is the time taken to load the largest content (text or image) on the page. For the best user experience, Google recommends that your LCP should be less than 2.5 seconds.

Largest Contentful Paint (LCP)

Steps to improve LCP 

The first step is to identify the pages on the website that need improvement in LCP. You can use the tools already discussed to help you with this. 

There are four factors that determine/affect your LCP

  1. Render Blocking Javascript (JS) and Cascading Style Sheets (CSS)
  2. Slow server response times
  3. Resource load time
  4. Client-side rendering

Let’s take a closer look at each of these factors and examine how you can optimize them.

  • Render blocking JS and CSS

Scripts (.js) and stylesheets (.css) are the main culprits that can significantly delay LCP. You need to carefully determine which .js and .css are critical and which can be deferred during your initial page load time.

Here are some things you can do to make sure your LCP doesn’t get bogged down by your scripts and stylesheets:

Minify the CSS

The CSS can contain some unnecessary characters, including indentations, extra spaces or comments. You can minify the CSS, which will remove any such extra characters. This will help ensure that the browser does not waste time rendering these unnecessary characters during the initial page load. This, in turn, will help improve LCP.

Defer or in-line CSS

Carefully scrutinise the CSS elements. If there are certain unused non-critical CSS on your Web page, make sure that you defer them. You can find such unused CSS by visiting your page and pressing Control+Shift+I. This will open Chrome DevTools. Closely observe the “Coverage” tab and locate “Unused Bytes”.

Coverage - Unused Bytes

Deferring these style sheets (CSS) during initial page load will help improve your LCP.

Also, identify the CSS that are very critical and used during page load time. Make sure that you in-line these CSS elements. This will ensure that the browser does not have to render your entire code to find the useful CSS. A good practice would be to add these critical CSS elements in the <head> section of your page. 

CSS Elements

Reduce JavaScript blocking time

Javascript plays a very important role in page speed. Make sure you are only delivering critical Javascript files to your users. Any unnecessary Javascript code needs to be completely discarded. You can also compress the Javascript to remove unnecessary spaces and indentations. You can also use defer and in-line techniques mentioned above to segregate critical Javascript files.

  • Slow server response time

Server response time is very critical and can dictate the overall page speed. If the server takes longer to respond to the browser requests, it will take longer for it to display the content to the user. This can significantly impact LCP. 

Make sure your browser is quick to respond to requests and delivers the content as quick as possible. You can also make use of Caching techniques in which the important elements are stored on the server-side when a user visits a website. This reduces the load on the server.

  • Resource load time

If the CSS and Javascript are properly optimised, you may want to take a look at other resources that slow your website. These resources could be <img>, <image>, <video? or even HTML text files. Look out for resources that take more time than usual during the initial page load. 

In the case of images, a good practice is to compress them and make sure they are under 100 kb. You can also use the Gzip tool to compress text files as well. A very useful technique is using the <link rel=”preload”> function to prioritise the resources are important and should be loaded first. This will help ensure that your memory-hungry resources do not affect your First Contentful Paint (FCP).

Here’s an example of implementing <link rel=”preload”> function:

Link rel preload function

You can choose whether you want to preload a .js,.css or image file.

  • Client-side rendering

Many site owners now use client-side rendering Javascript technique on their websites. Using client-side rendering, you can render the entire page directly on the user-end (browser). This is possible due to various frameworks such as Angular, React and VUE and their extensive libraries. However, if not done right, client-side rendering can severely impact LCP. In such cases, Google recommends to either opt for pre-rendering or server-side rendering. You can read more about SSR and CSR here.

First Input Delay (FID)

What is FID?

FID indicates the delay that occurs when a user performs an action on the Web page and when the browser actually processes the request. The action could be anything. For example, the user clicks a button, clicks a link or interacts with the navigation bar. The time it takes for the page to respond to that particular action is the FID.  In order to provide the best user experience, Google recommends that your FID should be less than 100 ms

First Input Delay (FID)

Steps to improve FID 

Your website should be coded in such a way that it responds almost instantaneously to user events. You may end up with a scenario where the user clicked on an element while the page was loading, and the event wasn’t registered at all. This will leave the user frustrated. This is an example of FID.

Here are some techniques that can help you minimise FID:

  1. Reduce JavaScript execution time
  2. Minimise main thread work
  3. Reduce the impact of third-party code

Let’s discuss each of these techniques in detail.

  • Reduce JavaScript execution time

If your Javascript file takes significantly longer to load, this can hamper your page load time. This has a very bad effect on your FID.

Your first step should be to identify such Javascript that takes ages to load. You can either use Pagespeed Insights or Lighthouse tool to find such JS files. Run your page through these tools. You will find a report of all your Javascript files and their respective execution time.

Reduce JavaScript Execution Time

The Lighthouse tool recommends that your JS execution time should be less than 3.5 s

  • Minimize main thread work

The main thread of your website plays the most crucial role as it performs all code processing. It builds DOM, parses HTML, CSS, and style sheets, and manages the JavaScript. It also handles user events and inputs. 

Make sure that the load on the main thread is not too much as this can result in failed events. If the main thread is busy handling other tasks, it may completely ignore user input. This, in turn, will result in a longer FID and can also fail in some instances.

Lighthouse and Pagespeed Insights give you details of the events that your main-thread work handles during page load. 

Minimize Main Thread Work

Look for opportunities to minimise the load on the main-thread which will help improve FID.

  • Reduce the impact of third-party code

If you want to add a heatmap tool, social media tracking, perform A/B testing or measure analytics, you need to put a small piece of code on your page. This third-party script can interfere with your main thread and result in slower page load times. 

In some cases, these third-party scripts also take over the critical code of your website in terms of priority. They demand to be loaded before the critical code and take up the resources of the main-thread work. This hampers page load time and results in larger FID. 

Pagespeed Insights and Lighthouse tool help you identify such third-party scripts.

Reduce the Impact of Third-Party Code

Lighthouse reports third-party scripts that take up more than 250 ms of your main-thread work. You can use Web worker which will ensure that your third party scripts run in the background rather than hogging on your main thread work.

Cumulative Layout Shift (CLS)

What is CLS?

CLS happens when the elements of a Web page unexpectedly shift from one position to another when the page is loading. These elements shift because of certain fonts, images, videos, button or any other styles that don’t load quickly enough. This can hamper user experience drastically. Imagine clicking on a button, and when the page loads completely, the button unexpectedly disappears and moves to the bottom. CLS in large numbers can be very frustrating. For the best user experience, Google recommends that your CLS score should be less than 0.1

Cumulative Layout Shift (CLS)

Steps to improve CLS

Google gives a lot of importance to content and how interactive it is with the user. If the user fails to interact with the content on your website, it will demonstrate how insecure your content and elements are. For this very reason, CLS has been included in the Core Web Vitals for SEO.

Google believes that CLS can occur due to the following reasons

  1. Web fonts causing FOIT/FOUT
  2. Images without dimensions
  3. Dynamic content
  4. Embeds and iframes without dimensions

Let’s discuss each of these scenarios in detail.

  • Web fonts causing Flash of invisible text (FOIT) and Flash of Unstyled Text (FOUT)

Some websites make use of Web fonts for their pages. It all works great if the fonts are loaded on time and are displayed to the user. But, if your page speed is slow, these Web fonts lead to FOIT/FOUT. 

  1. In FOUT, until the original Web font is not fully loaded, it is swapped with a new temporary font. This new font is called FOIT. 
  2. And, FOIT is the new temporary invisible text that is displayed until the font is fully loaded. This “invisible” text is called FOUT.

Google recommends using the <link rel=preload> attribute on your page. Using rel=preload, you can preload important Web fonts. In this way, the original font will be replaced by the temporary font and text during the first paint itself. This will result in no layout shift.

  • Images without dimensions

Sometimes images are declared in the website code without the height and width attributes. This is the biggest culprit for CLS since the browser doesn’t know how much space to allocate to images. It gives the space to another element, and when the page is completely loaded, the element will be relocated again.

Google recommends using aspect ratio boxes to solve this problem. Using aspect ratio boxes, you can define the aspect ratio that your image will take, and the browser will allocate the space appropriately.

Even if you are using responsive Web design, Google still recommends using “srcset” to define the height and width attributes of the images.

  • Dynamic content

Dynamically generated content affects CLS. Dynamic content (aka adaptive content) is when content is changed in real-time depending on user interactions, interests and behaviour. For example, if you open an e-commerce site and click a product, suddenly a dynamic content/banner will appear notifying you that the product is going out of stock. Another example would be when you scroll down and suddenly the static content transforms into a dynamic widget, gif or video. 

Dynamic content is good for user interactivity but can have adverse effects on CLS if not done properly. It results in a lot of layout shifts, as the content keeps changing. 

If you would like to include such dynamic content, Google’s advice is to reserve sufficient space for them in the viewport. You can use placeholders to tell the browser that some dynamic content is coming and to reserve space for the same. This will result in lesser layout shifts.

  • Embeds and iframes without dimensions

Embeds and iframes are commonly used in websites to display audio, video or text widgets. These embeds could be videos from YouTube, an audio podcast, maps or a social media post on the page. These embeds are mostly inserted using HTML snippets, JavaScript or iframes. 

The problem here is that the browser knows that it needs to allocate space for an embed, but it doesn’t know its size. The embedded content could be just one line of text, or it could be 4-5 social media posts. In most instances, the browser ends up allocating less space for the embed. When the embedded content loads fully, the space increases, which leads to layout shifts.

Google recommends that you minimize CLS by allocating sufficient space for embeds along with a placeholder. Try to measure the height of the embedded content and allocate space accordingly.

Conclusion

To wrap up, Google’s Core Web Vitals is the next big thing in town. By the end of 2020, these Core Web Vitals will be deeply integrated into Google’s algorithms as a ranking signal. As a pre-emptive measure, we need to start focusing on website speed optimization in much more detail.

If you are a company providing SEO services, it would be a good idea to start tracking the Core Web Vital metrics of your clients and to include them in your reports. If you are a site owner, this means that you start focusing on the speed of your page and strive to provide the best possible user experience. The Core Web Vitals can help you measure how effective your speed optimization is.

Let us know in the comments section below what are your thoughts on Google’s Core Web Vitals – LCP, FID and CLS.

Popular Searches

SEO Company in Australia  |  Digital Marketing Services in Australia  |  Ecommerce SEO Services  |  Website Audit Services  |  Google Penalty Recovery Services in Australia  |  Local SEO Company  |  PPC Services in Australia  |  ASO Services in Australia  |  Content Marketing Company  |  SEO Agency in Australia  |  SEO Sydney  |  SEO Consultants Australia  |  SEO Company Melbourne  |  Perth SEO Services  |  SEO Company Brisbane  |  Google Reverse Image Search  |  What is Digital Marketing  |  How to do Local SEO  |  Google Tag Manager  |  What is SEO

Leave a Comment

Related Posts