The release of Next.js 13's new app router has captured the attention of web developers across the internet. One of its standout features is the claim that it can significantly reduce the amount of JavaScript sent to the client, all thanks to its implementation of React Server Component (RSC). However, skepticism crept in my mind, prompting me to delve deeper into this assertion.
To put these claims to the test, I embarked on an experiment. I set out to create an identical application using both Next.js App Router and Page Router. The results of this experiment turned out to be not only enlightening but also unexpected.
I began by creating a simple website containing 2 pages with a reusable component in both App Router and Page Router.
- Here is the code for App Router:
- Here is the code for Page Router:
You can check the code in this repository: https://github.com/afiiif/next-app-router-vs-page-router
Comparison
Build The App
Here is the result of running pnpm build for both Next.js app:
- App Router
- Page Router
It looks like Page Router produces less bundle size. 🤔
Wait, don't jump to conclusions too quickly.
Serve The App
After build the app, I run pnpm start to start the production server, visit the homepage, and inspect the network request-response.
- App Router (9 requests, 118.37 kB transferred)
- Page Router (12 requests, 96.77 kB transferred)
The App Router resulting fewer JavaScript files, but the total transfered assets is larger than the Page Router. 🧐
Inspecting The Assets
I wonder how the HTML entry file for App Router was significantly larger than entry file for Page Router.
4.25 kB vs 1.52 kB, it's 280% larger. 😲
After examined the responses, I found that the truth is...
Here is how my code is compiled and served:
(The HTML entry file, the assets for homepage & another page)
- App Router
- Page Router
My investigation led me to a fascinating discovery: the Next.js App Router, while promising less JS, was actually carried a relatively-equivalent-bundle inside the HTML file. 😅
Which do you prefer:
- A web page that can be viewed in 1 second but need additional 2 seconds to be interactive, or
- A web page that can be viewed in 2 second but need additional 1 second to be interactive
It's important to acknowledge that the scenarios I've examined might not perfectly mirror real-world applications. The aim here was to simplify the process, offering a straightforward explanation of how the code was compiled and how different routers performed under controlled conditions. Real-world applications often come with a myriad of complexities, including diverse functionalities, various libraries, and intricate user interactions. So, it's crucial to consider that actual projects may yield different results based on their unique configurations and requirements.
In closing, I want to express my sincere gratitude to the Next.js team for crafting an exceptional web framework. Their innovation have undoubtedly elevated the web development experience for countless developers, including myself.
The Next.js 13 App Router was cool, but I think for now I'll stick with Page Router.
Top comments (0)