How Core Web Vitals Will Affect Google Rankings in 2021

Hey everyone, thanks so much for joining me today and I'm really excited to talk about how Core Web Vitals will impact Google rankings in 2021. My name's Lee and I am a solutions architect at Vercel, and I lead DevRel for Next.js.

If you haven't heard of Vercel, that's totally okay. Vercel is a platform for developers and it empowers them to build great websites. If you haven't tried it out, I recommend going to deploy.new and deploy an application in a matter of minutes.

But what we're going to talk about today is a little bit on these things called Core Web Vitals. I'm going to start with some background and introduction. I'll dive into these Core Web Vitals and how they'll impact your Search Engine Optimization, or SEO. I'll give some practical strategies for improving performance. And finally, after implementing those strategies, measuring that performance and seeing the changes that you've made.

But before we can do any of that, let's step back and do some background introduction on should care about web performance. Back in 2009, so going back a little bit, Amazon found that for every 100 milliseconds of extra latency, they saw 1% fewer sales. So they were able to tie performance directly to a business impact on their sales. And just to reiterate this point, if we look a few years later, Walmart, when they reduced latency by 100 milliseconds, it led to 1% in more revenue, and this was in 2012. So similar idea, similar results here. The bottom line is that better performance leads to better SEO, and it has a direct impact on your business.

I love this screenshot from the founder of Nomad List, saying, Did Google Search do an algorithm update? Because I woke up today, and for some reason, my SEO was off the charts. I was getting so many more clicks in Google Search Console, seeing the convergent rate from people coming from Google. So when you have better performance, like they do on Nomad List, it's going to ultimately lead to better SEO, especially now with the introduction of Core Web Vitals.

So how can we measure this actual user experience of people using our site? Google has cared about performance for a long time and they've given us many different tools to measure that performance. But when there's so many different tools, it can be hard to understand what are the most important things that I need to focus on and what are the quantitative measures to understand what's good and what's bad. So really a breakthrough was made when the Web Performance Working Group worked with Google to introduce these Core Web Vitals Metrics. We're going to talk about them here in a second. But really they help you understand how good your actual user experience is by focusing on the end user outcome, how they're actually perceiving your site. So how fast it gets in front of their eyes, if things jump around or not, how fast it reacts to input, and we're optimizing for the quality of the experience. So Google and the Web Performance Working Group did this research and they cited other research looking into HCI, human-computer interaction, to understand what are the most important metrics to look at. And that's Core Web Vitals. First, we have Largest Contentful Paint. So this is the perceived loading speed of your page. Basically the point and when the largest element comes in, typically something like an image or a video.

When you have a fast LCP, it helps reassure that your page is useful. It's getting paint on the screen or getting content on the screen quickly. As I mentioned before, these Core Web Vitals not only do they tell us the what, but they give us some guidance on what is good, what is kind of eh, and then what is not very good.

We want to aim for an LCP of under 2.5 seconds, ideally. There's more information in the bottom right of these slides if you want to learn more and go more in depth. An example of this, just to really show what this looks like is for Google Search. Let's say I'm loading a page that's searching for Larry Page. You see I have my first Contentful Paint, the first thing that I see on the screen, and then the largest Contentful Paint comes in shortly after that. Plenty more examples of this on the WebDev page as well.

The next is the first input delay. This is measuring the amount of time from when a user first interacts with the page. So clicking on a link, clicking on a button, or using some kind of custom JavaScript powered control. So the time between when they actually click and when the browser begins processing those event handlers. I think we've all seen a bad example of this. You click on an element and nothing happens when you click and you get frustrated and you click a bunch more times, it's just not great. We want to shoot for under 100 milliseconds, ideally to have those interactive elements. To kind of show this picture, tying this in with FCP, I know there's a lot going on here. So on the left, we navigate to a page essentially, and this is progressing from left to right chronologically. We navigate to a page, that navigation starts. We get some paint on the screen, and our browser's able to interpret that and understand that. And then you see in the middle, there's a point where the browser receives that first user input. So the time in between there and when it can actually respond is the first input delay. The other metric at the top is a summarization of all this, which is TTI, or time to interactive.

The next one to talk about, the final one to talk about is cumulative layout shift or visual stability. So I'm sure you've been on a website somewhere, and you're reading something and suddenly the content changes out in front of you. There's some kind of shift, maybe you lose your place or you accidentally click on something. This can be a really frustrating experience, and we want to aim to have as little layout shift as possible on our websites. So for an example of this, this is a really bad example. You're trying to go back, but it shifts in your layout and you accidentally place your order. This is a really frustrating experience.

We don't want this. This is what we want to avoid. An idea of how you could reduce CLS would be, like in this example, showing the Vercel dashboard, you'll notice that when it reloads, there's loading skeletons for all the content. And this means that the layout doesn't jump at all when the content actually finishes resolving from some API. So those are the three core web vitals, LCP, FID and CLS.

These are tools that will allow us to measure, understand, and then improve some frameworks. You've got the framework and then you need to go find this plugin or download this other thing to kind of make something which is pretty sort of standard in websites to work, but to have all of those things built in, I think that just makes the whole process and the whole sort of development cycle just much more pain-free.

And you've been working sort of with Next.js for quite a while, and you've seen the products, you've seen it sort of mature as time goes on? Has there been any sort of differences to maybe the way developers are using it or things that maybe were a certain way back in the day when Next.js just first got started and to pick up sort of popularity whereas now as much more developers are adopting it? Yeah, so one thing just to quickly go back on that's super interesting to me and then I'll answer that is the fragmentation of installing npm packages, especially in the react ecosystem, is actually a pro and a con at the same time. And that's why it's so difficult when you talk about it with people, because the fact that you can npm install react hyphen literally anything, somebody has built a package, is also the greatest thing and a confusing thing for beginners. So still having that community and that ecosystem and then also having more opinionated solutions is kind of the best of both worlds. So it's a tricky topic for sure.

But to your question, based on growth, what have we changed with Next.js? Well, I think one of the biggest things when I was talking about how it started out as server rendering, around this time we started to realize that a lot of people wanted to build completely static HTML with their React applications. They'd already understood the mental model of how to build a React application. They liked building components. It made sense. So they didn't want to have to switch to a completely different tool, just to also build some static parts of their sites. And what we did was kind of step back and we looked at that and we said, this is great. And now we want to make it even more dynamic, where we can choose on a per page level, which ones become static HTML, and which ones maybe have some kind of dynamicism built in. So when we rolled out static site support for Next.js, we made it such that opting in or opting out is on a per page or a per route level. That makes that makes so much sense and being able to sort of extend that use case for a whole another set of developers to make their lives so much easier. I can definitely say I appreciate that myself.

And kind of we spoke about sort of where Next.js has kind of come from. But what's next? Is there anything exciting? Maybe I'm a fan of Next.js. Is there anything exciting coming around in the future? Yeah. Yeah, so next week on the 15th, we're having the second Next.js conference. And we're going to be releasing something that's really exciting that could change how people develop with Next.js. So I'm getting in trouble. If you drop us a sneak peek. I will say that I'm going to I'll give you I'll give a one sentence sneak peek. It's going to make development more collaborative, more collaborative.

Well folks, you had it here first more collaborative. You can definitely check that out at the Next.js conference next week. Where can people maybe find more information about that? Yeah, if you go to nextjs.org slash conf, you can register for the conference next week. And if you want to check out anything I'm talking about, you can go to my Twitter, which is Lee Rob Lee with three e's Rob. Be Rob with three e's. Definitely check him out on Twitter and definitely reach out. Thanks so much for hanging out with me today. I've really enjoyed. I've really enjoyed learning, and I hope I get to see you soon and get see you in person at some point. Absolutely, absolutely. Thank you so much.