What are Core Web Vitals?
Core Web Vitals are a collection of specific factors that Google considers important in the overall user experience of a webpage. Core Web Vitals are three distinct page speed and user interaction measurements: largest contentful paint, first input delay, and cumulative layout shift.
In a nutshell, Core Web Vitals are a subset of factors that will be included in Google’s “page experience” score (basically, Google’s way of assessing the overall UX of your page).
The Core Web Vitals data for your site can be found in the “enhancements” section of your Google Search Console account.
What Is the Importance of Core Web Vitals?
Google intends to make page experience a Google ranking factor. The page experience will be a mash-up of factors that Google considers important for user experience, such as:
- There are no interstitial pop-ups.
- “Safe-browsing” (basically, not having malware on your page) will be a significant component of that score, and Core Web Vitals will play a significant role in that.
In fact, based on the announcement and the name, it’s safe to assume that core web vitals will account for the majority of your page experience score.
It’s important to note that a high page experience score will not automatically propel you to the top of Google. Indeed, Google was quick to point out that page experience is one of several (approximately 200) factors used to rank sites in search. That being said, there’s no need to panic. Google has stated that you have until the end of next year to improve your site’s Core Web Vital scores.
However, if you want to improve your Core Web Vitals score before then, that’s fantastic. Because I’m going to go over all three Core Web Vitals in this guide. And demonstrate how to improve each of them.
Largest Contentful Paint (LCP)
LCP is the time it takes for a page to load from the perspective of a real user. In other words, it is the time it takes from clicking a link to seeing the majority of the content on the screen. LCP is not like other pagespeed measurements. Many other page speed metrics (such as TTFB and First Contextual Paint) do not always accurately represent what it’s like for a user to open a webpage.
LCP, on the other hand, focuses on what is truly important when it comes to page speed: the ability to see and interact with your page. Google PageSpeed Insights can be used to determine your LCP score. That’s useful. Especially when it comes to identifying areas for improvement. The advantage of using Google Pagespeed Insights over a tool like webpagetest.org is that you can see how your page performed in the real world (based on Chrome browser data).
Having said that, I recommend reviewing your LCP data in your GSC. The data in Search Console, like that in Google PageSpeed Insights, comes from the Chrome User Experience Report. Unlike PageSpeed Insights, however, you can view LCP data across your entire site. Rather than analyzing random pages one by one, you get a list of URLs that are good, bad, or somewhere in the middle.
In that regard, Google has specific LCP guidelines. They categorize LCP speed into three categories: Good, Needs Improvement, and Poor. In a nutshell, you want every page on your site to reach LCP in less than 2.5 seconds. For large web pages, this can be a real challenge. Or pages with numerous features.
For example, this page on our website contains dozens of high-resolution images. As a result, the LCP on that page is 5.1 seconds (considered “poor”). That is not an acceptable explanation. However, it demonstrates that improving LCP is not as simple as installing a CDN. In this case, we may have to remove some of the images from the page. Also, clean up the code on the page.
Work that is difficult? Without a doubt. Is it worthwhile? Definitely.
Following that, here are some things you can do to improve the LCP of your site:
- Remove any unnecessary third-party scripts: according to our recent pagespeed study, each third-party script slowed a page by 34 ms.
- Improve your web host: Better hosting = faster overall load times (including LCP).
- Set up lazy loading: Lazy loading causes images to load only when a user scrolls down your page. As a result, you will be able to complete LCP much more quickly.
- Remove large page elements: Google PageSpeed Insights will tell you if you have an element on your page that is slowing down the LCP.
- Minify your CSS: Bulky CSS can cause LCP times to be significantly delayed.
First Input Delay (FID)
Let’s now look at Google’s second Core Web Vital: Delay in the first input. So, at this point, your page has FCP. But the question is, will users be able to interact with your page? That’s exactly what FID measures: the amount of time it takes for a user to interact with your page.
Interactions include the following:
- Selecting an item from a menu
- Choosing a link from the site’s navigation
- Filling out a form with your email address
- Using a mobile device to view “accordion text”
FID is important to Google because it considers how real-world users interact with websites. They have specific criteria for what constitutes an acceptable FID, just like FCP.
Yes, FID technically measures the amount of time it takes for something to happen on a page. So it’s a page speed score in that sense. However, it goes a step further and measures the time it takes for users to do something on your page. FID is probably not a big deal for a page that is entirely content (such as a blog post or news article). Scrolling down the page is the only real “interaction.” Alternatively, pinching to zoom in and out.
In fact, my Search Console does not even report my site’s FID. I suppose it’s because I don’t have any login pages. Or other pages where someone would need to enter information right away. FID, on the other hand, is HUGE for a login page, sign up page, or any other page where users need to quickly click on something.
Remove any unnecessary third-party scripts: Third-party scripts (such as Google Analytics, heatmaps, and so on) can have the same negative impact on FID as they do on FCP. Make use of your browser’s cache: This speeds up the loading of content on your page. This allows your user’s browser to complete JS loading tasks even faster.
Cumulative Layout Shift (CLS)
Cumulative Layout Shift (CLS) is a measure of how stable a page is as it loads (also known as “visual stability”). In other words, if elements on your page move as the page loads, you have a high CLS. That is a bad thing.
Instead, you want your page elements to be reasonably stable as they load. Users will not have to re-learn where links, images, and fields are located once the page has fully loaded. Or you might accidentally click on something.
Here are some simple steps you can take to reduce CLS.
- For any media (video, images, GIFs, infographics, etc.), use the following set size attribute dimensions: The user’s browser will then know exactly how much space that element will take up on that page. And it won’t change on the fly as the page loads.
- Ensure that the following ad elements have a reserved space: Otherwise, they may appear unexpectedly on the page, pushing content down, up, or to the side.
- Add the following new UI elements below the fold: This way, they avoid pushing content down that the user “expects” to remain where it is.