[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]
