Optimizing High-Traffic Next.js Site: CMS Integration & Real-Time Data Strategy
Unanswered
Broad-snouted Caiman posted this in #help-forum
Broad-snouted CaimanOP
We're currently building a Next.js website for a client that's expecting significant traffic (between 5M and 20M visits). It'll primarily be content-driven, pulling data from a headless CMS. We chose Next.js for its performance and developer experience.
Based on our understanding of the new App Router, we've outlined a build strategy:
1. Fetch CMS content and pass it to components for rendering.
2. Implement a revalidation time on these calls to ensure the Next.js cache is purged regularly.
Here's where we'd appreciate your guidance:
- Build Time Caching: Does Next.js generate and cache the entire server-rendered markup during build time, or just the fetch calls themselves?
- Serving Cached Content: When a user requests a page, will the server serve the entire cached version (if available) or re-render on runtime using the cached fetch calls?
- High-Traffic with Real-time Data: We have some page components that require real-time data. Can we force these fetch calls not to be cached, ensuring fresh data on every request? Will the server be able to handle a high-traffic scenario with such a setup?
- Personalized Content: Similar to real-time data, some components need personalized content based on the logged-in user state.
An alternative approach is to convert these real-time data components to client-side components, potentially saving runtime costs. However, this might introduce a slight delay in user experience, and it would also add complexity to managing the application-level state for personalized user experience, which is generally easier to achieve during Server-Side Rendering (SSR).
We'd greatly appreciate any insights you can share on these points to help us optimize our build strategy for this high-traffic Next.js website.
Thanks in advance!
Based on our understanding of the new App Router, we've outlined a build strategy:
1. Fetch CMS content and pass it to components for rendering.
2. Implement a revalidation time on these calls to ensure the Next.js cache is purged regularly.
Here's where we'd appreciate your guidance:
- Build Time Caching: Does Next.js generate and cache the entire server-rendered markup during build time, or just the fetch calls themselves?
- Serving Cached Content: When a user requests a page, will the server serve the entire cached version (if available) or re-render on runtime using the cached fetch calls?
- High-Traffic with Real-time Data: We have some page components that require real-time data. Can we force these fetch calls not to be cached, ensuring fresh data on every request? Will the server be able to handle a high-traffic scenario with such a setup?
- Personalized Content: Similar to real-time data, some components need personalized content based on the logged-in user state.
An alternative approach is to convert these real-time data components to client-side components, potentially saving runtime costs. However, this might introduce a slight delay in user experience, and it would also add complexity to managing the application-level state for personalized user experience, which is generally easier to achieve during Server-Side Rendering (SSR).
We'd greatly appreciate any insights you can share on these points to help us optimize our build strategy for this high-traffic Next.js website.
Thanks in advance!
1 Reply
Broad-snouted CaimanOP
Awaiting some valuable inputs