Performance Concerns with App Router Compared to Pages Router

[buyaoaoman]

As Next.js strongly recommends using the App Router, I assumed it would be superior to the Pages Router. However, after a period of development using the App Router, it has become clear that this is not entirely the case. Despite the advanced technologies like RSC and streaming, the response time of the App Router is significantly slower than that of the Pages Router for an SSR framework.

You don’t need a complex example to see this discrepancy. Simply create two new projects using npx create-next-app@latest for both routers, and you’ll notice a huge difference in TTFB (Time to First Byte). The App Router takes almost twice as long as the Pages Router, which is completely unacceptable.

I made this comparison because I initially aimed to enhance user experience by refactoring and upgrading my project from the Pages Router to the App Router. This result is extremely disappointing.

I’m wondering if the current Next.js team is focusing on this issue. If this continues, I might consider switching to Remix or even Nuxt.

[icyJoseph]

Got some code? In an app we have, TTFB went down, but interestingly enough, when the app sits behind a CDN that buffers responses, then the TTFB shoots up... expectedly of course, but I wanted to set this up, as a what it was for us, a discovery journey.

For testing sake, I made a create-next-app, with the same contents in pages and app routes:

• [Web Vitals Extension] TTFB 0.012 sec (good) (App Router)
• [Web Vitals Extension] TTFB 0.015 sec (good) (Pages Router)

Refreshing the page several times, gives different results of course, but they two stacks are the same ballpark.

[buyaoaoman]

@icyJoseph You’re right, we shouldn’t just focus on certain metrics. So, is streaming rendering one of the reasons why App Router’s server-side rendering time might be longer than Pages Router’s?

[icyJoseph]

You can follow this guide: https://nextjs.org/docs/app/building-your-application/optimizing/open-telemetry

• enable the instrumentation hook
• in the instrumentation file, import and use @vercel/otel (also install it)
• in your .env add NEXT_OTEL_VERBOSE=1
• then go to this repo https://github.com/vercel/opentelemetry-collector-dev-setup, clone and run the recommended command
• now build and start your app, and go to the zipkin consumer, and find your service name, next-app if you followed the guide, there 😄

I'd also recommend using HTTPS, with Caddy you can reverse-proxy your localhost to your next.js server, caddy reverse-proxy --to :3000, so that you can go to https://localhost (no port), and see your app. That'll make it pick up http2 streaming, and to verify this, you can install the Chrome extension Claire, https://chromewebstore.google.com/detail/claire/fgbpcgddpmjmamlibbaobboigaijnmkl

You can also use oha, https://github.com/hatoo/oha, to fire a bunch of requests to your server, and see how it behaves:

oha http://localhost:3006 --http-version=1.1

Response time histogram:
  0.048 [1]   |
  0.217 [113] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.387 [48]  |■■■■■■■■■■■■■
  0.556 [4]   |■
  0.726 [3]   |
  0.895 [2]   |
  1.065 [3]   |
  1.234 [2]   |
  1.404 [2]   |
  1.573 [2]   |
  1.743 [20]  |■■■■■

but using HTTPS with HTTP2, through caddy:

oha https://localhost --http-version=2

Response time histogram:
  0.172 [1]  |
  0.279 [14] |■■■■
  0.386 [97] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.494 [78] |■■■■■■■■■■■■■■■■■■■■■■■■■
  0.601 [0]  |
  0.708 [1]  |
  0.815 [2]  |
  0.923 [1]  |
  1.030 [2]  |
  1.137 [1]  |
  1.244 [3]  |

Both are firing request to the same App Router page, statically rendered during next build, using next start.

[buyaoaoman]

I used to think that App Router would achieve faster initial response times and thus a faster TTFB by using streaming. However, pure server-side rendering doesn’t seem to yield that result, which is quite surprising.

[luisvieiragmr]

Yeah this kind of example has been observed before, https://github.com/eknkc/ssr-benchmark

I haven't had time to debug this much more than this though:

This image /landing, is a Pages Router, next build, statically optimized page:

This is an App Router, next build, statically optimized page: Here's the build report for transparency:

Route (app)                               Size     First Load JS
┌ ○ /                                     136 B          87.2 kB
└ ○ /_not-found                           875 B          87.9 kB
+ First Load JS shared by all             87.1 kB
  ├ chunks/23-ef3c75ca91144cad.js         31.5 kB
  ├ chunks/fd9d1056-2821b0f0cabcd8bd.js   53.7 kB
  └ other shared chunks (total)           1.88 kB

Route (pages)                             Size     First Load JS
┌   /_app                                 0 B            79.1 kB
└ ○ /landing                              727 B          79.9 kB
+ First Load JS shared by all             80.7 kB
  ├ chunks/framework-4be839806aa8e2d3.js  45.2 kB
  ├ chunks/main-66783b0b0ef1a702.js       32 kB
  └ other shared chunks (total)           3.5 kB

○  (Static)  prerendered as static content

As you can see, in the second image there's a lot of "dead time" to the right, after all traced work seems to have completed, I guess this is either, a bunch of promises resolving, or a stream not completing? But yeah, that one use case is strange to say the least, and although not very likely in real world apps, it can still happen.

Did you ever figure out what this "dead time" is? i'm currently struggling with something similar

[icyJoseph]

Not yet; but I will. That being said, i remember doing some other benchmark with version 15, and there were some improvements

[Envoy49]

Hey peeps, I opened this issue #69561
App router is significantly slower than Pages router even in sandbox environment

[Envoy49]

https://www.youtube.com/watch?v=3Q2q2gs0nAI

found a video which is relevant to our problems

[smoothdvd]

Same situation when I integrate bull-board + hone into NextJS 15.

In Page router mode:

wrk -t8 -c64 -d15s --timeout 8s http://localhost:3003/api/bull
Running 15s test @ http://localhost:3003/api/bull
  8 threads and 64 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    12.77ms   38.86ms 657.50ms   98.17%
    Req/Sec     0.98k   113.57     1.32k    91.81%
  116028 requests in 15.04s, 149.38MB read
Requests/sec:   7712.06
Transfer/sec:      9.93MB

In App router mode:

 wrk -t8 -c64 -d15s --timeout 8s http://localhost:3003/api/queues
Running 15s test @ http://localhost:3003/api/queues
  8 threads and 64 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    24.15ms   36.09ms 720.03ms   98.48%
    Req/Sec   390.59     58.98     1.02k    84.90%
  46526 requests in 15.08s, 63.63MB read
Requests/sec:   3085.63
Transfer/sec:      4.22MB

Page router's Req/s is almost 2.5x faster than App router.