Let’s Talk About Core Web Vitals
It has been a busy summer with not one, but two core updates being released by Google for its search algorithm. And if that wasn’t enough, in late June, Google finally introduced its Core Web Vitals update, which it had been talking about for a while, but was slow to roll out.
If you don’t spend your time reading SEO blogs (don’t judge me for my interests), you might not know about this update, which in my opinion, is one of the most important things Google has done in a very long time. Before I jump into what it is, let me explain why it matters.
On Tuesday, I wrote about Dotdash. One thing I said was that a core belief of the company is that speed matters. And when I say speed, I mean how quickly a website loads. The faster it loads, the better the user experience, and hopefully, the more ad revenue that can be made.
Core Web Vitals look at page speed and then supercharges it, asking for even more improvements to user experience. And since it is an update to Google’s search algorithm, ignoring it can have a serious impact on the number of users that find our content.
There are three parts of Core Web Vitals:
- Largest Contentful Paint (LCP)
- First Input Delay (FID)
- Cumulative Layout Shift (CLS)
Let’s talk about each of them to understand why they matter so much.
Largest Contentful Paint (LCP)
This is the most straightforward of the Core Web Vitals. What LCP is tracking is how long it takes for the page to load, but with a twist. Historically, we’ve looked at things like First Contentful Paint (FCP), which is how long it takes for the first piece of content to load.
Google is paying attention to how long it takes for a user to be in a position to interact with the page. In other words, the page could load quickly with the first piece of content, but if it takes all the content—text, images, video, etc.—a while to really process, then it’ll have a negative impact.
How fast is fast enough?
According to Google, it’s 2.5 seconds. If the page and all its content loads in <2.5 seconds, you’re going to get a good score from Google. This is page-level analysis, though. This means that one page could do incredibly well while another could really do poorly.
The question, though, is what actually impacts the page load time? There are a few things that come to mind.
The very first one that seriously impacts publishers is our advertising. If an ad takes a while to load (as they often do because of header bidding), then we may see our LCP blow through the target mark of 2.5 seconds. One of the simplest fixes here is to simply remove partners from the bidding stack. Identify partners that are always bidding, never winning, and generating a very small percentage of your revenue. Take those partners and remove them. It’s costing you resources and not making you any money.
Another area where publishers really struggle is with images and video. These weigh more than text. Therefore, it requires more processing power to get them to load. There are a few ways to help alleviate this problem.
- Implement lazy loading: If there are images that are down the page from what the user will first interact with when it loads, don’t load them right away. Have them load after the user has started reading (though be cognizant of CLS, which we’ll get to).
- Compress file sizes: We can take a large file, upload it to our CMS, and resize it. But it’ll still weigh a lot. Instead, take the extra step and reduce the actual file size before uploading it into our system. Most of us are looking at things on our phone; we don’t need ultra-high definition images to work.
- Push videos below the fold: Since we all agree auto-play video is bad (tell me you agree), push the video below the fold so that it doesn’t have to load right away. That way, the user can interact with the site before having to see the video.
Finally, clean up your 3rd party trackers. Identify every piece of JavaScript that is loading and figure out what you really need to do your work. It’s probably not nearly as many trackers as you presently have. With those that remain, spend the time to transition to Server Side Google Tag Manager. This removes the loading of these tags from the browser, which should improve the speed of things. Google has more to say about that here.
First Input Delay (FID)
With LCP, we are looking at how long it takes for a user to be able to see the content on your page. With First Input Delay (FID), we are looking at how long it takes for someone to do something on the page. More specifically, it’s how long it takes for the browser to react to the action taken by a user.
For most publishers, this won’t matter nearly as much as the other two Core Web Vitals. Most interaction on our site is the ability to scroll and continue consuming our content.
But there are a few areas where people do input and interact:
- Signing up to a newsletter
- Becoming a subscriber
- Clicking a link
What does FID look like in this case? If a user goes to sign up for the newsletter, puts their email in, and hits subscribe, how long does it take for the browser to start loading that they’ve signed up? To have a good FID score, it needs to be 100 milliseconds or less. No one likes to click something and have nothing happen.
But like I said, for most publishers, FID is the least important of the three Core Web Vitals.
Cumulative Layout Shift (CLS)
Now we come to my favorite Core Web Vital because it touches on one of my biggest pet peeves. As the name suggests, CLS is assessing how stable the page is as it loads. So, while the previous two are looking at speed, this is looking at how much the site shifts as the site loads.
How many times have you visited a site, started reading the content, and then lost your place because an ad that hadn’t finished loading finally appeared? How many times has the content shifted left or right because an outstream video suddenly appeared?
Publishers are horrible at this. We allow our monetization to interfere so egregiously in the user experience. And it’s even more offensive because our monetization techniques take longer to load than our content (since so many pubs rely on 3rd-parties for this), so things are constantly bouncing around.
It’s really intrusive to the reader and it’s hurting publishers’ businesses as well.
The major fix here is to preload the space required for advertising from the beginning. Even if you have fluid ads (where you might load a few different sizes in there), look at ad fill reports to determine which size loads most often and default to that on initial load.
Other areas of improvement could be simplifying the ad load experience above the fold. Again, what happens off-screen is less important than what happens when the user is engaging with the content. Therefore, if you want to get fancy with fluid ads, force those below the fold and keep simpler, larger ads up top.
The goal here is not to avoid monetizing; it’s to avoid a website doing the waltz.
This doesn’t get a time rating, but instead, a rating from 0.0-0.3 (or worse). If your page gets a score of 0.1, you’re in a good place. If, however, you’re pushing 0.25 or above, it’s time to make some major fixes.
Summing up
Advertising is a major culprit for a lot of the problems we deal with pertaining to page speed and layout shift. And we have to do the necessary work to ensure we are hitting the necessary scores even if it means we take a short-term hit to page RPM.
Here’s why…
While we might see a drop in how much we earn at the page level, if we have a fast-loading, dance-free site that is easy to interact with, users are more likely to stick around. That means we can monetize them more often across more pages. So, RPM may drop, but ARPU could increase.
Additionally, since Core Web Vitals are part of the variables that go into ranking pages, if a site is doing better than a competitor, it could result in more people visiting the site. That’ll definitely have a positive impact on revenue.
Speed and user experience both matter. The fact more publishers don’t take these things seriously is disappointing. It’s 2021. It’s time.
