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 is 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. So I'll 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 why you 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, you know, my SEO was off the charts. I was getting so many more clicks in Google Search Console, seeing the converging 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. So 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. And 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. So we want to aim for an LCP of under 2.5 seconds, ideally. And there's more information in the bottom right of these slides if you want to learn more and go more in depth. So an example of this, just to really show what this looks like, is for a 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. And 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 is 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 the 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 the performance of our sites and in turn have better SEO on our sites. So we understand what the metrics are. How do we actually improve the performance of our website, improve these core web vitals? What are some practical strategies? Everything I'm going to talk about today is agnostic to whatever framework or tooling choices you want to make. But I'm specifically going to talk about Next.js because it allows you to more easily implement some of these suggestions out of the box. If you haven't heard of Next.js, that's okay. It is a framework on top of React that many companies, some of these you've probably heard of from the likes of Apple to Nike, DoorDash, TikTok, Netflix, lots of awesome companies use Next.js to run React in production. So they're using Next.js because it's helping simplify them getting better performance and better SEO. The first one I want to talk about is pre-rendering content. So when I say this, I mean generating some HTML in advance on every page from the server. So rather than doing some computation on the client side, the initial request that comes with the server is including the markup on the page. Now for anyone who has been doing web development for a long time, we're not reinventing the wheel here. This is how the web was born, serving that content from servers. But we have also explored in recent years doing things with client side rendering as well, too, when single page applications became more prevalent. The advantage of pre-rendering content is that it's able to be immediately indexed by Google, the Google bots, the crawlers on your websites. So not only is pre-rendering good for getting that content on the screen faster, better web vitals, it's also better for SEO. Whether you're doing this through static generation, so you might've heard of static site generation, Hugo or Jekyll in the past, and then even to more modern solutions today like Next.js, or if you're doing server side rendering, which is another thing that Next.js can handle. Another cool feature that Next.js gives you is called automatic static optimization, which essentially means that if I'm not making any blocking data fetches from my page, we can automatically optimize that to HTML. If you want to learn more, there's a link in the bottom right for a interactive tutorial. Next, you can optimize the images on your page. So there's a ton of images on the web, and we want to make sure that we're serving these up in the correct sizes and based on the device that the user is using. So first, we want to use the width and height attributes on an image to prevent layout shift. We're telling the browser, hey, here's how much space you need to allocate for this image. Number two, we want to lazy load these images as they enter in the viewport. So that when we land on a page, we don't want to load all the images below. I'll show a demo of this in a second. We want to use modern image formats like WebP and AVIF, same quality, but lower file size. We want to serve correctly sized images using source set. So source set is just part of the HTML spec for images, and it allows you to serve up different variations depending on the device and viewport that your user is viewing. And also, we want to provide blur up placeholders to make that loading experience a little bit more nice. So an example of this is, if you notice when I scroll down, you see these requests coming in the network tab, and I'm loading the images. I'm lazy loading them as I scroll. And you'll also notice that the type of these images is WebP. So when using this Next.js image component that's included out of the box with Next.js, you get this functionality for free and included. So let's just dive into this a little bit and look at a quick example. Basically you import this image component. You say, hey, here's a source, whether that's a local image or a remote image. Give it an alt tag. Tell it how much space to allocate or use a layout prop to have it be responsive, and you're good to go. But now I want to dive in just under the hood a little bit, because this isn't some custom JavaScript magic here. It's really just based on HTML. So there's three things I want to call out. Number one, you'll notice there's a couple wrappers around the image tag. So it's not a drop-in replacement for image. It's doing a couple extra things for you. It's making it automatically responsive and maintaining the aspect ratio. It is, and that's number one. And number two, you notice we have this underscore next slash image URL for the source. Out of the box, the next image component is going to give you automatic image optimization. So regardless of where you deploy your application, as long as you're doing next start, which starts up a Node.js server, we're doing web assembly-based image optimization out of the box. That's on the latest version of Next.js. Number three, there is the source set that we already talked about that serves up these different versions of our image based on the viewport. I mentioned that you can fetch images either locally or remotely, and the special sauce here is what we call either custom loaders through a loader prop or through the custom loaders we have already defined. So in this example, you see we have a loader prop, and you're able to change basically whatever service you want to be the optimizer for your images. Maybe that's Cloudinary or a similar cloud-based service. You can use those in conjunction with the next image component without having to change anything. Okay, that's images. Next I want to talk about optimizing fonts. So 82% of web pages on desktop use web fonts. You're probably going to use web fonts. It's probably hard to get around those just using the system font stack. So when you do, you really want to make sure that you're doing it in a performant way so that you have good Core Web Vitals on your website. So one, we want to use a variable font. It's going to have a smaller file size. We want to preload our font files to tell our browser that we want to load this earlier in the rendering cycle. We want to self-host instead of using Google fonts. We want to use font display optional to prevent layout shift. So let's dive into these a little bit more. As I mentioned, we can put a link tag in the head of our document to preload this font file. And like I said, we're basically telling our browser, this is important and we should fetch it earlier. Also then somewhere in our CSS, we're defining a font face. In this case, I'm using the font enter and we noticed that we have a font weight that's 100 to 900. So we have a range of different fonts here because we have a variable font. We have font display of optional, which is telling the browser, we don't want to have CLS. So if you can't resolve this request to fetch this font, then show the fallback font. So also ideally here, you have a fallback font that looks as similar as possible to whatever the web font is that you want. In this case, San Francisco is a good fallback for enter. So those are some practical strategies for how you can improve performance. But let's say you do all that. You need to also measure that performance to know that you've actually improved things for real users of your site and also improve your SEO. Most of us are probably familiar with a tool called Google Lighthouse. There's a few variations of this page speeds, insights, web.dev slash measure lighthouse metrics.com. These are tools that allow us to do simulated runs in the lab per se of our site and get back metrics on the speed. So when I say simulated, for example, I think we're looking at like a 3G mobile device in this example. This is how that device performs in the lab. These are great tools that help us understand not only the core web vitals that are shown at the top, but in the case of Lighthouse to digging into accessibility and progressive web apps and all sorts of other information. We want to use these tools, but then actually take it a step further as well, too. So one solution that we have created at Vercell that we really like, there's other solutions in the field, too, is based on the concepts of real user monitoring. So Vercell Analytics, which works with Next.js, Gatsby and Nuxt.js allows you to capture core web vitals and other performance metrics from real users who are using your site. So in this example, we're looking at the analytics dashboard. You see there's about 18,000, 19,000 data points for the last day in the last three hours. And we're getting kind of an overall health check of our site based on these vitals. On the right, you see this chart and you see these dashed lines. These dashed lines are deployments. So we're juxtaposing the deployment versus our score such that we can understand if a regression was introduced and if we negatively affected the performance. If we did, we want to revert that and go back to times when our performance was better. Now at the bottom, you'll notice that we also have a breakdown by the individual core web vital. We can also take this even further and break it down on a per URL level or like in this example with Next.js on a per page name level. So looking at even dynamic routes here for Next.js routes. This is something that we've been really thrilled with. One of our customers at Vercel HashiCorp that we're big fans of, shout out to HashiCorp. They use Vercel Analytics to track the performance of all of their sites. And it's really helped them not only improve that performance, but also the SEO of their sites as well. So in summary, by improving the performance of your website with the new changes to Google Search algorithm in May, not only will you have better performance for your end users, but you will also have better SEO. My name is Lee. Thanks for tuning in and joining. Feel free to DM me on Twitter if you have any questions. Thank you. Let's give Lee a massive round of applause. If you're listening, go into the Resonance Track Q&A and drop your biggest applause emoji. That was a really, really good talk. I really, really enjoyed it myself. And let's go and check out the answer to the poll that Lee asked us. So he asked, have you heard of Next.js and do you plan to use it in the future? I've just got the results up here. We've got people saying that they have heard of it, but don't plan to use it in the lead at 41%. But quite a few people have said that they either have heard and plan to use it or already use it. And when you add those two up, though, I think we can say that people who use it or plan to use it is in the lead, right? What did you think? Is there any surprises from that for you? That seems about right. I'd say that for certain people, it makes a lot of sense. And for other people, whether they prefer Vue or they prefer Angular or Spelt or something like that, there's always lots of options out there. So yeah. I think that's something which is so unique about the web space that we're in now is that we're spoilt for choice, right? But even among all those choices, there's definitely certain times where a certain framework or a certain way of doing things is just really fits your product better. Well, I just, this is a question, kind of a selfish one for myself. What would you say are the specific use cases where Next.js gets the opportunity to really shine and show its best work? Yeah, absolutely. So one thing it's kind of helpful to explain is that if you think about technologies like React or Vue, they're almost like the library level and they're giving you these APIs and these primitives to build on the web. But for a lot of people, they want an experience that's a little bit more configured out of the box for them, essentially like a layer of abstraction on top. And for React, this is Next. And for Vue, this is something like Next. And what these frameworks try to provide is automating away and giving you solutions to all the things you would probably need in your application anyway, whether that's routing or helping you have good performance or configuration for how you fetch data. Yeah, I think, I think... Sorry, go on. Oh, you're fine. I was going to say, so when you think about that, it's helping simplify a lot of the use cases for people spinning up these applications. And then specific use cases, I would say e-commerce is a really big one. We see Next.js used for ad-backed media sites. So news sites are very popular as well, too. And then also SaaS applications. Yeah, I think being able to sort of... I think it's really interesting how we've watched this JavaScript ecosystem and we've slowly seen systems being built on systems, right? And it's funny because when React first came about, it was like, oh, okay, this is a new thing. And now we're like, no, that is a low level. Like, there's now another layer of abstraction above that. This is why some people think we're eventually going to no code because there's so much abstraction on top of each other. But I definitely enjoy... I've played around with Next.js. I'm looking forward to being able to do it in a bigger project myself at some point soon. But we've got a question actually coming in from Mickey. He asks, how do you decide when to use Next.js rather than Gatsby or some other similar tools? What would you say is one of the big reasons why you're like, okay, I'm using this now rather than those? Yeah, absolutely. So first a little history on Next.js. When it started out, it was a framework for server rendering React applications. And then over time, it's kind of evolved to not only do server rendering, but to do static site generation as well too. And what we describe it now as a hybrid framework. Basically it empowers a developer to make the choice of how they want to generate their application with a pretty granular level, like a per page level. So maybe you want your homepage to be static and you want your newsfeed to have it up to date and rendered on the server. So when you look at something like Next.js and you compare it against some of the other solutions that exist, what Next.js tries to do is make it as flexible as possible as your application scales. So we kind of understand that while it might start out as just a small static site, as you add more and more pages and it grows larger and larger, the reality is you probably are going to need some kind of server rendering down the line. So we try to include all of that such that you don't have to switch frameworks or break out of the mold when you need to do something a little more advanced. Yeah, I just realized I needed to correct myself. I said I've never used it on anything like sort of big at work, but no, actually we kind of built a whole conference platform with Next.js and honestly, it was the first time I got to use it, I remember. And I loved it. I loved it so much I went and did some experimentation on it by myself and it was, I really enjoyed sort of the way it all came together and it made it really easy to build with. I think for me, that's something which I find unique. And I guess especially for you working in DevRel, seeing developers enjoy building with the product. And a kind of question for you, this is not necessarily a technical question. So please indulge me for a little bit. But as you work in DevRel for Next.js, you get to see people from all different skill levels working with Next.js. And what would you say are some of the things, the benefits maybe when you're speaking to someone who's just getting started with web frameworks, trying to still figure out what their best one, and then maybe someone who is sort of the lead engineer on this massive e-commerce site. When you're trying to sort of tell them the benefits of moving across, what are the different ways you pitch that to someone who is talking about all of this skill and maybe someone who is just trying to learn and get started? Yeah, absolutely. So for people who are just beginning their web development journey, one of the biggest benefits or one of the biggest frustrations I'll start with is when you get stuck and you realize I have to npm install some new package, or you get stuck and there's not a clear solution that's defined in the documentation on how you progress forward, and you have to kind of stitch together different pieces in the ecosystem. I think when people get frustrated about things like that, what they're really looking for is a more integrated framework that's giving you an all-in-one solution or as close to that as we can get. So what Next tries to do for beginners is say, we know that as your application grows, you're going to need some of these things. You're going to need routing, you're going to need styling, you're going to need to fetch some data and put it somewhere. So we're going to give you a solution that helps you do all these things in one place, such that you don't have to go all over the place and read a bunch of documentation. It's hopefully intuitive enough through just going through nextjs.org slash learn to kind of understand how to build your own application from zero to something. So that's kind of beginners. For advanced users, we use Next.js for pretty much everything that we build and Vercell.com as well, too. So not only Vercell customers, but our own internal stuff, we are using Next.js at a really high scale and a high level. So because of that, we've been able to understand how to optimize and how to get great performance and take those learnings and put them back in the framework. So one of the things that we've been working on really heavily is giving tools to developers to automatically optimize things for them. And the three main things that we're working on is fonts, images, and scripts. And these three things can have a massive impact on the performance of your website. And by putting these optimizations directly in the framework and making it easy for people to use, in turn, it helps advanced developers create a faster web. I really love that take. And I think you spoke quite eloquently when you spoke about the fact that a lot of times of some frameworks, you 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 first got started and first started to pick up sort of popularity? Whereas now, 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, like 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 dynamic 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 so much sense. And being able to sort of extend that use case for a whole other set of developers to make their lives so much easier, I can definitely say I appreciate that myself. And we spoke about where Next.js has 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. I'm very excited about that. Would you get in trouble if you drop us a sneak peek? I will say that it's going... No, no, no. 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 heard 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 Lerob Lee with three Es. Rob. Lerob with three Es. Definitely check him out on Twitter and definitely reach out. Thank you so much for hanging out with me today. I've really enjoyed it. I've really enjoyed learning. And I hope I get to see you soon and get to see you in person at some point. Absolutely. Absolutely. Thank you so much. Thanks for having me.