Next.js — The Hybrid Architecture (SSG/SSR) for Web Developer Modernization and Scaling React

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 deploying 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. We'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.

So, 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 saw, 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 any algorithm update? Because I woke up today and for some reason, you know, my, 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 in 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 web dev 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. 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 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 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 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 OK. 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. 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. When I say this, I mean generating some HTML in advance on every page from the server. Rather than doing some computation on the client side, the initial request that comes with the server is including the markup on the page. 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. 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. 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, you might have heard of static site generation. 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 an 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 BlurUp 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. 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. 82% of webpages 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 the 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 notice 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 lighthousemetrics.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 2, 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 concept of real user monitoring. So Vercel 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 dash lines. These dash 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 infected, negatively affected the performance, if we did, we want to revert that and go back to times when our performance was better.

Now, 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 I'm like lighthouse test, lighthouse test, lighthouse test. So total record, record there. Really great talk. Oh, wait. Now it's at 54-46. This poll's too funny. OK. 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 it's 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. 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, and some of the things we're going to be talking 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. 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.

We have a question from Darren Reed, and it is, what is a good starting point or reference for Next.js? In my opinion, the best starting point for Next.js is nextjs.org.com slash learn. The way 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 walk-through course or the introduction for beginners, and it will take you from essentially zero to having your own blog built with Next.js. And while 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. 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 learning sergeant 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 Vercell 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 Next.js.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 BigCommerce and Shopify, which support for Magento coming soon as well. Or other, you know, other backends that we can plug in there. It's basically designed in a way where you can use whatever headless commerce 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 wouldn't, I'd 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 Rosen Moon. How do you measure real user experiences 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 actually 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 such that when you come in there and if it dropped from 95 to 90, you can look at the commit and say, OK, I think I know what might have introduced this. We made some major changes to the home page or something. Cool.

Well, this one's from first input. Yeah, OK, so referencing first input to Lake or WebViddle is scrolling considered one of those inputs. That's a really good question. I don't know with 100 percent certainty, but 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 and actually 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.