Start a Project

Client Login

menu menu

All Categories

Digital Marketing, SEO

Another Shake-Up in the SEO Industry: Core Web Vitals and Why They Matter

16 Jun 2021

Mike Patel

Another Shake-Up in the SEO Industry: Core Web Vitals and Why They Matter

Core Web Vitals: Page Speed is Now More Significant for SEO

Search engine optimization (SEO) is the process by which a website is changed to fit the mold of what search engines consider “good.” Better websites rank higher on search engine results pages, leading to more web traffic and more business for companies with well-optimized websites.

Search engines, Google lead among them, consider a wide range of factors when determining where a website should rank in the search results.

The goal behind the algorithms the search engines use to make these decisions is to mimic what a human searcher would look for in a result. That’s good news for companies trying to optimize their websites. It means that, with a few minor tweaks to the way they format things, they can design their sites with their audience in mind, and their page rank should benefit.

Keywords, links, mobile-friendliness, structured data, and the quality of the content on a site all play into its page rank. Beginning this month, Google is shifting its algorithm to include three more key factors.

These are your Core Web Vitals. Considering them as a ranking signal is one of the most significant changes Google has made to their algorithm in recent years, so understanding them is critical to your company’s continued success.

Google is adding Core Web Vitals to its search ranking criteria. The “page experience update” is rolling out beginning in mid-June 2021. With the release delayed because of COVID-19 considerations, Google first announced the update last year to provide advanced warning of the coming changes. The company announced a general launch time frame of May 2021 late last year to give business owners and website administrators ample time to improve their sites.

In April, Google gave another time frame update in a blog post on Google Search Central. The update is officially launching gradually from mid-June to late August 2021, giving website owners additional time to prepare.

This update has been a long time coming, as Google has been integrating page speed factors into its ranking algorithms, or at least talking about it, since 2010. The page experience update is the latest push toward user experience-focused metrics, where Google’s metrics were previously limited to technical aspects.

Page experience includes not only how well a website works on the back end but also how it feels to use it. The primary focus of this update is the inclusion of Core Web Vitals.

What Are the Core Web Vitals?

The first thing you need to know is what, exactly, the Core Web Vitals are. Google considers them part of a user’s page experience. As their name suggests, they’re a little like the vital signs medical personnel measure in a person’s body.

The Core Web Vitals, as Google outlined them back in 2020, are a set of new metrics that it is introducing in the page experience update. The current three Core Web Vitals focus on user experience with regard to loading, interactivity, and visual stability.

By monitoring a website’s Core Web Vitals, the site owner should be able to better understand their users’ experience on their site. Google is making these metrics viewable across all its page experience measurement tools throughout the update.

Google is also introducing more expanded Web Vitals metrics based on thorough research into how to gauge and quantify the user experience. The Core Web Vitals are, as their name suggests, the most key Web Vitals for understanding page experience.

The Core Web Vitals measure not only page and element loading speed but also how fast or slow the page reacts to interaction from the user and the page’s visual stability. That is to say, does the page register and react to clicks, and will those be misclicks due to elements lurching around on the screen at the last second?

Google may add metrics to the Core Web Vitals in the future, especially as its research into quantifying user experience continues to progress. The current set of Core Web Vitals mostly measure experience on page load, specifically how fast and how smooth that load is. The three new metrics that measure loading, interactivity, and visual stability are known as LCP, FID, and CLS, respectively.

You can think of them as indicators of your website’s health and ability to function as intended. They are:

– Largest Contentful Paint.

– First Input Delay.

– Cumulative Layout Shift.

It’s entirely likely that the Core Web Vitals will shift as the typical user’s online experience changes with technological advancements. However, these are what matter right now in 2021.

Core Web Vitals as Ranking Signals

We will delve a little deeper into how, exactly, the Core Web Vitals function as ranking signals.

Initially, Google meant the algorithm change to start rolling out in May of 2021. Now, you can expect to see changes starting in the middle of June, finishing up toward the end of August.

The delayed roll-out has given site owners more time to adjust, and its gradual nature means bugs and glitches can be caught and addressed before they cause significant issues.

You probably won’t notice drastic changes in your site’s ranking, which will come as a relief to many of our readers, particularly those who remember the so-called Mobilegeddon update from back in 2015.

The Core Web Vitals are just a part of what makes up the total page experience score, and page experience is just one of many contributing factors.

A side note: why do we care so much about what Google is doing? The answer to that question comes in the form of a percentage. Google holds 92.18 percent of the search engine market share. It dominates the industry. Where Google goes, other search engines like Bing, Yahoo, and Baidu will follow.

Why Should You Care About Core Web Vitals?

Now that you know all about the Core Web Vitals metrics, you may be wondering how Google’s page experience update will affect you.

Changes to the way Google ranks its search results are a big deal for website owners. The page experience update incentivizes website owners to improve the page loading experience for their users. Significant changes like this can mean major redesigns, and that costs money.

The page experience update may not cause big problems for your website, especially if it’s well designed. However, now is a good time to review how you approach user experience. If the page loading experience wasn’t a priority, this update could push your website down in search results.

It is a good idea to take a look at and try to improve your Core Web Vitals during the transition period to maintain or even boost your standings. Having good Core Web Vitals might be the leg up your site needs to outpace your competition.

What Does the Future Hold?

Part of what makes the SEO industry so exciting and dynamic to work in is that we don’t know what’s going to happen next. Between Google and our competitors, we’re usually kept on our toes.

The first thing we want to say is that you shouldn’t panic if you haven’t started optimizing your Core Web Vitals. You still have time to begin doing so, and it’s not the only thing search engines will judge your site on.

Next, you should know that, despite the general lack of predictability in the industry, there are some things you can expect to see as the update rolls out and new changes occur.

Google’s goal in creating and updating its page ranking algorithm is to mimic what it believes human searchers would do if they had the processing power to crawl millions of websites. If you’re doing your best to ensure your website is useful and user-friendly, the algorithms will likely view you favorably.

As this algorithm change takes effect, it may turn out that other performance metrics would be helpful to use. If that’s the case, and we suspect it will be, Google will add more metrics. The infrastructure for monitoring and analyzing them will follow.

Core Web Vitals in Detail: Technical Details about LCP, FID, and CLS

The way Google measures aspects of website performance is important to understand to optimize your site and improve your metrics. Now more than ever, this is a worthwhile endeavor for administrators as Google introduces the application of page experience metrics to its ranking algorithms.

Image Source: developers.google.com

LCP (Largest Contentful Paint)

The first metric we will look at is LCP. LCP is an acronym for Largest Contentful Paint. This is going to be your loading speed metric.

In the past, web developers have struggled to measure how fast page content loads and becomes visible to the user. The metrics to come closest to reaching this goal are FMP, or First Meaningful Paint, and SI, or Speed Index.

Where other user-focused metrics such as FCP, or First Contentful Paint, were able to measure the first part of the users’ loading experience, FMP and SI were at least able to go a bit farther. However, they tend to be complicated to learn. And most importantly, these metrics frequently return incorrect results.

Now, the closest we can get to measuring the loading experience is LCP. LCP measures the time it takes for the page to render the largest element that is viewable to the user, from the initial load start time.

How LCP Works

Google scores the LCP metric on a scale with three sections: good, needs improvement, and poor. The threshold between good and needs improvement is 2.5 seconds, and 4.0 seconds between needs improvement and poor. So, the goal is for a website to load the largest element in under 2.5 seconds from when it started loading.

The LCP currently takes into account the following types of elements:

– <img>

– <image> inside <svg>

– <video>

– Elements that include background images loaded with url()

– Blocks with text nodes or inline text elements children

The LCP may also consider additional elements such as <svg> and <video> in future pending further research.

The size of an element for LCP reporting depends on the type of element. Generally, size is determined based on the amount of the element that is visible to the user, fewer additional parts added through CSS. Any excess, non-visible parts of the element aren’t counted.

For an element to be considered as a candidate for the largest element in an LCP report, it must appear within the viewport at first render and only its initial size will be used. For example, an element that renders within the viewport at first but ends up outside of it will be counted. An element that renders outside the viewport but ends up inside will not.

However, the largest element can change as the page loads because pages usually load in a series of stages. To report the most accurate LCP, browsers send out a largest-contentful-paint PerformanceEntry every time a larger element loads than the previous largest element. The browser stops sending PerformanceEntry dispatches when the user interacts with the page.

How to Optimize for a Better LCP Score

Several issues can cause a page’s LCP to be subpar. Here are the four most common issues and how to improve them:

1) Client-side Rendering

A lot of websites render in-browser rather than through the server using client-side JavaScript logic. If the client has to load a large JavaScript bundle without sufficient optimizations in place, it can cause a poor LCP.

The first optimization option is to use a smaller JavaScript bundle by minimizing the amount of critical JavaScript. Minifying or deferring unused JavaScript or minimizing unused polyfills can help.

Using a blend of server-side and client-side rendering is your second option. This solution can get complex and cause problems with server response times and the time it takes for the page to become interactive to the user.

Developers can also use pre-rendering. Implementing pre-rendering as optimization can improve LCP without tanking server response times. However, Time to Interactive, or TTI, still suffers.

2) Render-blocking scripts

CSS and JavaScript can block rendering and therefore delay FCP and LCP. Minimizing JavaScript just like the first optimization for client-side rendering can help speed up rendering time. Developers can also minimize CSS to improve LCP by minifying and deferring non-critical CSS, or including critical CSS within <head>.

3) Slow server response times

If the server is sluggish when sending content to the browser, rendering and therefore LCP suffers. By measuring server response time with TTFB, or Time to First Byte, developers can determine if this issue is contributing to poor LCP.

To improve server response time, developers can employ the following methods:

– Making third-party connections early

– Caching assets

– Using signed exchanges

– Routing to a Content Delivery Network

– Serving HTML pages cache-first

– Optimizing the server

4) Slow resource load times

In addition to render-blocking scripts, certain resource types may also slow down LCP. These resource types are the same that are reported for LCP: <img>, <svg> <image> </svg>, <video>, url() loaded background images, and text blocks. Obviously, a page’s LCP will suffer if the elements counted in that metric are slow to render.

To improve resource load times, developers can employ the following methods:

– Caching assets via a service worker

– Compressing text files

– Preloading important resources

– Implementing adaptive serving

– Optimizing and compressing images

FID (First Input Delay)

First Input Delay, also known as FID, is the metric that measures the delay between user interaction and the page’s response. Essentially, FID measures how interactive and responsive a website appears to the user at first load.

During the web page’s loading process, as previously discussed, some elements may appear before others. As soon as there is an FCP, users may begin trying to scroll, click, tap or otherwise interact with the page. Whether the elements they’re trying to interact with move at the last second is measured with the next Core Web Vital, CLS.

But when the user successfully interacts with the page, the timer for FID starts. It ends when the page gets that signal before the page begins processing the interaction and what to do about it. When nothing seems to happen after, say, clicking on a link on the page, it can cause a poor user experience.

So, it’s best to have a minimal FID score.

How FID Works

Google measures FID using another three-part scale from good to poor. A good score is an FID under 100 milliseconds, while a poor FID is over 300 milliseconds. That’s an extremely thin margin, especially since anything measured in milliseconds is considered very fast in most contexts.

As previously mentioned, FID is the measure of latency between input and browser acknowledgment. Input latency occurs when there is a user interaction while the main thread of the browser is busy. The browser may be trying to load and process CSS or JavaScript files and, as a result, it will be unable to do anything else.

The periods where the main thread is busy working on a task are what create input latency. Response times are therefore directly affected by the processing time of tasks. The more complex the task, the longer the latency if input occurs while the main thread is busy.

FID can be measured even when interactions don’t require event listeners as long as running the task requires the main thread to be idle. HTML elements such as text fields, checkboxes, radio buttons, dropdowns, and links are all interactives that don’t need event listeners, for example. These elements also commonly appear first when a page is loading, so a user may try to click on them.

FID also only measures the first input, as the name suggests. So, FID is closely related to the page loading experience as most interactions occur upon page load. A long FID is an indicator of a web page that is poorly optimized and has a lot of busy time while loading.

It should also be noted that FID doesn’t count scrolling or zooming interactions as they are continuous. Scrolling delay is still annoying for users, but it has different constraints than clicking or tapping, which are discrete actions.

How to Optimize for Less FID

The primary cause of long FID is overly complex JavaScript execution. Optimizing JavaScript execution results in a less busy time for the browser’s main thread, and thus less opportunity for long FID. Developers can improve JavaScript processing time by implementing the following techniques:

1) Minimizing script usage

This solution simply calls for reducing the amount of JavaScript a page has to work on. Therefore, the page can become responsive in less time. To accomplish this, minimize unused polyfills and defer unused Javascript.

2) Using web workers

Rather than have the browser executing JavaScript on the main thread and causing backups, web workers allow the browser to run JavaScript in the background. This option is a little more development-heavy, but freeing up the main thread by performing non-UI operations on a worker thread should improve FID.

3) Optimizing the page for interactivity

If a page relies on JavaScript for much of its operations, FID can be improved by optimizing first-party script execution, third-party script execution, and data fetching. Because FID can only be tested in the field, developers can use TTI and Total Blocking Time to measure responsiveness as a proxy for FID.

4) Breaking up extensive tasks

If reducing the amount of JavaScript isn’t an option or hasn’t reduced FID, developers can break long tasks up into asynchronous tasks. To determine what code might be splittable, look for tasks that take longer than 50 milliseconds, which are considered Long Tasks. The less time the browser has to spend on individual tasks, the better the potential FID.

CLS (Cumulative Layout Shift)

Finally, CLS is a metric that measures layout shift scores and reports the largest burst across the pages’ lifespan. When visible elements move between rendered frames, this is known as a layout shift. A layout shift burst, or session window, is one or more layout shifts within 5 seconds of each other.

CLS essentially measures unexpected shifting on a page as it loads progressively more elements. A large CLS can negatively affect user experience because users may have already begun interacting or engaging with the content on the page. The most obvious situation in which a page has a CLS problem is when a user clicks on something on the page and accidentally clicks something else due to a layout shift.

Poor CLS is most associated with invasive advertising and sketchy websites. At best it can be annoying to accidentally click off to another page. At worst, the user ends up with malware or an inadvertent purchase. Especially bad layout shift incidents can make the user feel like the website is actively trying to trick them into clicking on ads.

How CLS Works

Google measures CLS using the same three-part scale, with good being a CLS score of less than 0.1 and poor being more than 0.25. A page’s CLS is based on layout shift scores over each session window, based on the Layout Instability API. Elements that shift position are known as unstable elements.

The layout shift score is determined by the following equation:

– layout shift score = impact fraction * distance fraction

The impact fraction is a measurement of the combined area of the viewport from the original element position to its new position between two frames. The percentage of the total area of the viewpoint affected by the shift is the variable for the impact fraction

The distance fraction is a measurement of the distance the unstable element moves between two frames. The percentage change in position within this area is the variable for the distance fraction.

It is important to note that elements that don’t move from their initial position, and elements that appear during loading, aren’t considered unstable elements. Only elements that move from their initial position are considered unstable. This is the case even if a new element popping in is what causes another element to shift.

The layout shift score also only takes into account changes in the visible area. For elements that shift or get shifted out of view, partially, or fully, the amount of the element that is no longer visible is not counted in the score equation.

Layout shifts occurring as a result of discrete input from the user, within 500 milliseconds of that input, are flagged with hadRecentInput. Shifts with this flag are also not counted in the score equation. Changes due to the use of the transform property in CSS are also not counted as layout shifts.

How to Optimize for Lower CLS Scores

Poor CLS is perhaps the most glaring user experience problem among the Core Web Vitals. The results on the users’ end can also be particularly problematic if the site includes harmful elements for whatever reason. Here are four of the most common issues that result in a bad CLS score and how to fix them:

1) Elements without dimensions

Inserting elements without specifying dimensions is one of the most common causes of poor CLS scores. Images, iframes, embeds, and ads can all have this problem. Without including dimensions in the code or only in CSS, these elements can pop in unexpectedly and cause layout shifts.

To optimize against layout shift issues, simply building in room for these elements is all it takes to avoid a poor CLS score. Developers should specify width and height size attributes or use CSS aspect ratio boxes for each element of this type. This way, the browser will allot room for the elements ahead of time and avoid unexpected layout shifting.

2) Dynamically injected content

Dynamic UI is another common culprit of layout shift. To avoid this problem, simply refrain from inserting this type of content above the main content. Developers can also reserve space for dynamic content with skeleton UI or placeholders.

3) Flashes of unstyled or invisible text from using web fonts

Non-standard fonts can cause layout shifting problems as the browser loads them. The browser inserts the text-only first, either unstyled or invisible, then retrieves and renders the font.

To solve this issue, developers can use tools such as Font Loading API and preload optional fonts with various coding methods.

4) Animations

The way developers implement animations and other actions can cause layout shifts. Simply using transform animations instead of others that are prone to this problem will help improve CLS.

What Tools Can Help You Measure Your Core Web Vitals?

The first step to improving your Core Web Vitals, should that prove to be necessary, is to measure them. There are plenty of tools available, and more are likely to appear as the update rolls out and we learn more about it.

Field Data vs. Lab Data

Before we start looking at tools, we need to look at the data they use. For Core Web Vitals, there are two types of data that matter: field and lab.

Field data is the primary data type that you will work with. When we say field data, we’re referring to data that is collected from real users. It tends to be the most accurate reflection of where your site stands because you can see how your site and its users interact. You might see field data collection called real user monitoring (RUM).

Lab data, on the other hand, is data collected in a laboratory setting. There aren’t vials or beakers involved, but the principle is the same. Lab data is helpful because it tells you how your site should behave without any additional variables complicating matters. It’s useful when you need to identify problems or ensure something is bug-free before giving customers access to it.

Resource: Chrome User Experience Report

The Chrome User Experience Report is an invaluable resource. It’s what powers the Search Console’s Core Web Vitals Report and PageSpeed Insights, which we’ll discuss next.

Google Chrome collects data from its users, anonymizes it, and uses that information to assess each of the Core Web Vitals. It’s a method of field data collection.

The Chrome User Experience Report has some drawbacks as far as sources of information go. Data is only collected from Chrome users who have opted in and enabled usage statistic reporting. There may be differences between the browsing habits of the population that meet these criteria and the population that doesn’t.

Right now, the Chrome User Experience Report looks at the following web vitals, including the Core Web Vitals we’re discussing:

– First Paint.

– First Contentful Paint.

– DOMContentLoaded.

– Onload.

– Time to First Byte.

– Notification Permissions.

– First Input Delay.

– Largest Contentful Paint.

– Cumulative Layout Shift.

Right now, the Chrome User Experience Report focuses primarily on how well web pages load. In the future, it will probably expand to encompass other metrics.

You might see the Chrome User Experience Report referred to as the crUX report, so keep that in mind while you’re researching this algorithm change or any related topics.

Tool: PageSpeed Insights

PageSpeed Insights is one of the tools that gets its data from the Chrome User Experience Report. It’s easy to use. You simply enter the URL of the website you wish to analyze, and it will provide a brief report for both your mobile and desktop page.

Check the results of both because they might vary between the mobile and desktop versions of your webpage.

After you run the URL of your choice, PageSpeed Insights will give you a breakdown of how your webpage performed over six categories:

– First Contentful Paint.

– Speed Index.

– Largest Contentful Paint.

– Time to Interactive.

– Total Blocking Time.

– Cumulative Layout Shift.

At the time this article was written, but LCP and CLS were tagged with a link to a site explaining more about them.

You will notice that FID doesn’t make this list. If you’re using lab data, it can’t. You don’t have a user present to interact with the site. Use Total Blocking Time as a stand-in instead.

Each of the six categories is given a rating: good, needs improvement, or poor. A green circle indicates a good rating, a needs improvement rating is indicated by an orange square, and a red triangle indicates a poor rating.

Depending on the site you’re attempting to analyze, you may only have access to measurements made using lab data. This goes back to the issue sometimes encountered when using the Chrome User Experience Report as a data source.

If there aren’t enough samples available, Google can’t provide you with the data you would need. Either the sample size will be too small to be meaningful, or they’ll be unable to anonymize the data.

PageSpeed Insights doesn’t stop there. It will also provide you with ways you could improve your website’s performance.

For example, if you have images on your page, the odds are good that they’re formatted as a JPEG or a PNG. Those are the image file types most of us are familiar with. However, JPEG 2000, JPEG XR, and WebP tend to compress more efficiently, which means your site will consume less data as it loads.

Another way you might improve your page’s performance is to remove unused CSS and JavaScript. Web development is a complicated process. You can have hundreds or thousands of lines of code in a single file.

If something isn’t breaking something else, it usually gets left alone. That’s true even if it doesn’t have a function.

While it might not be actively causing problems, unused code can slow a browser down. It still has to read it and realize that it doesn’t have a use, which is time that the computer could often devote to something else.

Tool: Search Console (Core Web Vitals Report)

Along with the algorithm change, Google is making changes to your Search Console. Specifically, they added a Core Web Vitals report to it.

Like PageSpeed Insights, the Core Web Vitals report is based on field data from the crUX report. Unlike PageSpeed Insights, you need to be the owner of a site to use it, and it goes more in-depth.

If your website is newer or doesn’t receive enough eligible traffic, you might not be able to use the Search Console’s Web Vitals report. Instead, you will see a screen telling you that there isn’t any data available. If your site is newer, give it time. That could change.

Search Console uses the same performance categories as the other tools on this list: good, needs improvement, and poor. When you access the Core Web Vitals report, you’ll see a page with tabs corresponding to each category.

From there, you should be able to see the different pages of your website that fall into each category. It appears that, as with PageSpeed Insights, you will have access to separate reports for the mobile and desktop versions of your site.

Now, there are three Core Web Vitals, but Google rounds down. If a page on your website is rated as good for the CLS and FID but needs improvement for the LCP, the page will receive an overall rating of needs improvement. You will not be penalized if there isn’t data available for one of the metrics.

From there, you should be able to view recommendations on how to fix the issues the Core Web Vitals report discovered. Once you have made changes, you can validate your fixes. If the problems don’t appear over 28 days, Google will consider them solved, and you will pass your validation.

If you do not pass your validation for whatever reason, that’s not the end of the world. Make more changes and give it another try.

Tool: JavaScript

JavaScript is a programming language with a lot of different uses. Many programmers have strong feelings about it, and not all of them are positive. Whether you love it or hate it, you can’t deny that it’s useful.

You can use JavaScript to measure your Core Web Vitals. To do so, it’s best if you have the web-vitals JavaScript library. For those of you who aren’t familiar, many programming languages have libraries that contain pre-written code, which speeds up the development process.

When you have the web-vitals library, you don’t have to write everything yourself. Instead, you can call a function, capture the data and then analyze it. We linked to the GitHub page where you can download the web-vitals library above, and the same page includes detailed instructions on how to set things up the way you need to.

If using JavaScript to measure your Core Web Vitals sounds like a nightmare, whether because it isn’t a language you like or you haven’t learned it yet, don’t worry. The other tools on the list will allow you to identify areas where your website’s performance could be improved just as well as JavaScript will, and often in a more easily digestible way.

Tool: Chrome DevTools

Chrome DevTools is a multi-purpose development tool. Like JavaScript, it isn’t meant solely for activities related to the Core Web Vitals. Recently, it was updated so that site owners can use it to identify CLS problems on their website.

Because it primarily uses lab data, FID is not applicable. Instead, you will want to look at Total Blocking Time. Improvements to Total Blocking Time should boost your FID score too.

If you’re already familiar with Chrome DevTools, its new functionality to support the Core Web Vitals algorithm update will be especially useful. If you’re not familiar with it, it’s a user-friendly tool with broad functionality. Starting to learn your way around can help you speed up and simplify your web development activities.

If you have enjoyed this article or are looking for more information, check out the rest of our blog and subscribe to ensure you don’t miss any exciting updates.

Mike Patel

Mike Patel is a digital marketing enthusiast, innovator and President of a leading Digital and E-commerce Development Agency in Dallas, Texas. Mike holds a BS, Computer Science degree from Wayne State University and is a key player in the E-commerce development and digital marketing industry since 2004. The scope of technology in his extensive experience of more than 15 years ranges from Magento, Shopify, BigCommerce SEO (Search Engine Optimization), PPC (Pay Per Click) management, E-commerce SEO, Google Shopping Ads and more.