Next.js Conf – Special Edition

Next.js Conf – Special Edition

Show Video

[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  `` 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 `` 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 `` to try it out. Let's make the web. Faster. [upbeat music] [fades out]

2021-06-17 16:29

Show Video

Other news