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.
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.
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.
We want to work with you! Check out our "What We Do" page.