Transcription
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. 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 conversion 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 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. 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, 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. At 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 WebAssembly-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 Vercel that we really like, there's other solutions in the field, too, is based on the concepts of real user monitoring. So Vercel Analytics, which works with Next.js, Gatsby and Nux.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. That was an awesome talk. Thank you so much, Lee. Let's discuss the results of your poll. So it looks like it's like pretty much 50-50 right now or exactly 50-50. Yeah. I think it's always incredible to me to see these polls and to get feedback on the assumptions that we may or may not have. I think probably more people have heard of Web Vitals than I thought, but still so many people who haven't, so much room for opportunity in educating others and helping them understand these changes to Google. Yeah, for sure. For sure. I teach a blogging workshop pretty often and do it as a conference talk. And I always am like lighthouse test, lighthouse test, lighthouse test. So total record there. Really great talk. Oh, wait, now it's at 54-46. This poll is too funny. Okay, cool. So we've got some questions for you. The first one is Next.js is gaining a lot of traction. It's amazing. It's one of my favorite things to use. And can you explain why? What is its most important feature? Yeah. So my opinion is Next.js' most important feature is what I like to call its hybrid approach. And really what I mean by that is over the years of developing, I've switched between frameworks quite a few times as new things came out or new solutions emerged and throughout my career as a web developer, I've learned about all these different ways of building high quality web applications. And the great thing about this hybrid approach that Next.js offers is it tries to be really to give you strong opinions loosely held. And what I mean by that is we don't want to be too over the top on the options that you can choose for rendering your application. Maybe you want to do a completely static site. Maybe you want to involve a server a little bit. It's really up to the developer to have those tools and to be empowered to make those choices such that they don't have to break out of the bounds of the framework when they need to do something that maybe is just a little bit off course of what they're doing before. And I think this is the most important thing because it's empowering developers to make choices that help improve the performance of their application and ultimately a better user experience. Awesome. Awesome. And definitely has an amazing developer experience as well. Just want to shout that out. So what are you most excited about that's been recently released for Next.js? Yeah. So the past six months of Next.js have been really fast paced. It's been great. It lasts, well, I guess it's longer than six months now, but last October we released Next.js 10.0, which had some really exciting things. Some of the things I talked about today, like the image component and automatic image optimization, trying to help put performant defaults inside of the framework as well as analytics and a few other things. And then just a few weeks ago, we released 10.1, which really the focus of Next.js in the past, let's say three to four months has been on performance and security and reducing the bundle size, reducing the number of dependencies, trying to make it as optimized as possible. And 10.1 came with some really amazing improvements to make it faster to install, less dependencies, which is great. We all want less node modules. It makes the world a better place. And overall getting support for things like M1, Max, and trying to build a platform for even more features where we're really trying to iterate on the local dev experience. And what I mean by that is we want to make it feel as real time and as performant as possible. So with 10.1, it's now three times faster when you're doing hot module reloading or React fast refresh for React locally. And we're working to bring it up to 20 times faster here pretty soon. So I'm super, super excited about this. I think it's really going to help people's developer experience working with Next locally. That's awesome. We have a question from Darren Reed, and it is, what is a good starting point or reference for Next.js? Yeah, in my opinion, the best starting point for Next.js is nextjs.org slash learn. So the way that the documentation is structured is it tries to be as to the point as possible and serve as a reference. And then slash learn is really more of the walkthrough course or the introduction for beginners and it will take you from essentially zero to having your own kind of blog built with Next.js. So it's doing that understanding some of the core concepts of the framework. And the way that we built it was we added some questions at the end to make it kind of interactive like a quiz so that you can basically reaffirm that knowledge and understand that you're learning it. And really, I'm really excited because right now on nextjs.org slash learn, there's just really one course, but we're adding a bunch more here soon, which is going to be amazing. So I would check that out. Oh, that's awesome. That's awesome. The getting started guide is really cool. I love the interactive questions. It reminds me of checks for understanding, which is like a teaching concept. Another question is Niz wonders, they have an e-commerce site with Magento. Should they switch to Vercel and Next.js? That's something that I actually didn't talk about with Next.js 10. But we so for a little history here, we see a ton of people in the e-commerce space adopting Next.js. And because of that, last October, we released this thing called Next.js commerce. So nextjs.org slash commerce, which is a it tries to be an all in one kind of starter kit for building a high quality, high performance e-commerce kit. It currently has support for big commerce and Shopify, which support for Magento coming soon as well, or other other back ends that we can plug in there. It's basically designed in a way where you can use whatever headless commerce back end you want and plug it into an agnostic front end that has these data hooks. So my recommendation without knowing more would be, it really depends. I never like to recommend just drop everything and switch because that might not be in the best interest of your company, but it's worth checking out. Maybe you'll like it. Yeah, that's a great answer. I feel like it's always it depends. Question from Rosenmoon, how do you measure real user experience points in Vercell? Yeah, so we have a little algorithm, which is probably too fancy of saying a formula that basically takes in all of the different core web vitals and assigns them weights and rankings. If you go to vercell.com slash docs slash analytics, I can put a link in the discord, but it breaks down exactly what's inside of this formula. It's basically our guidance on trying to give you a single number that makes up this real experience score. So it tries to give you just an overall pulse or health check on how things are going, such that when you come in there, and if it dropped from, you know, 95 to 90, you can look at the commit and say, okay, I think I know what might have introduced this, you know, we made some major changes to the homepage or something. Cool. Cool, this one's from popling gay can scrolling be considered as first input? Yeah, okay. So referencing first input to like core web vital is scrolling considered one of those inputs. That's a really good question. I don't know, with 100% certainty, but my, my guess would be no, because I would think it would be like actually clicking into an input, or, you know, entering in some information. I don't know if when you're blocking the JavaScript thread, or when you're trying to execute some code, I don't know if you can get to a point where you also can't scroll because you're blocking. My guess would be no. But I'll have to double check that. That's a great question. Cool. Cool. This one's from IAC. What does Vercel have built in that improves performance? Yeah, absolutely. So I didn't talk too much about Vercel. But Vercel is really a platform for it was built to deploy Next.js sites. And it really what it gives you is a collaboration for, you know, working with your team to deploy your sites, and then you deploy it to our edge network, which just fancy word for a CDN to deploy your application across the world. And out of the box, you get a lot of cool things like, you know, HTTPS and SSL. So good performance, compression, you know, fast responses from all the different regions, things that you would expect from CDNs. And another thing that's great is just the team at Vercel is also the team at Next.js. And I'm really, really excited working with some really incredible engineers there who are making that performance better every day. Cool. Have one from Ironman. So I have integrated GraphQL and Next.js together with Apollo. But I was wondering if something that you may support natively in Next.js installation. So it sounds like if there's a GraphQL starter for Next.js. Yeah, so this is great to talk about how Next.js thinks about data fetching. So the methods that Next.js exposes for user to fetch data are unopinionated about where your data is at. So we give you these hooks to say, do I want to go fetch from WordPress? Sure. Do I want to use REST? Sure. Do I want to use GraphQL? Sure. To kind of provide that decoupling between what you want your front end doing and what you want your backend doing. So you can use Apollo, you can use GraphQL requests, you can use whatever libraries you want here. As far as the good starter for using GraphQL, inside the Next.js GitHub repository, there's an examples folder. And we have, I think, probably four or five different examples doing different things with GraphQL. There's one with Apollo. So I would recommend checking that out for some real examples. Awesome. Paula Stanislav asks, any insights into how much the ranking will be affected by performance? Would like to sell it to management? Some comparison would help. You know, I wish. I wish that everyone knew. The reality is, this is, in my opinion, this is kind of the first insight, really, that we get into the Google black box of page rank algorithm. It's awesome to me that Google's essentially saying, if you optimize the performance of your site, given these three main metrics, and you have a performance site, we can't tell you exactly how this magic works, but we can tell you that you're going to rank higher. So it's finally a little bit of clarity on what we've all thought for a long time, which is, hey, a better performing site should provide a better experience to users. So I wish I knew, but. Yeah, none of us know the Google search algorithm, other than the people who work on it. And I would guess that probably a lot of them only know pieces of it as well. Oh, yeah, for sure. Chris Rojas, and this is the last question, asks, what are some of the main differences between Next.js and Remix.js? Yeah, there's a chat or a breakout room, I think, about Remix.js specifically here that Ryan and Michael are in, I think, or involved in some regard. But Remix.js is a framework for building JavaScript applications, very similar to Next.js in a lot of ways, but they also take some differences. I haven't used it personally yet. So I don't have too much of an opinion to say, but I know that they're both really great engineers and doing lots of amazing things. I love how they did their funding model for the framework. So I would definitely check it out. I think they're going to release their docs open source soon. So that should be a good place to read more. Yeah, for sure. I think that Michael talked yesterday about it, actually, on this track. So you can go watch that video and potentially join in the conversation on Discord as well. Well, thank you so much, Lee. This was a great conversation and a great presentation as well. Yeah, thank you so much for having me. I really appreciate it.
