Next.js 3.0 Beta: Shipping Static Sites and Code-Splitting Upgrades

Next.js 3.0 is now in beta, introducing two headline features: a new next export command for generating fully static websites, and built-in support for dynamic imports via the TC39 proposal. The release is backwards-compatible and available now with npm install next@beta.

Static Exports with next export

The typical Next.js workflow has been to use next for development, next build for production compilation, and next start for serving the app. With 3.0, a fourth command, next export, compiles the app into a standalone static site that requires no server to run.

To use it, set up a custom next.config.js file that maps your app's routes to their corresponding pages. The export command builds the project, executes the getInitialProps functions of those pages at build time, and stores the results as prebuilt HTML files in the out directory (which can be customized; run next export -h for options).

The static output supports most Next.js features, including dynamic URLs, prefetching, preloading, and the new dynamic imports. Deploying is as simple as pointing any static host at the out directory.

Static Export Limitations

Because the build process pre-renders HTML at export time, getInitialProps functions can only access the pathname, query, and asPath fields of the context object. The req and res fields are unavailable since they require a server runtime. Apps needing server-side dynamic rendering should continue using next start.

Dynamic Imports and Code Splitting

Next.js 3.0 adds full support for the TC39 dynamic import proposal, meaning import() is available anywhere to fetch modules as a Promise. A new higher-order component helper, next/dynamic, turns those promises into rendered components. When used, the dynamically imported components are excluded from the main page bundle and lazily fetched on the client side.

If a dynamic component is actually rendered during server-side rendering or static export, the necessary <script> tag is included and loads in parallel with the rest of the page scripts. This granular, per-component code splitting is particularly useful for scenarios like large chat applications with many message types, where static imports would force the client to download handlers for message types that may never appear.

Server-Side Rendering for Dynamic Components

Unlike client-only dynamic loading approaches, Next.js supports server-side rendering for dynamic imports. A dynamically imported component that is part of the server render is loaded and rendered synchronously on the server. This preserves all the code-splitting benefits of dynamic imports without showing users blank pages, flickering, or loading spinners—a combination unique to Next.js.

Getting Started with the Beta

The 3.0 API is considered stable for experimentation and pre-production use; the team does not expect significant breaking changes. Documentation and an example app for dynamic imports are available in the Next.js repository, currently maintained under the canary branch.