Avoiding Making Your Next.js Build Slower

Brief introduction

Next.js is one of the most hyped and used React Frameworks to create SSR (Server Side Rendering) applications nowadays. It’s known for its practicality in routes usage and styling, while also needing little to no setup.

This framework was created inside of ZEIT headquarters, the same company behind Now, a really easy and fast way to deploy apps.

🧨 The Problem

When it comes to organizing your code into files and folders there is a whole range of possibilities, but Next.js seeks to standardize that somehow: it requires you to put all the page components inside of a folder called pages, so it knows how to generate the routes.

All JavaScript files placed in that folder and those subfolders are going to be built and served by Next, so if you place your spec files there, they will be built as well. At the moment of writing, both Next 7 and 8 have this behavior.

If that was not enough and you decide to generate source maps for your files, things become way more critical. Probably, you are going to have source maps for your specs file too. Imagine how much time you’ve been spending unnecessarily.

🚀 Speeding up

In the project that I’ve been working on, we decided to create the specs files alongside components. In thepages folder, this wasn’t any different. Although, this was the bottleneck of our build time. Moving those specs to another folder did the trick. We’ve decided to move these files to the specs folder on the root of the project.

As Next.js only builds the files from inside the “pages” folder and their dependencies, it will neither build nor generate source maps for the tests anymore.

What about the numbers?

Disclaimer: this might change accordingly to your machine, project size, and structure.

My project has the following numbers:

  • Around 100 React components
  • Around 15 Next.js pages, which usually are a group of React components
  • Using latest Next.js 7

My machine is a MacBook Pro 13″ — 2018 and to build the project it was taking between 150~165 seconds without source maps.

Moving the spec’s files from pages to another folder, the build time decreases to 45~60 seconds. That is a decrease of 72% in the build time, which was possible just by putting files into a proper folder.

Wrapping up

When you are using a third-party framework or library, with a built-in setup to process something, you definitely should read the docs.

Avoiding read the documentation may cause unwanted issues in the future. You can find in the Docs a variety of information that may help you solve some specific issues. Another option is to get a look into their codebase.

If this post helped you solve that particular problem or similar issues, I would like to know.

Feedback and discussion are more than welcome, please drop me a comment if I helped you, or reach me on twitter at @abnersajr.

Last but not least, in software development, small things can cause a big problem.

Thanks to Iago Dahlem Lorensini, Will Soares, and Laka3000.