The old hot reloading implementation was not resilient to compilation or runtime errors and would perform a full reload of your application if you made a typo while editing your CSS or JavaScript. This was suboptimal and interrupted your train of thought.

This means Next.js will only update code in the file you edited, and only re-render that component, without losing component state. This includes styles (inline, CSS-in-JS, or CSS/Sass Modules), markup, event handlers, and effects (via useEffect).

Next.js introduced Static Site Generation methods in 9.3 with a clear goal in mind: we should get the benefits of static (always fast, always online, globally distributed), but with excellent support for dynamic data, which Next.js is known for.

To get the best of both worlds, Next.js supports Incremental Static Generation, updating static content after you have already built your site. For example, in 9.3 we’ve introduced the fallback: true option in getStaticPaths, which allows you to add new pages at runtime.

We recently put together an example showcasing how Next.js can statically pre-render an infinite number of pages this way:

Today, we are also introducing Incremental Static Regeneration (beta), which is a mechanism to update existing pages, by re-rendering them in the background as traffic comes in. Inspired by stale-while-revalidate, this ensures traffic is served uninterrupted, always statically, and the newly built page is pushed only after it's done generating.

exportasyncfunctiongetStaticProps(){return{
props:awaitgetDataFromCMS(),// we will attempt to re-generate the page:// - when a request comes in// - at most once every second
unstable_revalidate:1}}

A common piece of feedback that we got from companies using Next.js is that it was unclear when an environment variable is inlined into the browser bundle and when it is only available in the Node.js environment.

Today we're announcing two fully backward-compatible features that will help streamline this process.

First, you can now prefix the environment variable with NEXT_PUBLIC_ to expose an environment variable to the browser. When that environment variable is used it will then be inlined into the browser JavaScript bundle.

You no longer have to add a next.config.js and add the env key to expose these variables.

// pages/index.js// The environment variable will be exposed to the browserconsole.log('My Application Version', process.env.NEXT_PUBLIC_VERSION)exportdefaultfunctionHomePage(){return<h1>Hello World</h1>}

The second change is that Next.js now supports .env loading by default. Allowing you to easily define development and production environment variables.

When building production web applications you also want to know how your site is performing for your visitors and (potential) customers. You might even want to track the improvement or regression of these metrics over time in order to see if your changes have the intended impact on your audience.

In order to aid reporting Core Web Vitals to your analytics service we have introduced, in collaboration with Google, a new method called reportWebVitals which can be exported from pages/_app.js:

// Will be called once for every metric that has to be reported.exportfunctionreportWebVitals(metric){// These metrics can be sent to any analytics serviceconsole.log(metric)}functionMyApp({Component, pageProps }){return<Component{...pageProps}/>}exportdefaultMyApp

Furthermore, Next.js 9.4 also supports the paths option, which allows you to create custom module aliases. For example, the following allows you to use @/design-system instead of components/design-system:

We have redesigned the command line output to be more consistent and output less duplicate data like the deployment URL, waiting on the development server to start and more. We've also changed the spacing of the message type to be consistent across messages, meaning they no longer jump from line to line.