Where Next.js apps actually slow down
Next.js gives you excellent defaults, but enterprise traffic finds the gaps: pages that render on every request because of one dynamic cookie read, API routes doing N+1 queries, and a single slow upstream service stalling whole pages.
Before touching infrastructure, measure. In most engagements the first big win is not a new architecture - it is finding the three routes responsible for 80% of server load and fixing how they fetch data.
Cache at every layer you can
The fastest render is the one that never happens. Static generation for anything that can tolerate staleness, incremental revalidation for content that changes hourly, and edge caching in front of everything else.
For truly dynamic pages, cache the expensive parts inside the page: memoised data fetches, Redis for hot reads, and request-level deduplication so ten components asking for the same user hit the database once.
Architecture patterns that hold up
Under sustained load, the patterns that survive are boring: queues between the web tier and slow work, read replicas for heavy queries, circuit breakers around flaky upstreams, and autoscaling tuned to real traffic curves rather than defaults.
Page speed scores in the high 90s are a side effect of this discipline, not the goal. The goal is a p99 you can put in a contract.