 Hi, everybody. I hope you're enjoying the speakers so far today. I got to confess the next speaker actually intimidates me a little bit. Tom Kaepern intimidates me mostly because he's smarter than I am. He has very strong opinions about SEO, but he's very fun to argue with. Tom previously worked for years running the consulting arm of Distilled in London. Now he heads up search science teams at Moz during research and working with Moz's next generation of tools. Today he's talking about Core Web Vitals. If there has been a topic that has dominated SEO for the past year, it has been Core Web Vitals. But the problem with that conversation, it's been lacking a lot of actionable insights. So Tom's been diving into this to figure out what we should actually do with Core Web Vitals to see measurable results. His talk is titled, The Fast and the Spurious Core Web Vitals in SEO. Please welcome the smartest guy in the room, Mr. Tom Kaepern. At this point you may be thinking that you've heard everything that there is to be said about Core Web Vitals. This tweet is from my colleague Cyrus and this was way back in February months ago at this point. It's now been over a year since we first heard about this update from Google and since we've known that it was coming and what it was going to be about. And yeah, as he says, I'm physically unable to tweet one more word about these damn Core Web Vitals. I don't want to lose you straight away though. I'm going to try and give you a slightly different perspective. What if I told you that Core Web Vitals and this update are a bluff? Google is bluffing. However, your business is at stake here or maybe your boss or your client's business is at stake here. So you can't exactly afford to call the bluff, but you can sort of cheat. Is that more interesting? This is what we're going to talk about today. The flaws of Core Web Vitals, then why they're taking such a ridiculous amount of time to roll out still and then does it matter and what to do next? So firstly, the flaws. You've probably seen this graphic by now. This is from Google's original announcements or, well, from one of their 2020 announcements. I'm going to talk briefly about each of these three new metrics and why I think individually and taken together they actually have some rather large holes in them. So firstly, largest content. So this is the one that's kind of closest to a traditional site speed metric, right? This is how long it takes the largest element on the page to load. So if I take a page like this, what's the largest element is the first question we're going to ask, right? Because that's what it's going to judge. It's going to be how long it takes the largest element on this page to load. So what is the largest element? Well, intuitively, we might think it could be one of these two hero images or maybe one of these chunky text blocks. Now, if the text loads quicker than the images, we might be kind of incentivized to make the text larger, right? Because we would want the quicker element to be identified as the largest element. And that's kind of perverse incentive. That's probably not improving the page really, but it would improve this metric. As it happens, there are a lot of tools out there that will tell you which the largest element the page is according to this method. Which element you're going to be judged on by this metric. MozPro is one of those tools, and it turns out that it's this block at the top. This is the element that your large content page will be judged on if you are the Moz blog. Not that intuitive, right? What about this e-commerce page? I think probably I would guess it was this. This is, I think, an AMD advert. But it's actually this. The cookie overlay is what Google will judge your largest contentful paint on for this page. And is it fair to compare either of those with a page like this? So on this page, the diagram is kind of the very important key element of this page. And if the diagram's not there, then the page is kind of worthless. It's completely dominated. Now the largest item on the Moz blog page was not that important to the page. But the largest element here is. So is that fair, really, to compare the two using the same method? What about first input delay? So this is how long it takes from the user's first click, which is at their discretion, on an interactive element to when the processing happens for that click. So it's not how long it takes for the page to actually update, or the browser to update in response to that processing. It's how long it takes for the processing itself. And this only counts at click events on interactive elements. So it does not account for scrolls or zooms or that kind of thing. So again, if I wanted to optimize the Moz blog homepage for first input delay, I've got some kind of weird incentives going on. Those two big hero images that I highlighted before, those are both links at the moment. They're links to the blog posts. And obviously the user is quite like to try and click on them. So if I made those not links, then when the user clicked, nothing would happen. So the clock wouldn't start for measuring first input delay because the user hasn't yet clicked on something. They've clicked on something that wasn't a link. So as far as first input delay is concerned, they haven't clicked. So removing these links from these images would probably improve my first input delay metric. Again, rather at the expense of user experience. Similarly, I could make the titles of the blog posts absolutely tiny so that in order to click on them, my users have to sort of brush off their call of duty skills and get that precise click. And again, that's going to be pretty bad for user experience, but it should improve this metric because by the time the user has managed to click on these obscure elements, the page is going to have finished loading so they're going to get a much more reactive experience sort of. Or maybe I could put this big call to action at the top, which actually isn't a link but looks like one. Again, to base out their click and by time while we're waiting for the page to finish loading. All great ways to improve your first input delay by ruining user experience. What about cumulative layout shift? This is your maximum change to the layout of the page within a five second session window or so it's called. This is session not in the same sense that it's used in any other Google technology. Confusingly, it's completely different meaning of the word. But it's the maximum change in this five second duration. So if you have annoying pop-up maybe to collect your user's email addresses or something like that, then you definitely want to make sure that that's 20 seconds after page load when they're halfway through the article because that's not annoying at all, right? But it would improve this metric. Now clearly I'm being silly. You shouldn't do any of these terrible optimizations that I've just suggested to you. But my point is doesn't this all feel a little bit unwieldy? To compare two pages based on these kinds of factors, it's inevitably a bit of an Apple to oranges comparison. And that's not even getting to the data issue. What if all of this data that Google is going to use to judge you on for these metrics is based on real users using Chrome in what's called the crux database. So what if the page that you're trying to rank with doesn't have enough traffic yet to be in that database? What if your whole site doesn't have enough traffic to be in that database? Google have said that they'll try and aggregate based on similar pages. So presumably they'll judge a new page based on pages on the same template on your site. But what if your new page is on a new template? Or what if it's a new website altogether? Or what if you just don't get much traffic in general right now? Maybe that's why you're trying to do SEO in the first place, right? Maybe you're just not eligible for the boost in that case. Seems harsh. So hold all of those flaws, all of those problems in the back of your head for a moment. Because now we're going to talk about a very related topic, which is why this is all taking so long to actually roll out. So I'm going to take you back to the original announcement. May 2020, Google said this update is coming and it will be in 2021. Okay. Then in November they said, well, actually it won't be until May. Okay. And then a month before that new deadline they said, oh, well, hold up, we're not ready. It'll be at least June. I mean, fair enough, I guess we've all been there. But it didn't stop there. In May, they started backtracking what they said in the first place. In May 2021 this is the second May, they started backtracking. Because in the original announcement they said, if a page hits the recommended targets for all three metrics, so if you meet a certain threshold that they've set for performance, all of these metrics, then you would pass the assessment and you would get a boost. And they sort of said that twice on the same page. This wasn't a typo or an accident or something. But then in May 2021, they said something slightly different. They said it is not the case that unless you reach the good threshold for all of the Core Web Vitals metrics, that you have to reach the threshold to get a ranking boost. And when they issued this clarification, they said something like, oh, we've noticed some confusion. Well, yeah, you will notice some confusion if you directly contradict yourself. It's not too surprising, is it? But then in the same statement they said, in fact, it's kind of the opposite. You'll get a ranking boost for reaching the good threshold for all pages, presumably for all metrics. But these are not kind of the opposite. They're the same. So you've, yeah, issued a statement, the contradicts your previous statement, and then in the same statement, you've contradicted the new one. Great, okay, crystal clear. And then about the same time, now we're going to get a ranking boost if we just improve our speed, but don't hit the threshold. Presumably separate to the other ranking boost you just said would get if we did hit the threshold. Great, okay. I'm not going to try and pull these apart and do the chronology to figure out exactly what's meant by all of this. But my point is just to ask the question, why is there the need to constantly clarify, update, amend, delay? Why have they not made their minds up and decided how this is going to work and told us? Given that that seems to be what they're trying to do. To answer that question, I'm going to take you on a brief tangent into a thoughts experiment you may have heard of, which is called the Prisoner's Dilemma. So this is a situation, a hypothetical situation where there's two partners in crime who are in a prison cell together and they're going to be taken out of the cell one at a time to be interviewed in private. Now if they both confess in their separate private interviews, then obviously they'll both be found guilty, but they'll both get somewhat lenient sentences because they both confessed. On the other hand, if only one of them confesses or the one that confessed obviously incriminated the other one and was cooperative so they'll get an extra lenient sentence in fact they'll pretty much go away scot-free. But then the one that didn't confess while they were found guilty and they didn't confess so they can get a very harsh sentence. Obviously similarly if it's mirrored the sentences will be mirrored. But then in a scenario where both of them remain silent or they can't be convicted at all now the system is still a bit suspicious of them at this point so they both do remain in prison but only for very minimal sentences. So if you're one of these prisoners and you don't know what the other prisoner is going to do you can't collaborate. What are your incentives? This is kind of the bottom right cell here this is the optimal outcome, right? For the group as a whole. On aggregate. But the trouble is both prisoners face the risk of the other confessing they want zero years for themselves. So if I am one of these prisoners and I stay quiet the potential outcomes are either get one year or 20 years. But if I confess my potential outcomes are either zero years or five which is better in either case. So I'm going to confess, right? But the other prisoner is facing the same situation so they're going to confess as well. So we end up here. We're in the cell in the top left which is worse in every sense because it's coming from the bottom right. And it's kind of inevitable. And the idea is that this game is impossible to win. They cannot trust each other or cooperate when only one of them is in the room so they always lose the game and the system always wins. This is kind of like what's taking place with Core Web Vitals. We all know now, we have done for some time that when Google announces ranking factors like these it's because they want to use SEOs as a lever to change the shape of the web. So we've seen it quite a few times with HTTPS, with mobile friendliness. But ultimately it's a bluff. Google cannot roll out changes that reduce the quality of their search results. That would undermine them totally, right? So they're relying on all of us SEOs actually being manipulated and cooperating at the same time because you've been incentivized to do so. We are the prisoners here. If my competitor even might improve their site then I have to improve mine as well. Even though if both of us did nothing rankings would be the same as if both of us invested that effort, that cost. We ultimately can't guarantee that our fellow SEOs will not improve their sites. That's the theory that Google is going on. So they have made it extra hard for themselves. Remember that Web Vitals as opposed to Core Web Vitals is actually seven metrics four of which were already ranking factors. So if we understand Google correctly perhaps in some of those earlier statements depending how you read them you would actually have to pass all seven metrics for a boost. And it's possible that a lot of sites were already getting boosts for some of them but now wouldn't because they didn't do the top ones. So Google is in a situation where they could degrade their results. Basically Google has said if most of you SEOs can improve your websites you'll do better than those who don't. And they're hoping that as a result we will all improve our websites. We'll all end up in the top left. But as a collective SEOs have somehow done the impossible and won the prisoner's dilemma through our combination perhaps of ineptitude or maybe laziness or probably lack of executive buy-in we've won the prisoner's dilemma. We've ended up in the bottom right. So I want to back up this claim with a bit of data. So I took a look at the Mozcast corpus. So Mozcast if you're not familiar with it this is a corpus of 10,000 keywords where basically Moz reports on algorithm fluctuations and features coming and going based on 10,000 reasonably competitive keywords that are regularly recalled. I decided to take all the URLs ranking top 20 for a keyword in the Mozcast data set and see what was up. Now it turned out that only 30% of them actually had crocs data which is surprisingly low when you consider like I said that these are ranking top 20 for fairly competitive terms. And then of those 30% I was curious how many had actually passed? How many were eligible for a ranking boost? Initially I was quite impressed at 53% ish met the threshold for cumulative layer shift. 48% did for largest contentful pain. 88% met the threshold for first input delay. I'll probably publish more of this data over time with benchmarks and updates and ranking correlations and so on so look out for that but in this case I was mostly interested in how many were meeting all of these thresholds and it turned out although 64% ish were meeting 2 out of 3 less than 30% were meeting all 3 so now we're in a situation where 30% of URLs have the crocs data available at all and then of that 30% only 30% actually pass and are eligible for the boost. That's pretty tricky for Google we've seen this before remember how mobile get in seemed a bit of a non-event with so few URLs passing to be eligible for the boost this time we might end up looking back on this similarly or maybe it'll be like medic where they roll it out it seems to make the results worse perhaps later they pretty much roll it back to how it was before Google have alluded to this too they suggested oh it's going to be a tiebreaker they tried to downplay it although like my former colleague Will Critchlow I sort of don't buy that I think in a system as complex as Google was ranking out with them you can't really ever have a tie so if they're literally true and it's a tiebreaker I think it will do nothing but either way they're trying to downplay this so having said all of that having sort of downplayed and criticised everything about the whole system and suggested it's flawed and silly and a bluff am I suggesting you just shouldn't care well maybe not quite when I was looking at that MOSCAS data I also looked at the impact on ranking although maybe that's a bad way of putting it because I actually looked at the average difference in rank whether that's an impact because URLs which passed that small quantity of URLs that passed the assessment based on their crux data they ranked on average 2.3 places higher than those that didn't that's kind of if you do pay attention to your ranking factor studies you should be careful here because this is kind of flawed because in order to get this data in the first place based on crux data you have to have crux data which means you have to have traffic which means you probably already rank highly indeed URLs that had crux data at all regardless of how well they performed were already ranking 2.8 positions higher on average than URLs that didn't which is kind of inevitable right that's how they got the data in the first place but when I looked at the second one when I looked at URLs that passed the crux assessment controlling the availability of data there was still a positive impact they still ranked on average 0.4 positions higher and that doesn't sound like a lot but if I said to you oh you can rank half a position higher for all of your keywords I think you'd bite my hand off and incidentally that's a larger impact than being in the top 50% of pages by speed and it's also a larger impact than a lot of link based factors considering all of that if we zoom out a little bit and look at Mobilegedon like I said before sure it wasn't a big thing at the time but would you really launch a few years later in 2021 would you really launch a desktop only website or even an m.site it's got to be better to be ready for the future right on top of that there are plenty of other reasons to worry about speed there have been numerous correlations over the years at this point showing that numerous studies I should say showing there's a correlation between pages being very fast and then converting well and then there's a reason that you probably weren't thinking about which is Google Discover so this is the personalized article suggestions you see when you open the Google app or the new tab screen in Chrome on mobile it's a huge truck opportunity that SEOs are sleeping on at the moment basically every site I've seen that's taking Discover even remotely seriously is getting more Discover traffic than they are organic it's also incredibly responsive to site speed to such an extent I've often seen it written or I've seen SEOs advising that Discover is AMP only it's not AMP only at all it's just that if you're not a massive household brand national publisher you probably need to have AMP levels of site speeds to compete here this is an example of what I'm talking about this is traffic from late last year from a site with a domain authority of around 30 that was getting hardly any organic traffic this is a stacked chart so you can see that tiny purple sliver the thickness of that is the amount of organic traffic they were getting which is virtually none but they were getting hundreds of thousands of Discover hits per day and this is what happened to them in the December 3rd algorithm update and then that recovery afterwards that you can see at the end of the graph that was then when we started to fix some of their site speed issues so to reiterate Discover is a massive opportunity but it's incredibly and increasingly responsive to site speed and this is the future so that born in mind what should we do next well we just spent a good chunk of time I'm picking what on earth Google is doing I'm going to try and pick that into a few lessons and a few actions so what have we learned firstly we're going to want to prioritise our high traffic pages as cynical as it seems that is the game we're playing now secondly some of these metrics are not the most robust but we should not try to fix them at the expense of overall speed and experience so how are we going to go about those we're going to go through one by one prioritise high traffic pages I think it's worth briefly covering a key distinction which is between field and lab data so field data in this case means data collected in the field or data collected in in Chrome from real users and that's what Google is using lab data on the other hand is synthetic data that you might collect externally it's more scientific but it may not be as representative so the field data is more representative it's exactly what Google is using but it sometimes makes unfair comparisons based on arbitrary user devices and so on and the lab data is viable for staging sites new pages etc etc which field data obviously isn't and then you can if you use a Google methodology for your lab data it starts to look like the more useful of the two so for my personal site for example the field data doesn't exist but I can still look at lab data then if I look at a site like moz.com which has a mix of high traffic and newer pages I can still use lab data so this screenshot is from moz pro and you can see I'm prioritising by traffic level and comparing higher and lower traffic pages side by side I can then look at aggregate scores within maybe a template or certain groupings that might contain high and low traffic pages together then we need to optimise the metrics so there's some less obvious methods that are open to you for cumulative layout shift like we said this is the maximum change in a 5 second window so this is a screenshot from reddit while it's loading and you can see that even though the content at the top isn't there they've got blocks that hold the place so when the content does load it doesn't rearrange the page at all you can also move unstable elements beneath the fold this is an example from the Guardian don't worry about the tiny text I just want you to track the layout as this loads so you can see this tweet comes into view and then there's this advert as well that rearranges the text yet again but all of this is beneath the fold so the cumulative layout shift metric for this page is 0.05 which is well beneath the threshold this would pass that test despite all of this movement you could also in an extreme case even though the elements were already all together but I wouldn't really recommend that then there's largest content for paint so obviously like we talked about at the start the first thing you need to do is identify which element is actually the largest again this is a Moz Pro screenshot but there are ways you can do this if you were having hero images imagine if the Moz blog had a big hero image at the top that was the largest element and that was slow to load if you were on the fence previously about whether to have a hero image this might push you over the edge on that and then of course similar to what we talked about before you could drop large elements beneath the fold so they don't affect this and then the last metric is first input delay this is the weirdest one really because this is about humans this is about when the human decides they need to click so on a page like this that we looked at earlier a human kind of needs to click immediately to view the page so it's going to end up with a delay because they're clicking while the page is still loading obviously I'm just scratching the surface here with what you can do with some of these metrics you can make a heavy presentation about just that but sometimes it's difficult to know where to start and I think it's worth trying to identify the metrics you need to fix and then tracking your or then matching your fixes and your opportunities onto the metrics you're targeting so we tried to do this a little bit in Moz Pro again and sort of let you know that if layout shift is your weak point you can prioritize the issues that are likely to impact that but we'll also show you which elements are actually causing those issues however with all of this like I said before we can't be doing it at the expense of more holistic or user experience focused improvements Google have actually said that over time they plan to incorporate more and more metrics and signals each year so I think you need to make sure you have a holistic approach here you need to make sure that you're not just gaming a few metrics that are currently included and that you're tracking absolute speed alongside these new metrics that's what we're doing and that's what we recommend you do as well thank you and that's all from me