001 Core Web Vitals: What They Are and Why They Matter

In this episode, we’re gonna talk about Google’s upcoming Page Experience update which is happening in May 2021. Slobodan breaks down what Core Web Vitals means for your website and how to prepare for it.

We’re covering the key elements of Core Web Vitals:

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

Links from today’s episode:

Episode Notes:

In this episode, we’re going to talk about Google’s  upcoming Page Experience update. Unlike most of their roll outs, they announced it early on giving us a year to prepare for this. You’ve probably been hearing Core Web Vitals more and more. Whether you’re an in house marketer, work in an agency or own a business, we need to be on top of this.

In May 2020 Google first announced its Page Experience Update, ranking changes set to launch in May 2021. That’s a twelve-month heads-up website owners got, leading me to believe Google is serious about this one. Today we’ll discuss what Page Experience is, according to Google, mostly focusing on the Core Web Vitals, what it is that makes this update different from most previous Google updates, and most importantly, how you can make sure your website is ready for it.

If we look at the history of SEO, in the beginning it was very primitive compared to what we have today. 

Remember the good old days of keyword stuffing? Search engines were simply not advanced enough to understand the pages as well as they do now, but over time, through several major Google updates, they became good at it. It stopped being about repeating the same phrase a hundred times and became more about creating useful, meaningful content around it. 

Knowledge Graph became a thing, so did mobile-first, and Google got seriously good at providing you the right results at the right time. How that content was provided after a user would click the search result and jump to your website from the search results page was rarely considered, assuming your website was mobile-ready enough to survive the “Mobilegeddon” update in 2015. Well, in 2021, how you deliver your content truly becomes important, in addition to what that content is.

What is Page Experience, according to Google?

Page experience is a set of page-level signals Google considers important. The list is not final and will be updated on an annual basis. Currently page experience signals are:

Yes, Core Web Vitals are a new thing, something Google introduced in 2020. But we’ll talk about them in a lot more detail today. Let’s leave them aside and look at the rest of that list. You can tell this is all about how the user perceives the page. 

It has to work well on every device, be safe and secure, and the important content is what users need to see right away. This is all common sense, if you’re trying to make sure people will enjoy interacting with your websites.

Core Web Vitals

But when you look at what Core Web Vitals are, you can really start to understand what it is that Google expects from you, other than things I just listed. As of the time we’re recording this in early 2021, Core Web Vitals are:

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

It may sound complicated, but it really is about three things: how long it takes to display important content, how interactive the page is while it loads, and how stable the layout is during page load. 

How Can You Check Core Web Vitals for Your Website?

The easiest way to check your Core Web Vitals for any URL is to go to PageSpeed Insights and enter your URL. If you’re not familiar with PageSpeed Insights, the link is in the episode description. What you’ll see when the test has finished is two sets of metrics:

  • Field data, taken over the previous 28-day period, from real Chrome users visiting your website and
  • Lab data, from the test you just ran

You can do this for any public URL. So if you want to check how your competitors are doing, this is how.

Another place where you can monitor Core Web Vitals for websites you manage is Google Search Console. You even get warnings if the values are not good enough and can see how many URLs have good Core Web Vitals values, how many need improvement, and how many are simply bad.

Finally, there’s Lighthouse. It is an open-source, automated tool for controlling and improving the performance of web pages. PageSpeed Insights I just mentioned, is powered by Lighthouse. But you do not have to go to PageSpeed Insights URL to run the test, you can use Chrome Developer Tools, or even a command line tool to run it programmatically from your computer. I will not go any deeper with Lighthouse now because we have a lot to cover, but if you check this episode’s description, you’ll find some useful links there.

Are Core Web Vitals More About Page Speed or Site Design?

Great question, and I would say if you look at Page Experience as a whole, definitely both. But if you’re only looking at Core Web Vitals it’s more about loading performance of a webpage, so not only speed, but also interactivity and visual stability.

Let’s talk about each Core Web Vitals – what they represent, how you can monitor and improve them.

Largest Contentful Paint (LCP)

Largest Contentful Paint is a way to measure loading performance of a page – how quickly the user gets to see the largest visible element above the fold. That’s literally the element that takes up the most pixels above the fold, when the page is loaded. 

To get a good LCP score your page needs to display that element in 2.5 seconds or less. 

So does LCP only pertain to an image or the combination of images, text and other elements above the fold?

Your largest contentful paint element could be any single element of the webpage – an image, a heading or paragraph of text, maybe a video, or an iframe, literally any element, as long as it is the largest one above the fold.

Let’s say you’re looking at a typical product page in an e-commerce website. In most cases, LCP element will be the main product image – you want this element displayed as soon as possible. This is where a lot of people would go for things like CDN, caching, a more powerful server – and all of those can help, sure, but they should not be the only, or even the first things you do.

Too often, performance optimization is nothing more than optimizing delivery of existing assets, by using the techniques I just mentioned. Again, that’s great, but if that is all you’re doing, you are really missing out on making a greater impact. Think of it as hiking. Yes, you could get a larger backpack and carry everything you have in it on your hike, including a bunch of things you won’t really need – but does that make sense? Shouldn’t you pack only the things you actually need and make your experience as pleasant as possible?

What exactly is it that gives you a poor LCP value then? How do you know what to pack and what to leave home?

For best results, you should work with your web developer to fix this. A good developer should know to build a fast loading website. If not, send them to web.dev/fast. It is a free resource provided by Google where web developers can find everything they need to know about website performance.

But in reality, due to the popularity of content management systems like WordPress, a lot of websites are not built that way. If you can buy a domain and get a hosting plan it is really easy to run your own website. Pick a theme, install a few plugins and you’re up and running. 

Before we continue talking about LCP and how to fix it, can I just say something about WordPress? It is not slow, OK? It is easy to make it slow, and most people do, but out of the box, even on a cheap hosting plan, WordPress is fast. I did some tests last weekend, set up a simple page using WordPress’ block editor, no optimization at all and it got a 99 mobile PageSpeed score.

That out of the way 🙂 let’s get back to largest contentful paint and what it is that hurts your website. We already talked about what LCP is – the time it takes to display the largest element above the fold, but this is not as simple as loading an image, or a webfont.

Everything That Needs to Happen Before the Largest Element is Displayed

The first thing that happens when you click a link, or type a URL in the address bar is the server hosting the website processes the request and returns the document. You may have heard of the metric called Time to First Byte, this is the time it takes the server to send back anything. And while a slow server or a poorly optimized backend is definitely something that can happen and hurt your website, it is not as common these days.

Also, Core Web Vitals are more about loading performance after the server has returned the page. In a race, your reaction time matters, but a sprinter with a slower start will beat an average person ten times out of ten. We’re talking about tens or hundreds of milliseconds when it comes to server response time, in most cases. Loading the entire page, processing all the assets, rendering the layout – that’s a few seconds, if your page is fast.

This is why things like CDN, caching, or a more powerful server are not the most important things you need to work on.

You can easily have a server response of 100ms or less and still score poorly on all three Core Web Vitals. And the reason for that is usually very simple – complexity and clutter.

Pages with dozens of unused CSS and JavaScript files are that “just pack everything you have and take it with you” hike. Usually, most of those files are render-blocking, which means the browser can not start rendering the page until it processes them. I’ve seen websites that have 30+ of CSS and JavaScript files, in fact, if you get carried away with plugins on a WordPress website, that’s nothing special. If you use a page builder plugin it is likely your HTML structure is also complex.

And let me explain, in simple terms, why this is bad, other than the obvious reason – too many files to download, and a larger than needed HTML document.

Before a browser can display anything, it needs to process what the server sent back. It needs to go through the entire HTML document and create the Document Object Model, the DOM, which is a tree-like structure that is an object-oriented representation of the HTML document. So, html tag has head tag and body tag inside it, head tag has meta tags, title tag, script tags and so on, body tag has sections, divs, paragraphs, images… In the DOM, each tag is converted to a node that can have a parent node and children nodes.

Simple enough, right? But a webpage is not a text document, and everything you see has some styling applied to it, and there’s also the layout of the page. That’s what CSS is for. So in addition to creating the DOM, the browser now needs to go through all CSS files and process them to create CSS Object Model, or CSSOM. This can take a while. And it needs to be finished before anything is displayed, because the browser needs to know what each element is supposed to look like and where it’s supposed to be in the page. This is why CSS is what is called “render-blocking” – the page can’t render until CSS is downloaded and processed, simply because the browser doesn’t know where the elements should be and what they should look like.

Throw in some DOM-altering JavaScript and this process can take even longer. 

THIS is why clutter is bad. Complex HTML means more time to construct the DOM. A whole lot of CSS rules means more time to construct the CSSOM. And JavaScript, unless you’re careful about it, is there to add fuel to the fire.

So, should you hire a developer to address this issue?

Having a technical person on board helps a lot. But, even if you’re on your own, go to that plugins page and ask yourself – do I really need this one? Just assume every single one of those plugins is slowing down your website – some more, some less, but it is very likely they all make things at least a little bit slower. If you have a staging site, try deactivating some of the plugins and running PageSpeed Insights before and after, to see if things change. Maybe you can even do this in live, if the plugin is not essential.

If you ARE working with a web developer – have them audit every single asset that’s being loaded. For every CSS or JavaScript file they list for you, ask yourself these questions:

  • Which plugin is responsible for it?
  • How big is the file?
  • Do I need it for this page to function?
  • Do I need it loaded early or can I afford to load it later?

Often, the answer to at least one of those last two questions will be no. Remember, what you want to do is allow the browser to compute the page as quickly as possible, so it can be displayed. Anything that’s in the way of that – CSS and JavaScript files – that doesn’t need to be there must be gone. This is called optimizing critical rendering path, and the whole purpose of it is allowing the page to be displayed as soon as possible.

Do this and your Largest Contentful Paint will improve, guaranteed. You want your LCP to be lower than 2.5 seconds to be considered good, and you DEFINITELY want it under 4 seconds, anything more than that is considered poor and could get you in trouble.

And for those things you cannot remove, like a chat bot, if you consider that to be essential for your business, better make sure it performs well, and then try to make improvements elsewhere.

What can website owners expect if they improve their LCP?

Earlier we mentioned a WordPress website I set up recently that got 99 on PageSpeed mobile, I believe LCP there was around 2 seconds. So any out of the box WordPress website will crush it.

And if you need a good example of what optimizing LCP can do for you, NDTV, one of India’s largest news websites has recently improved their LCP by 55%, which led to bounce rate being reduced by 50%. 

Improving LCP is hard work, but the idea is dead simple, show your users meaningful content as soon as possible and they’re much less likely to bounce.

First Input Delay (FID)

Let’s move on to the next Core Web Vital – First Input Delay? What is it, and how is it different than LCP?

LCP measures loading performance of the page – how quickly it displays important content. First Input Delay quantifies load responsiveness of a page. What’s the point of displaying a page quickly if users are not able to interact with it? When it comes to First Input Delay, an interaction is an input event from actions like clicks, taps and key presses. So, a user trying to open a menu, or clicking an AJAX add to cart button. Notice that actions like scrolling and zooming are not on that list.


Does the interaction have to happen above the fold?

The reason Google chose first input and not “every input delay” is, well, first impressions matter. This is a simplification, but essentially, that’s it. It’s also easier to measure delay for one particular interaction – the first one – than for everything a user does in the page.

You want FID value to be under 100ms, anything more than that could make the user notice the lag. 

How you can address first input delay (FID)

We mentioned field data and lab data. The thing about First Input Delay is that it can’t be captured by lab data, a generic automated test doesn’t know how to interact with your page the way a user would. This is why a tool like PageSpeed Insights will not report what your First Input Delay, instead it will show you Total Blocking Time, a metric that correlates well with FID in the field, while also capturing page interactivity issues.

So the answer is no, you can’t measure First Input Delay by running a lab test, simply because that test will have no user inputs. Luckily, there’s a good proxy metric in Total Blocking Time. If your page is blocked, or unable to respond because it is doing something else, for a long time while it loads, it is likely First Input Delay will be higher.

So, why is there a delay in the first place? What is it that is blocking the page? Heavy JavaScript. And lots of it. To optimize the JavaScript code that your page load you will need help, unless you are a developer.

However, the first step to better load responsives is not forcing the browser to do the work that’s not needed. Fewer resources, followed by optimized delivery of whatever’s left. Clean up the mess before you worry about optimizing what’s left.

Cumulative Layout Shift

Cumulative Layout Shift is all about visual stability or how much the elements are getting pushed down while the page is loading.

I’m sure you’ve had this happen to you more than a few times: the page is loading, you’re about to click or tap something, then the page elements shift or get pushed down, and as a result of that you click or tap the wrong element.

This usually happens when resources are loaded asynchronously or DOM elements get added dynamically, especially high up in the page. 

Cumulative Layout Shift is the sum of layout shift scores for all above the fold elements. Layout shift score is impact fraction * distance fraction, basically size times distance moved.

If an element is large and moves a lot its layout shift score will be larger, a small element that barely moves will get a low score and any element that doesn’t move at all gets a zero.

Scores below 0.1 are considered good and that’s what you should aim for. 


That may sound hard to achieve though, so how do you address and avoid this shifting or jumping on your page?

For most websites, this one will be the easiest one to fix, or get right. If you specify image dimensions in your templates, place ads and iframes in container divs that have a fixed height that matches the content, avoid dynamically injecting content, especially above the fold, unless the user has specifically requested it by interacting with the page – you’ll mostly be OK.

To simplify things a bit, for every element in your page that might be loaded or populated after the document has been rendered, for whatever reason, make sure you reserve the correct amount of vertical space, so the layout doesn’t shift once the element is loaded. You want to avoid any movement in the page that wasn’t initiated by the user.

To give you an example, Yahoo! Japan worked on their CLS, improved it by 15%, and as a result their sessions got longer by 13% and the users saw an average of 15% more pages per session. A layout that doesn’t frustrate doesn’t make you run away.

Core Web Vitals Summary

It’s all about how your webpage is loading, but specifically about three things:

  • Perceived load speed
  • Load responsiveness and 
  • Visual stability

This is not UX in a traditional sense, but it is about a pleasant user experience, so keep that in mind. If you optimize for Core Web Vitals you’re not only keeping Google happy, you’re keeping your actual users happy, too. And that’s never a bad thing.

Where do you start with the Core Web Vitals? 

  1. If you have no experience with them at all, check out Google Search Console, just to see where you stand, if you have any warnings or anything like that. 
  2. Once you’ve done that, go to PageSpeed Insights and analyze some of your key pages. Homepage, some landing pages, anything that you need to rank well, but also convert well with real users. Core Web Vitals and Page Experience are about making the page easier to use after all. Unlike Google Search Console, which only gives you an overview, PageSpeed Insights will give you tons of useful info that will explain why something is wrong and get you on the right path to fix it.
  3. Finally, talk to your web developer about this, and if needed point them to web.dev/fast, or get your hands dirty and start inspecting and tweaking your website. Test the page, remove a plugin you don’t really need, test again, see how that affects the score.   

If you don’t mind getting a bit technical, spend some time getting familiar with Dev Tools in your favourite web browser, head over to Network tab, the one that lists all the requests a page makes and you’ll learn a lot about the size of the resources, how much time they need, for how long they block the rest of the page, if they’re used or not, and so on. Check your browser documentation to see how you can use its dev tools and see network requests or use a service like webpagetest.org to check any URL. The report you’ll get will not only list all the assets, but also tell you the order in which they are requested and how much time loading and processing them takes, among other things.

With the way SEO is headed, with the emergence of technical SEO and the upcoming page experience update, that would be a great investment of your time.

It may sound complicated, but it really is about three things: how long it takes to display important content, how interactive the page is while it loads, and how stable the layout is during page load.


Don’t forget to subscribe to the No Hacks Marketing Podcast. And if you learned something new today, we would appreciate it if you can leave us a review on your favorite podcast platform.