Ultimate Core Web Vitals Guide for Publishers

You're watching AdThoughts, a video series where we interview industry experts on all things ad tech. In today’s episode, we chat with James Nielsen, Publift’s Head of Onboarding, about Core Web Vitals (CWV), why it’s important for publishers, and what they can do to optimise their CWV health.

The Core Web Vitals are the three Google metrics used to evaluate the performance of your website. It is used to measure the quality of user experience in the real world around loading performance, interactivity, and visual stability of a page. These metrics are Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS).

Ever since Google implemented these new metrics in mid-2021, CWVs have become increasingly important for publishers because it is a ranking factor for websites. This means publishers will need to deliver a consistent web experience across a multitude of devices to drive better user engagement.

Read more about Core Web Vitals here.

Key Takeaways

• Core Web Vitals are Google's framework for measuring user experience on the web — made up of three metrics: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), and FID (First Input Delay) — and they feed into Google's core ranking algorithm with increasing weight.
• Core Web Vitals matter most if you rely on organic search traffic from Google. If most of your traffic comes from direct or social, the impact on your business is much lower — always understand what these metrics actually mean for your specific site before acting on them.
• LCP — the most important metric for publishers — measures how long the largest element on the page takes to load. Google's benchmark is under 2.5 seconds for 75% of users. Compressing hero images, prioritising load order, and avoiding heavy above-the-fold elements are the key levers.
• CLS measures visual stability — unexpected content shifts that cause users to click the wrong thing. For publishers running header bidding, the primary fix is pre-allocating fixed-height div containers for ad slots so the page layout doesn't shift when ads load.
• FID measures how quickly the page responds to a user's first interaction. It's the least impactful metric for ad publishers specifically, but reducing third-party scripts, minimising JavaScript, and implementing lazy loading all help.
• For measuring your actual Core Web Vitals scores, Google Search Console is the gold standard — it uses real user data. Tools like PageSpeed Insights use simulated data based on worst-case scenarios and can be misleading without understanding that context.

What are Core Web Vitals, and why do they matter for publishers?

Naomi: I'm Naomi from Publift — we're an award-winning adtech company based here in Sydney, where we help publishers monetise their content and improve ad revenue. Welcome to our very first episode of AdThoughts, where we dive into the world of adtech by picking the brains of our expert team members. Today we're exploring Core Web Vitals for publishers. Core Web Vitals health is always an ongoing conversation between our internal team and publishers, so we know how important it is to maintain good scores to be in good standing with Google's search engine results page rankings. Today I have James Nielsen with me — Publift's Head of Onboarding. James oversees the entire onboarding process, ensuring that publishers who work with Publift are expertly integrated with our technology so that they can start monetising their content. James is overseeing the onboarding of hundreds of websites and has a great understanding of all things Core Web Vitals. Say hi, James.

James: Hi Naomi, nice to be here. As Naomi said, my name is James and I'm the Head of the Onboarding team here at Publift. So once publishers learn about our services and have spoken to our sales team, they're passed over to our team of skilled Solutions Consultants who walk our publishers from go to woe through the entire onboarding process. And one of those things that we often engage in conversations about with our publishers — because they're not only looking to increase revenue, they also want to maintain a good user experience for their sites — is Core Web Vitals.

Naomi: So let's dive right in, James. If I were a smaller publisher, perhaps still learning the ropes and grappling with all of this adtech stuff, how would you explain what Core Web Vitals is to me?

James: So Core Web Vitals is an attempt to measure the user experience of a website, and it's also something that now feeds — with increasing weight — into Google's core ranking algorithm. From a publisher's perspective, yes, it is saying you should seek to deliver the best user experience to all of your site's users as you can. And from that perspective it's a great tool to see how you're doing and where you can improve. That being said, there's also been a lot of fear around it that's probably stemmed from a level of misunderstanding about what it is. It should be used as a way to benchmark yourself and seek to deliver better user experiences. From an advertising perspective, the better experiences you can deliver, the more traffic you're likely to drive — and therefore the better advertising revenues you can get as well.

James: But it will be more relevant to some than others. For example, this is a Google project — for want of a better word, it's built into the Google search ranking algorithm. So if you're a site that doesn't derive any significant traffic from organic search from Google, then it's going to be less important in terms of traffic impact on revenue and so forth. Again, great tool to measure yourself and the kind of experiences you're delivering, but going to have less of a business impact if you're getting most of your traffic from direct routes or coming in through socials, for example.

James: It's also important to remember that it is one of — I think — about 200 ranking factors within the Google ranking algorithm, albeit an increasingly heavily weighted one. But things like search query and intent are still going to be the main ones. An example I sometimes give to explain that a little bit more: if you are a badminton club in Darwin, Northern Territory — I can't imagine there are too many badminton clubs up there, apologies to all the badminton enthusiasts in the Northern Territory — but I would imagine there are one or two. And so if someone goes into Google and searches "Badminton Club Darwin Northern Territory," given there are only one or two clubs, that search query and intent is going to deliver you very high in the rankings — probably number one or two — regardless of what your Core Web Vitals are. Now if you're in a situation where there were a thousand or ten thousand competitors — a much more saturated market — then Core Web Vitals are going to become increasingly important, because you want to have the best scores because it is going to inform that ranking algorithm and you obviously want to rank ahead of your competitors.

James: Anyway, I mentioned all that just as a bit of a caveat — like anything, these shouldn't be considered in a vacuum. Don't just get hit with an outreach email saying you've got poor Core Web Vitals. It's important to always understand: what does this really mean to me? Back to the topic at hand — Core Web Vitals. As I said, a measure of user experience, and there are three main metrics that make up Core Web Vitals: Largest Contentful Paint or LCP, Cumulative Layout Shift or CLS, and FID — First Input Delay. Those are the three main metrics driving your Core Web Vitals scores. Now for each of those you get a ranking of — I believe it's poor, needs improvement, or good. These are 75th percentile metrics, so it means for 75% of your users you need to be hitting Google's benchmark. For LCP, for example, that's two and a half seconds. But I believe we're going to get into that a little bit more.

Definition — Core Web Vitals: a set of three Google metrics — LCP, CLS, and FID — designed to measure the real-world user experience of a web page. They are a weighted factor in Google's search ranking algorithm.

What is LCP (Largest Contentful Paint), and how can publishers improve it?

Naomi: All right. And if we were to break all those down, should we maybe start with the most important one — that would be LCP, I'm assuming?

James: Yeah, so the biggest one is LCP. And certainly for us with advertising, some are more important than others. LCP — Largest Contentful Paint — is probably the most important along with CLS. This assesses the loading time or performance of the elements present on the website — specifically the largest element on the page. So it determines the time it essentially takes for that largest element to load on a page. Google sets that benchmark at two and a half seconds. It's a 75th percentile metric, so as long as 75% of your user base are experiencing an LCP score where the largest element of the page is loading in under two and a half seconds, you're going to get a good score from Google. And these are in line with key industry metrics — I think key industry metrics suggest that about 50% of all internet users expect websites to load in two seconds or less. But yeah, Google sets that benchmark at two and a half seconds. Over that, you're in needs improvement or entering failure territory.

Naomi: Right. Yeah, I mean that makes sense — if you open up a page and the biggest photo or banner isn't loading, you're probably going to exit it anyway and look for another site. So that two and a half seconds makes sense actually. So it's about loading times — what are some of the ways our publishers can actually maintain good scores? How would you suggest they can maintain below two and a half seconds of loading time?

James: Yeah, so as you said, it's all about load time. So you want to prioritise site design with that in mind. And it's a pretty helpful caveat to call out — this is everything above the fold. So anything that loads in that initial viewport — anything below the fold isn't counted. So you want to make sure that you're not running super heavy or large hero images right at the very top of the page, or that you've got them compressed accordingly. You want to prioritise load events as well so you're not overburdening the main thread. If you do have larger images above the fold, make sure they're as compressed as possible and make sure they're loaded in that load order as early as possible. Critical information above the fold only — is the information you're showing when a person initially hits the site important for that visitor? If it isn't, maybe consider moving it down. Do you really need that hero image? Could it be smaller, could it be compressed? Anything that prioritises load speed.

Naomi: That actually doesn't sound too complex for a metric that seems so important. So that's good to know that it's quite manageable.

Definition — LCP (Largest Contentful Paint): a Core Web Vitals metric measuring how long it takes for the largest visible element on a page — often a hero image or banner ad — to load. Google's benchmark is under 2.5 seconds for 75% of users.

What is CLS (Cumulative Layout Shift), and how do ads cause it?

Naomi: And how about CLS — Cumulative Layout Shift? I hear this quite a bit in our meetings, so it'd be good to have a nice breakdown of what it is.

James: So Cumulative Layout Shift — CLS — is about visual stability of the page and unexpected shifts in a website's page layout. What does that mean in practice? I think we've all had that frustrating user experience — and user experience being the operative word here, and why Core Web Vitals were brought into existence in the first place. You're on a page and you're about to click on something, and then all of a sudden something finally loads and all the content on the page shifts. So you might be trying to enter details or you might be trying to click a link, and all of a sudden you click something you didn't mean to and you're redirected to a page you didn't want to go to. And that's a frustrating user experience. So from a CLS perspective, the value that you want to maintain or stay below is 0.1 — to maintain a good user experience according to Google. And again, a 75th percentile metric — 75% of your visitors need to be scoring less than 0.1 to be classified as good. Again, this is only for everything above the fold.

Naomi: Right. And what would you say — how can our publishers keep these shifts to a minimum? I'd assume that a lot of it could be due to ads — like when the ad refreshes and then it changes size, and if the size is different from the previous ad loaded, the content shifts. Is that something that commonly happens with publishers?

James: Yeah, so specifically with our publishers and ads — because of what we do with header bidding and the fact that there's an auction being run in the browser — it can take time for that to finish for the winning creatives to be delivered to the page. And so sometimes, if they're not delivered to the page until most of the rest of the content loads, then the insertion of that ad creative can cause that Cumulative Layout Shift — things moving around on the page. So typically what we want to do here is fix the height of the divs where the ads are going to be displayed, in line with the maximum size creative that we expect to be served there. So if I've got a banner ad at the top of a page that's, for example, 728x90 — the div that I'm going to have that ad serve into, I want to fix those dimensions at 728x90. What that means is the space will already be accounted for when the page renders. Initially it might be a blank box, but then very quickly — within those couple of seconds — the ad will then serve into that div. And because we've already provided for the space on the page, we're not going to get that layout shift where everything else drops down the page. And again, whether an ad refreshes and we're serving different size creatives into that div, as long as we've fixed that parent div, we're not going to get that stutter as different ads refresh or different-sized ad creatives are served into that div.

Definition — CLS (Cumulative Layout Shift): a Core Web Vitals metric measuring unexpected movement of visible page content. For publishers, the primary cause is ads loading after the rest of the page and pushing content down. Fixed-height div containers are the standard fix.

What is FID (First Input Delay), and how does it relate to ads?

Naomi: Yeah. And how about that third metric — FID?

James: Yeah, so from a publisher's perspective, and in regards to us putting ads on the page — FID, First Input Delay, is probably the least important of the three metrics. Or a better way to put it: it's the one we tend to impact the least. So for LCP — the ads loaded on the page might well be the largest element, so we want to make sure we're getting the auction and everything kicking off as early as possible so they've got the best chance of being served on the page before that two-and-a-half-second benchmark. Cumulative Layout Shift as well — because there can be that slight delay with the auction and the ads getting returned to the page, we want to make sure those divs are fixed, ready and waiting for the ads to be served into, so we don't get that CLS. FID, on the other hand — First Input Delay — is a measurement of essentially the responsiveness of the website. It measures the time from when a user physically interacts with your site. So there might be a clickable button — if you click on it and nothing happens for two or three seconds, that delay is what's being talked about in First Input Delay. And that might mean that other processes happening in the main thread haven't finished yet. So your request — when you click that button on the page — is waiting to be executed while other things execute in the main thread. And again, that can be a frustrating user experience if you're clicking away and the page is still loading.

Naomi: Yeah, that's a poor user experience.

James: Now again, as I mentioned, a less impactful metric — or rather a metric we tend to have less impact on compared to the others. But on that, I think it's 100 milliseconds — so you can't have an FID score of more than 100 milliseconds, otherwise you're going to start failing that metric.

Naomi: How can publishers improve their FID then?

James: Yeah, look — it's pretty straightforward. As I was alluding to, you want to limit the amount of work being done in the main thread. For example, there are four main things you could do. Reducing third-party code and third-party scripts on the page that are running in the background — the longer they take to load, the longer it's going to take for the page to be interactive. Reducing JavaScript loading time — it's an important part of delivering good user experiences, however don't go overboard with it. For example, having potentially needless bells and whistles or dancing text or what have you on the page — they might look pretty, but is it delivering any value? Is it just slowing down your page load, just increasing page weight? So minimisation of the main thread load is going to help speed up that page. And then things like implementing lazy loading, which conserves bandwidth, delivering the main content that users need as soon as possible.

Definition — FID (First Input Delay): a Core Web Vitals metric measuring the time between a user's first interaction with the page (e.g. clicking a button) and when the browser can actually respond to it. Google's benchmark is under 100 milliseconds.

Definition — Lazy loading: a technique where page elements — including ads — are only loaded when a user scrolls close to them, reducing initial page weight and preserving bandwidth for the content users see first.

What tools should publishers use to measure their Core Web Vitals scores accurately?

Naomi: Like listening to some conversations that have been happening in our meetings as well, it seems that it can be a struggle to actually get accurate information on what your Core Web Vitals scores actually are. And because it's such an important thing, I can imagine it's really frustrating to not get one accurate metric or have one source of truth to find out what your actual scores are — inconsistent and unreliable. How are you going to optimise your website if you don't have any reference to base it off? So I know that in our team we do have a tool that is basically able to give you almost real-time results. Would you be able to share with us about that?

James: Yeah, so basically — not the finer details, that might be a question better answered by one of our brilliant dev team — but essentially baked into the tag we have, and through some Google APIs that are made available to us, we're able to extract this information directly from the web page. Again, these are all based on load events that happen within the page, and so we can capture that information in a real-time fashion and make that available to publishers.

Naomi: So outside of the Publift product suite, do you have any recommendations they can use to track their Core Web Vitals health?

James: There are a few. There are certainly some that I wouldn't recommend. Most publishers will have access to Google Search Console, which is going to provide much better information. It's going to be based on actual traffic to their site — real user experiences. So if you have the ability to set up Google Search Console for your site, I definitely recommend doing that. That's going to give you the truest picture of your actual performance against these metrics.

James: There are other tools out there which I definitely recommend less. A decent one is Lighthouse — this is a piece of tooling that's built into Chrome DevTools. It can be quite information-heavy and so it can scare off certain people. It's a mix of real data — or primarily simulated data — just don't quote me on that one.

James: And the last one is PageSpeed Insights. It's probably not one that I'd recommend — it comes in for a fair bit of critique across the industry and particularly within development circles. The reason for that is that a lot of people leverage it without understanding that it's simulated data. So it's not based on real-world results. Often those tests will be run in a throttled mode, assuming a worst-case scenario. So the test might run from a location or a country that has poor internet speeds. The test assumes a very dated device — so it might assume access from an old Nokia or LG device running on a low 3G connection. And so publishers will run the test, get these scores back, and be in shock — they'll have these terrible scores — without realising that it's been run on a very worst-case basis.

James: Now if the majority of your users are based in locations with poor internet and are using old devices — okay, well then that test would be quite telling of your usual user experience. But if the majority of your users are based in a country like the US or the UK, or somewhere with good internet speeds, accessing it on the latest devices — well then that test would not be reflective of that. You want to test where someone's got great internet on a new device. And if you adjust those settings and run the tests again — which you can do in Lighthouse — you'll see a very, very different result.

James: So the tools I'd recommend: if you get access to Google Search Console and set that up, that's going to be the best — actual measurements based on real-world data of your users actually hitting the site. The other tools, while they can measure it, are usually based on simulated data, and so you really want to understand if the simulation is reflective of your users.

Definition — Google Search Console: a free Google tool that provides publishers with real-world performance data for their site, including Core Web Vitals scores based on actual user visits. The gold standard for measuring your true scores.

Definition — PageSpeed Insights: a Google tool that analyses a page's performance. It uses primarily simulated data based on assumed device and connection conditions, which can produce misleading scores without understanding the test parameters.

Summary: What are the key things publishers should take away about Core Web Vitals?

Naomi: So James, if you were to summarise everything we've gone through today — which is quite a bit — what exactly are the key points you'd like our publishers to remember?

James: Yeah, so as I mentioned — first and foremost, Core Web Vitals came into existence as a way to measure user experiences. And as a publisher or website owner, from that perspective, it's a great tool to understand how you're performing — what kind of experiences are you delivering to your customers? Are they good, satisfying experiences, or are they poor — do they need improvement? I think it's also important, as I said earlier, not to consider any of these things in a vacuum, but to truly understand what this means to me. There's been some fear developed around them. Are these relevant to my business? Now certainly, if you're a website that derives a lot of revenue from advertising and gets a lot of traffic from organic search — from Google — then yes, very, very important. You want to nail those Core Web Vitals. You want to rank as highly as you can, get as much traffic, and drive as much ad revenue. That's probably what I'd want publishers to take away from today.

Naomi: Well that sounds very helpful indeed. And thank you so much for sharing your expert knowledge on this — I feel like I've certainly learned a lot more just from listening to you today. So yeah, thank you so much. And just a little note to our viewers out there — if you found this valuable, make sure to like and subscribe, as it really helps other publishers find this type of content as well. Thank you so much, James.

James: No worries, thanks very much. Have a great day. See ya.

This is an edited transcript of AdThoughts, produced by Publift. The words are Naomi and James's own — lightly edited for readability (filler words, false starts, typos, punctuation). No claims have been rewritten or generated by AI.

‍