Core Web Vitals – A Guide To 3-Letter Acronyms with Jason Logan was recorded at our SEO Brunch in March 2021
Jason Logan has worked on websites for over 15 years in multiple industries, including tourism, e-commerce, and lead generation. As a technical SEO, he works heavily with the inner workings of how Google interacts with websites. Jason currently works as a technical SEO manager at resulta, a full-service Nova Scotian marketing and technology company.
So today, I’m going to talk about CWV from GSC, specifically LCP, FID, and CLS, or as I like to refer to it, my guide to three-letter acronyms.
Introduction
So, Google ran into a problem…
How can computers understand “How a User Experiences a Website?”
The fact is, the human brain can store around 2.5 petabytes of data. That’s about 2.5 million gigabytes. So the ability for us to mimic the human brain is not even within our current storage capacity.
So what do we do?
Well, we’ve got to break it down as simply as possible. Sure, we’re not going to be able to make AIs, but, generally, we can get the inference of some of these items as they appear.
What are Core Web Vitals (CWV)?
So generally speaking, we’re talking about Core Web Vitals. Core Web Vitals or CWV is a new component that will appear inside the Search Console underneath enhancements. It’s going to give you scores of good, needs improvement, or poor URLs. These are the pages affecting the user experience of clients coming to your website. And, in May, that’s going to start affecting the rankings. And that’s huge because we don’t know how significant the change will be or how much weight it will carry.
So, what do we see here?
Core Web Vitals are found that in the left-hand column of the search console. In it, you will find two beautiful little charts. One is for mobile, and one is for desktop, allowing you to see the separation between devices.
Generally speaking, mobile is based on a Nexus. So, if you’re doing your testing there, that’s most likely where you’re going to see it. The desktop will be running off of approximately 1024 pixels wide. So a tiny segment of the overall view.
That said, we are going to be talking about three things, three things of importance. We have LCP, which is all about how your page loads. You have FID, which is all about how long it takes to click on things and do things. And then you have CLS, which is all about visual stability. Does your site move around? Does it have elements making it difficult to scroll and read or leave an uncomfortable feeling when loading?
Largest Contentful Paint (LCP)
So, we’re going to start with Largest Contentful Paint or LCP. LCP measures which object appearing in your starting viewport takes the longest to load.
Well, okay, that’s great. But, how do you tell?
Well, you have to take a visualized set. Take a screenshot of what your site looks like when it’s done loading and find the biggest element. See how long it takes to load.
How long is too long?
One big thing is we’ve got a scale. Google has expectations on how long it takes for each element to load. Overall, if you’re below 2.5 seconds, you’re peachy. If it’s between 2.5 and four, it will moderately affect you. And if you’re any further, it’s probably going to hurt your ranking, eventually.
Common issues for LCP
Slow Server
I’m not saying you should switch your host tomorrow, but you need to consider that your code will affect how fast your page loads. And you could end up seeing these issues.
Lazy-loading Images
A lot of popular content styles have lazy-loaded images. Lazy loading images is a fantastic thing. It’s very well thought out, except in the case of the largest contentful paint, where it can delay timing by several seconds. So you wait for all the other loaded items to come through, and you end up with a long loading element.
What’s the fix?
Well, just don’t lazy load the image in, or be careful about which images you’re lazy-loading. If it’s below that first section of content, it’s worth lazy-loading because it’s not on the screen. No one sees it. But if it’s within that first view of the page, for the user to know the page is loading correctly, you want to make sure that it will load at the right time.
JavaScript Inserting Elements
The last common issue is inserting elements of JavaScript. If you have ads, or statistics, or a Google Map—any stylized pieces loaded in with JavaScript, be aware that when you add an element that needs to load, it will affect your timings overall.
First Input Delay (FID)
Next on the list is First Input, Delay, or FID. FID measures how long it takes for the page to respond when you click on it.
FID is the least common issue I’ve come across with any of my clients. But it does happen.
Generally speaking, you want your site to respond as quickly as possible. Less than 100 milliseconds is usually the goal.
But, I think we’ve all experienced that moment of looking at your phone trying to click a link and clicking it four or five times because we’re not sure it’s even doing anything. That’s what Google is seeing. It’s an easy way for them to tell how well a website is functioning. So, 100 milliseconds for good, 100 to 300 for needs improvement. Anything greater is not good.
Common issues for FID
Slow Server Responses
If you have a slow server, one thing you can do is cache everything. Always a blessing and a curse, when done right, caching can save you a lot of trouble. Because if your server code takes a long time to load and you need all that content there, the user doesn’t have to wait if it’s cached. So, it saves a lot of that trouble.
Slow JavaScript Functions
On the other side, there’s JavaScript. If JavaScript is running on your clicks (including Google Tag Manager in some cases). Or anything loading responsively; a view more, for example, that loads more articles. Anything along those lines, that interactivity needs to be quick, or you’re going to start running into FID.
But FID is not the most common issue; it’s specific to a very particular problem.
As long as your server is solid, your website well built, and you don’t have 500 JavaScript files running on all your clicks, you should be fine. But, if you do find this showing up in Search Console, take a look at what you have running on your JavaScript. How fast are your servers responding? Then come back with that knowledge and address it.
Cumulative Layout Shift (CLS)
And last, but certainly not least, is Cumulative Layout Shift. The most important of the bunch, probably. CLS is fascinating because the way it’s measured is so mathematical. You get a score between zero and one, some decimal place thereof. If you have a score lower than 0.1, you’re in the clear. If you’re lower than 0.25, your site or app needs some improvement. Everything beyond 0.25 is terrible.
But how does that number even come to fruition? It seems foreign, but there’s actually a formula to calculate how much the page changes while it’s loading. They measure the size from the initial and endpoints while loading and calculate the difference between them. And if you come in any higher than 0.25, your ranking is at risk. And many things can cause this, so that’s potentially a real problem.
Overall, CLS will probably show up the most and be the most significant issue with CWV.
Common issues for CLS
Image Loading
I did one test using a page from the Chronicle Herald where I took a screenshot of the page loading. Due to lazy-loading, there was a broken image. While a broken image isn’t inherently a terrible thing, in this case, the lagging changed the position of a block of text. When I plugged that element shift into the formula, I got 0.5, definitely a poor result.
Font Loading
Fonts are a major design element, a beautiful part of branding, navigation—everything. But when you load in outside fonts, a resizing occurs. That resizing could end up being just a few pixels here and there, but depending on your primary font, maybe not.
I’ve seen one-line headings turn into two. I’ve seen navigations go from being two lines to one, thanks to the font. I have definitely started reading an article, had an image load in, and lost my place. That’s a layout shift.
JavaScript Adding Elements
The JavaScript issue will always continue. If you add an element to the page that wasn’t there before, it’s going to move everything around.
So what do you do?
The best action you can take is to tell the browser how big something is before loading it. If chrome knows there’s going to be an ad that’s 200 by 500 pixels, you want to save this space. So, put a <div> tag around it to set the width and height of it and fix the entire layout problem from the start.
And that’s it, generally speaking. The best way to deal with CLS is by finding ways to mitigate the size change.
Images are interesting because of how they load. With four or five ways to load images (backgrounds, image and picture tags, source sets, and SVGs (scatter vector tags)), there are as many ways to remedy the issue. For example, on a regular image tag, you can input width and height. If you do that, the browser already knows how much space is needed. The same goes for source sets. And again, you can create <div> areas that are approximately the right size to minimize the shift.
For fonts, that means finding a font to use before loading the original font with the same character width. With the same width, the font won’t cause any layout changes.
So, make sure to use the same font sizes. Make sure you’re loading all your style sheets at the same time—whatever makes sense.
CWV Question from the Audience
Question:
Are you suggesting images and javascript elements like ad units go below the fold for optimum CLS? The sales team would be upset!
Jason’s Answer:
That’s a valid question. I’m not saying you should move your ad units from above the fold. That’s how you make money. But, if you know how big an ad unit is, set the width and height around it, so the browser knows it is there before it loads. If you do that, you can avoid the issue before the layout shift even happens.