In this week’s release of Next.js, Vercel focused on delivering performance improvements by enabling partial pre-rendering on the page. Next.js 14 also includes a faster TurboPack engine and stable server actions.
Developers were frustrated by the amount of configuration, the amount of runtimes and the amount of thought that had to go into fine-tuning Next.js applications, said Lee Robinson, vice president of developer relations.
“We really wanted to focus on a return to simplicity, and not introduce new ways of using the framework,” Robinson said. “Partial pre-rendering actually builds on effectively the last decade worth of our experience — building not only on Next.js but also Vercel and the combined efforts of the entire team.”
The partial pre-rending feature combines static site generation with server-side rendering with no new APIs required for the developer, he added.
Traditional server-side rendering can be slow to load pages, but once it’s loaded, it’s done. Any changes re-render the whole page. Static site generation offers a faster alternative but it’s reading a static file and so eliminating anything done dynamically, Robinson explained. It doesn’t allow for personalization, either.
“The drop off between those two has put folks in kind of a strange spot,” Robinson said. “They want to have the flexibility of dynamic at the speed of static.”
One of the keys to accomplishing that was the Next.js app router, which is built to support streaming. As the page produces partial bits of the UI, content can progressively stream content back to the browser, he explained.
“It was a good step forward building on the foundation of the app router and being able to stream but to get to that world, you had to think about the edge runtime as well as a Node.js runtime,” he said. “The feedback from the community was, well, this is kind of a lot. The problem or the opportunity for improvement there was that even if you move your rendering to the edge, you still had to run some compute.”
Instead, Vercel opted to build off the foundation of React Suspense. Suspense manages asynchronous operations in a React app, allowing components to communicate to React that they’re waiting on data, according to this LogRocket blog post.
“What we’ve been working on is being able to define at the component level, built on the foundation of React and Next.js, whether we want components to run dynamically,” he said. “We’re really taking the best parts of static and the best parts of dynamic, personalized experiences, and combining them at the component level — without having to come up with any new APIs or invent any new concepts.”
It sounds a lot like islands, which also render components, but islands are isolated Preact components that are then hydrated on the client within a statically rendered HTML page.
Server actions are also stable in this version of Next.js.
React server components allow developers to grab data from a database or wherever. What server actions do is allow developers to actually change or mutate that data with less JavaScript client-side overhead, Robinson explained.
“What happened over the last 10 years of this architecture really is that a lot of client-side JavaScript was written, which can impact performance as well as SEO by having a slower page, and [so] the developer experience really suffered,” he said. “It was really hard to understand these systems and introduced a lot of bugs from the accidental state machine that was created.”
Server actions cut out the need to talk to an API and come back to the device, he explained.
“All I do is write a JavaScript function. It’s able to securely run on the server and update or delete content in my database, and then it can return back to the client and be integrated with the entire model of Next.js,” he said. “So how you fetch data, how you cache data, how you invalidate that data, it’s all one system.”
One use case would be on an Add to Cart button. Instead of waiting for the button to respond because the JavaScript hasn’t loaded, it will kick off something right away, he said.
“That’s really what this does, which is critically important for Next.js users and Next.js developers who are developing for audiences [that] might not have the fastest internet connections,” he added.
Next.js 14 includes “significant improvements” to the underlying Rust engine, TurboPack, Robinson said. The improved engine has passed 90% of more than 5000 tests; which includes bugs or potential edge cases for all of the Next JS development features. It also boasts 35% faster local server startup and 80% faster code updates with Fast Refresh, according to Vercel’s blog post on the news.
“This is a large improvement to the developer experience of Next.js,” Robinson said. “We really wanted to improve how quickly a developer is able to start their local server on their machine, as well as when they hit save in their editor, how fast can they see the updates in their browser from the changes that they’re making.”
There’s room to grow the performance improvements, he added.
“What we’ve done is we’ve shifted our strategy a little bit so that immediately more people, more developers, can start taking advantage of these performance improvements. And we have a lot of ceiling to go — the ceiling’s very high for performance improvements,” he noted.
Finally, Vercel has also announced an overhaul of its free Next.js Learn course, which now incorporates all the new Next.js features and foundations Vercel had released over the past year, he said.
“We’ve had millions and millions of developers learn Next.js through that course. It’s actually more popular than our documentation itself,” Robinson said. “It’s really exciting to see that foundation get updated because the next million developers will use that to start their Next.js journey.”
The changes don’t just improve developer experience, but also enhance user experience, Robinson said.
“All the things that we’ve talked about today, we believe also help accelerate the end user experience,” he said.
There’s still room to do more, he acknowledged. For instance, Vercel will be providing guidance for how to deploy security best practices with server actions and other new patterns, he said. To that end, a recent blog post explored how to apply security best practices in the new paradigm.
“One thing that developers will never say is ‘You know what, this could be slower. I don’t want more performance. I don’t want to be faster,” he said. “Everybody just wants performance.
