Next.js Conf – Special Edition
[intro music] Oh hey there! It's great to see our Next.js community come together again. When we released Next.js nearly 5 years ago, we had no idea how big our open source movement would get Working alone, no individual developer would be able to re-create what Next.js has become, and certainly not so quickly.
Next.js is the result of the combined work of over 1,600 community developers, industry partners, and our core team. Since we saw each other last October, the growth of our community has accelerated. In six months, we saw an increase of 50% in the number of Next.js downloads on NPM – from 4.1 million
to 6.2 million – we doubled the traffic to all sites and applications on the Vercel Edge Network, weekly deploys quadrupled, and the number of homepages built using Next.js in the Alexa top 10,000 grew by 50% – wait, is that right?! Wow, you’ve been busy. Well, after all, Next.js was built for scale. Whether you're starting out with a single static page or deploying dynamic sites with billions of pages, Next.js is a hybrid framework that meets you where are you are and grows with what you need. We believe that the fastest and most enjoyable end-user experience must go hand-in-hand with the fastest and most enjoyable developer experience So, what makes a great developer experience? For me, it's all about Real-Time Feedback. See, when I sit down to code and build my product, I want to see the reaction to my changes instantly. This was a priority in Next.js since Day One,
when we implemented webpack HMR with zero configuration. Later, we improved it by partnering with Facebook to bring their Fast Refresh innovation into Next.js. So, let's take a look at how it all works. Today, I'm working on a redesigned item page for our high-performance ecommerce starter kit, Next.js Commerce. I run the next dev command and my frontend project is ready to go on my machine. The browser reflects my changes as soon as I have saved a file. This not only works for styles, but thanks to React Fast Refresh, all state is preserved even as I make changes. Let’s make a change to something that impacts the carousel
I'll go to the last item, and notice that the right arrow is still showing. I'll hide it for now. But when I make a change, I see its reaction, and the carousel wasn't reset.That saves me a ton of time. Our mission to create the best developer experience is driven by a disciplined and measured approach. Since Next.js 10, we've been making steady progress towards improving critical DX metrics. First, we improved startup time by 24%. That’s the time it takes to start a new dev session cold, and start seeing my product on my screen. Later, we improved the processing time of your changes,
the time it takes from a change on your editor to seeing it on your screen. You've been getting these amazing improvements by just keeping Next.js up to date. Today, we’re introducing Next.js 11, with even more performance improvements. Seeing is believing, so let's take a look at how it works I'll turn on a debugging flag to visualize latency. Now, I'm going to start making a bunch of really quick changes. We can see that each time in
milliseconds Next.js processes my change and hands it to the browser engine for rendering. To make Next.js dev mode this fast, we're piggybacking on the continuous innovations of the Web platform.
We realized that leveraging the browser to drive the creation process was the key to speed. This opened up a very exciting innovation. Today, we’re thrilled to bring you Next.js Live, a revolutionary new capability that combines a brand new dev server engine for Next.js, with the Vercel platform to instantly share, comment, annotate, and even edit from anywhere in the world, enabling true real-time collaboration. Let’s take a look at how that works. I'm opening a Next.js Live URL that I can share with anyone with a web browser.
This works for both static and dynamic Next.js applications. Sharing and accessing this URL is always instant, no matter how many pages, because there's no build process involved. The best part, again, is that this URL is not just for me. I can share this URL with anybody in my team. To demonstrate it, let me send it to my collaborators for today. Oh! They're joining! That's great.
Participants are shown in this special toolbar over here that we add for Next.js Live sessions. I can see who's collaborating on the page, as well as their cursors and comments, allowing them to drive attention to different components. This works even for responsive sites on multiple breakpoints, because Next.js Live knows more
than just x and y coordinates – it understands your application on the React component level. A key ingredient of Next.js Live is this new development engine designed for real time collaboration. We overhauled Next.js to run entirely inside the web browser. By leveraging cutting-edge technologies like ServiceWorker, WebAssembly, ES Modules, everything that's possible with Next.js on your machine becomes possible in the context of a remote collaboration. We didn't do this just because it was possible; we did it because it's actually faster.
Oh and one more thing, Next.js Live works perfectly, even when offline, and its infrastructure is very efficient because it doesn’t rely on running any virtual machines, for yourself or your collaborators. Let's press Code on the Next.js Live Toolbar here to see it in action.
I want to change this Title component. As I type, my changes are applied directly in my own version of the page, and the incremental change is broadcast to my collaborators' browsers for them to apply. Finally, it's possible I don't know what change to make, or I'm just not the right person to do it. Let me point out a potential issue with the draw tool over here. These images feel a bit slow to load. Oh, it seems Lydia can help me with that! For sure, Guillermo. As we saw in the last conference, images are absolutely essential to performance, and one of the most common elements we use on the web. Let's see what the issue is.
If we look at the code of this page, it seems Guillermo used the vanilla, unoptimized <img /> element. While this technically works, the image is rendering, it's not as efficient, performant, or accessible. This will hurt our Core Web Vitals, the standard metrics that we use in order to measure a good user experience. In Next.js Live, I can quickly swap the HTML <img> tag to use the Next.js <Image> component instead. Since Next 10, it's as easy as importing it from the
standard Next.js image library. Images are often the largest part of web pages, especially in ecommerce. The Community has done a great job improving the Next.js Image component since it was released in October. Our focus has been on automatically applying the best practices and optimizing for each device viewport that the image is delivered to. Lighthouse tests provide lots of great insights for improving your loading performance. The Image component automatically addresses many of these
out-of-the-box, which means that by using it, you’ll automatically improve your app quality. Oh! It looks like the team is seeing the improvements already. One of the great optimizations of the Next Image component is its ability to automatically resize and compress images for each device it’s delivered to. This is done out-of-the-box in development when you run `next start`, or when you deploy to Vercel, which then offloads this process to its blazing fast Edge Network. The Community has taken this even further by adding support and partnering with Cloudinary, Cloudflare, Akamai, and Imgix. These are production ready and available today.
What’s more, we now support various responsive layouts and custom image optimization loaders, giving you control over the entire pipeline. Today, we are excited to announce some major improvements to how you can use images in Next.js As Guillermo mentioned, we always try to balance a great developer experience, with great results for their users. Let’s start with the developers. As of Next.js 11, you can now use the import keyword for the src. You can use this to refer to essential images that are part of your repository. Images with a set width and height reduce cumulative layout shift, a Core Web Vital. We've made this easier by automatically
setting those parameters for you for local images that you import. Next.js 11 also improves the end user experience. When a user first visits a page, some larger images might still take a while to load, even when optimized. This can result in a temporary blank space where the image is loading, which primarily affects users with a poor internet connection. To improve this part of the user experience and to ease the transition going from blank space to image, we're now shipping support for image placeholders on imported images. To get this beautiful effect, all you have to do is import your image and reference it from the src property in the image component.
We also support blurring for dynamic images by adding a placeholder attribute and providing a custom `blurDataURL`, provided by your backend. We worked hard to ensure that the user experience would be improved, with peak performance and minimal effort on your side. This is all possible because of the great feedback from the Next.js Community we're all part of,
and great contributors - especially Alex Castle and Joon Park from Google. Thank you so much! And good luck Guillermo! Thank you Lydia! We are shipping these image improvements in beta today with Next.js 11. Head to `nextjs.org/11` to try them. Because of its incredible performance, Next.js and Vercel are now powering the
new frontend experiences for pioneers like Zapier, GitHub, and Splunk. Next up, Shubhie will discuss how Next.js 11 systematically ensures that you deliver high quality apps. Thanks Guillermo. Even with great tools and automatic optimizations in frameworks, we have a problem: we are asking every site owner and every app developer to become an expert in UX quality topics like performance, security, accessibility -- we need to think differently.
In my last decade at Google, I've had my hand in building many different tools and frameworks. These frameworks have powered amazing apps, like Google Search, Image search, Maps, Google Photos. These apps have pioneered capabilities and pushed the boundaries of the web, such as with input auto-completion, gesture handling, and visualization.
The most important thing I have learned is that for developers to be able to achieve and maintain a high bar of app quality, the framework must participate and do the heavy lifting. At Google, we shifted this hard work away from developers and into the framework. This means every developer using these frameworks gets all of these solutions baked right in to every project they build. We also created rules and checks that serve as guardrails. These support the business and the product as features are added and as teams scale.
This is how a high bar of app quality becomes a side-effect of building for the web. At Google, we care about a thriving web, and we've realized that the best way to share our insights is to work directly with the Open Source framework ecosystem, and collaborate with the web community. Today, we work with some of the most popular frameworks such as Next.js, Nuxt.js, Angular. These tools have agency over the full system: from the client to the server, from the development to the production environments.
We also fund popular tools & libraries such as Vue, ESLint, webpack. The open source ecosystem enables modern apps to be built for the web along with great developer experiences. They empower companies & individuals alike, because building custom infrastructure is cost-prohibitive even for larger companies.
At Google Chrome, we are grateful to open source. Thank you. In our work with open source frameworks, my team at Google Chrome first focused on resources such as JavaScript, images, CSS. Each of these is a vast topic with complex challenges, but these are foundational optimizations for the web. In Next.js, we've shipped features such as
granular chunking, the polyfill chunk, the image component. We are working with Angular and Nuxt on Image optimization. We recently shipped Critical CSS Inlining as a default in Angular 12. I'm happy to see that granular chunking has become a default in webpack, which not only powers Next.js but many other frameworks.
These foundational optimizations power the trimming of bytes, the reducing of round trips, separating out what’s needed for first render, visual readiness, user interaction - such as by extracting critical CSS, or setting the priority attribute on Image. I'm excited for Houssein to introduce our work on Font Optimization in a few minutes. While we are developing these foundational optimizations, there are still a lot of right decisions that the developer has to make. Some optimizations are defaults and don’t require developer input, such as critical CSS inlining. Some require the developer to opt-in, such as using the <Image> component to properly size and scale your images And some require opt-in with customization, such as setting the priority on images for really important images. And finally there are some that aren’t features,
but still require the developer to make decisions, such as avoiding fonts that delay early rendering. Optimizations that require any decision from developers pose a risk to the app's performance. As features are added and as teams scale, even the most experienced developers are unable to keep up with best practices, nor is it the best use of their time. This is why today, I'm excited to announce Conformance for Next.js, a system that provides carefully crafted solutions and rules to support optimal loading. As a developer, Conformance means that you are free from having to memorize lots of complicated rules for loading performance and keeping up with the changing landscape.
You can think of Conformance as a compiler – like Typescript – following the rules is constraining, but in a way that builds confidence, because it ensures predictable outcomes. It makes teams productive, and becomes essential as features increase and teams scale. Conformance is a combination of ESLint rules and runtime checks in development. New apps will have a default next preset that ensures predictable loading performance.
Many production sites have already begun using our custom Next.js ESLint plugin, and they have seen significant performance gains from finding and fixing problems — such as unintentional render blocking scripts, or accidental full page refreshes from forgetting to use `next/Link`. Conformance is how we are open sourcing the system that we have internally at Google. We are early in this journey, and would love to evolve Conformance with feedback from the developer community. Please leave us your thoughts and suggestions at the GitHub repo. We know this worked for us, and I’m excited to see how this helps the Community.
Back to you Guillermo Thanks Shubhie. Our new Conformance system is enabled for all new apps starting with Next.js 11. As usual, all you have to do is run `create-next-app` For existing apps we made it easy: upgrade to Next.js 11 and run `next lint`. We made it both easy and incremental, just like our TypeScript integration. I'm glad Lydia reminded me to use the Image component earlier.
Now that Next.js has a Conformance system, I know that I won't forget that optimization again. Now, Houssein will set up Conformance for the app we're collaborating on, and walk us through how it works. Thanks Guillermo, I'm going to run `next lint` to set up Conformance and see what other optimizations we should be doing. Wow, there are a few optimization decisions that could improve loading performance. First, I'll wrap these anchor tags with the Next.js <Link> component and that'll ensure we get smooth client-side transitions between every page.
Next up, looks like one of our developers used a CSS reset to minimize browser inconsistencies. Thankfully, we have a rule to flag any manually-included, local CSS link tags and show how to include them using Next.js' built-in CSS support. I'll quickly select a solution from the linked doc, implement it, and done.
We also revealed that there’s an external synchronous <script> tag in use. Now, websites need third parties for their business, and this can include analytics, ads, and customer support widgets. However, they tend to be heavy on loading performance and can drag down user experience. And that's why, today, we're releasing the Next.js Script Component, a foundational optimization that enables developers to set the loading priority of third-party scripts. Developers often struggle to decide where to place third-party scripts in their application for optimal loading. With this new script component, simply define the
`strategy` property and Next.js will prioritize. This can massively improve loading performance! There are three different loading strategies: `before-interactive` – For critical scripts that need to be fetched and executed before the page is interactive. This can include any security or authentication scripts. `after-interactive` – For any scripts that can be fetched and executed after the page is interactive, such as tag managers and analytics and `lazy-onload` – For any scripts that can load at idle time.
Chat support widgets are an example of a script that can be lazy-loaded. Conformance makes it easier for developers to make the right optimization decisions, but we've continued to land more automatic optimizations to improve both developer and user experience. For example, many developers rely on custom web fonts to provide a beautiful web experience. Over 80% of web pages use a custom web font as part of their branding, design, or even to maintain cross-browser and device consistency. Unfortunately, loading a web font usually comes at the cost of performance. That's why, in April, we improved how web fonts load. In Next.js, the CSS of custom fonts
are automatically inlined at build time. This eliminates the round trip to fetch font declarations, improving both First and Largest Contentful Paint times. We’re happy to share that Font Optimization supports both Google Fonts and Adobe Typekit in Next.js, and that we've added Font Optimization to Angular for Google Fonts.
We'll be adding more font providers to more frameworks. For some large production sites already using Font Optimization, we've seen 2 to 5 second faster First Contentful Paints, with some Lighthouse performance scores improving up to 30 points. We’ve also taken things a step further by including a `preconnect` tag by default in Next.js, to establish a connection with the underlying font files even faster. At Google Chrome, we believe our collaboration with Next.js is an example of how to set predictable outcomes for loading performance. After wrestling with potential solutions
through the browser, we’ve come to realize that frameworks were the missing piece to the solution. We're now able to execute on a vision of what optimized loading looks like, taking the state of browser engines, platform primitives, framework tooling, and the needs of real production sites into consideration. We love working with great frameworks to help developers make the web faster.
We're incredibly grateful for the maintainers and sponsors of the frameworks that make it possible for the web to thrive. A special thanks to the Next.js team for testing with us, and sharing the cost of many of our early attempts. Thank you. Learn more about our initiatives in our blog. Back to you Guillermo. Thank you Houssein. We're so grateful for your and Google's contributions to open source frameworks like Next.js, Nuxt, and Angular. Vercel is committed to a thriving, open web. We're proud of our own contributions to this ecosystem.
With Next.js 11, our framework gets faster and easier to use, but most importantly, it raises the quality bar of your apps. Go to `nextjs.org/11` to get it. Today with Next.js Live, we made authoring the web real time, collaborative, and accessible to everyone with a web browser. Head to `nextjs.org/live` to try it out. Let's make the web. Faster. [upbeat music] [fades out]
2021-06-17 16:29
