Static Site Generation (SSG) & Hydration
5 questions foundWhat is static site generation and how is it different from server side rendering?
Beginner Static site generation builds the HTML for every page in advance, at build time, before any visitor even requests the page, then simply serves those already built files instantly. Server side rendering instead builds the HTML fresh on every single request. Static generation is extremely fast since nothing needs to be built on demand, but it works best for content that does not change on every single visit.
// Next.js static generation example
export default async function BlogPost({ params }) {
const post = await getPost(params.slug);
return <Article post={post} />;
}
export async function generateStaticParams() {
const posts = await getAllPosts();
return posts.map((post) => ({ slug: post.slug }));
}
Real-world example A company blog builds every article page in advance during deployment, so visitors always get an instantly loading page served directly from a fast content delivery network, without any server work happening at request time.
Common follow-ups: What happens if the underlying content changes after the static pages have already been built?;What kind of pages are a poor fit for static site generation?
Server-Side Rendering (SSR) & Next.js;Server Components
What is incremental static regeneration and how does it solve the problem of static content becoming outdated?
Intermediate Incremental static regeneration lets a statically generated page be automatically rebuilt in the background after a set amount of time, without needing to rebuild the entire site. This gives you both the speed of static pages and reasonably fresh content, without visitors ever seeing a slow, fully dynamic page.
export default async function ProductPage({ params }) {
const product = await getProduct(params.id);
return <ProductDetail product={product} />;
}
export const revalidate = 60; // rebuild this page in the background at most once every 60 seconds
Real-world example A product page shows the same fast static page to most visitors, while Next.js quietly rebuilds it in the background every sixty seconds, ensuring the price and stock information never stays outdated for too long.
Common follow-ups: What happens to a visitor's request while a page is being regenerated in the background?;How is this approach different from simply rebuilding the entire site on every deployment?
Server-Side Rendering (SSR) & Next.js;Data Fetching (React Query & SWR)
What is hydration mismatch, and what commonly causes this error in a React app using server rendering?
Intermediate A hydration mismatch happens when the actual HTML sent from the server does not exactly match what React expects to render in the browser during hydration, often caused by rendering something differently based on data that only exists in the browser, like the current time or a random value, or a browser only API like window.
// Causes a mismatch, this differs between server and browser
function Greeting() {
return <p>Current time: {new Date().toLocaleTimeString()}</p>;
}
// Fixed, only shows this after hydration completes in the browser
function Greeting() {
const [time, setTime] = useState(null);
useEffect(() => setTime(new Date().toLocaleTimeString()), []);
return <p>Current time: {time || 'Loading'}</p>;
}
Real-world example A team fixes a confusing console warning about a hydration mismatch, tracing it back to a component that displayed the current time differently on the server versus the browser, resolved by only showing it after the component mounts in the browser.
Common follow-ups: Why does the exact current time cause a mismatch between the server and browser rendering?;What other common browser only values tend to cause this same problem?
Server-Side Rendering (SSR) & Next.js;Effects & Lifecycle
How would you decide between static site generation and server side rendering for a specific page?
Advanced Choose static site generation for content that is the same for every visitor and does not change extremely often, like a blog post or a marketing page, since it can be built once and served instantly to everyone. Choose server side rendering for content that must be fresh on every single request or is personalized per user, like a dashboard showing a specific user's private data.
// Good fit for static generation, same content for everyone
export default async function AboutPage() {
return <AboutContent />;
}
// Good fit for server side rendering, personalized per visitor
export default async function Dashboard({ userId }) {
const data = await getPersonalizedData(userId);
return <DashboardView data={data} />;
}
Real-world example A company website statically generates its about page and pricing page, which rarely change, while server rendering its personalized account dashboard fresh on every request, since that content is unique to each logged in user.
Common follow-ups: Can a single app mix both static generation and server side rendering across different pages?;What role does incremental static regeneration play as a middle ground between the two?
Server Components;Data Fetching (React Query & SWR)
Why does a statically generated website often load faster than one that renders pages on every request?
Beginner Since the HTML for a statically generated page was already built ahead of time, the server, or often a content delivery network located physically close to the visitor, can send the finished file immediately, without spending any time computing anything at the moment of the request.
// Once built, this page is just a plain HTML file, ready to serve instantly
// No server computation is needed when a visitor requests it
// dist/about/index.html
Real-world example A company's marketing site, built entirely with static site generation, consistently loads in under half a second for visitors around the world, since every page is served instantly from cached files close to each visitor's location.
Common follow-ups: What role does a content delivery network play in making static sites load fast globally?;Are there any downsides to relying entirely on static site generation?
Performance (memo/useMemo);Deployment & Production Builds