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.

[icyJoseph]

Streaming is supposed to bring down TTFB, because the server sends data ASAP, without blocking, but that has caveats, gotchas, and other bits.

I think, unfortunately, that people just look at metrics raw, and use umbrella terms all over the place.

In this case though, it is indeed, at the very least, weird, that the request has so much dead time to the right of the last finished span.

Take for instance, what if we make everything render on demand:

This time the first image is Pages Router, with a getServerSideProps function that does nothing:

This second image is App Router with force-dynamic:

Both using the same setup as before. Build summary here 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                              743 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
ƒ  (Dynamic)  server-rendered on demand

But now App Router does better, though TTFB from webvitals, shows them at essentially the same level:

• Pages Router, [Web Vitals Extension] TTFB 0.059 sec (good)
• App Router, [Web Vitals Extension] TTFB 0.069 sec (good)

And, you can also get better results over HTTPS, on your former example, IIRC.

I guess, what I am trying to get at, is that, this kind of measurement, is not necessary very easy to do, because it depends on a whole bunch of factors.

[SLMNBJ]

@icyJoseph are those screenshot generated by this repo https://github.com/eknkc/ssr-benchmark? I would like to benchmark my app like this. Thank you

[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.