What Are We Even Talking About?
When someone visits your website, the page they see has to come from somewhere. There are three main ways to deliver that page:
Static Site Generation (SSG) — the page is built once at build time. When someone visits, they get a pre-built HTML file. Fast, simple, cheap to host.
Server-Side Rendering (SSR) — the page is built fresh on the server every time someone visits. Slower than static, but the content is always up to date.
Client-Side Rendering (CSR) — the browser downloads a blank page and JavaScript fills it in. This is what plain React does. Bad for SEO, slower initial load.
With Next.js, you can mix and match all three in the same project. That's the beauty of it.
When to Use Static (SSG)
Static is the default choice. If the content doesn't change every minute, go static.
Good examples:
Marketing and landing pages
Blog posts and articles
Documentation sites
Portfolio and showcase pages
Pricing pages
Static pages are served from a CDN, which means they load in milliseconds from anywhere in the world. They're also the easiest to cache and the cheapest to host.
In Next.js, you use getStaticProps to build static pages. You can even add revalidate to rebuild the page every X seconds — so if someone updates the content in your CMS or admin panel, the site picks it up automatically without a full rebuild.
When to Use Server Rendering (SSR)
SSR makes sense when the page content depends on who's viewing it or changes so frequently that even a 60-second cache isn't good enough.
Good examples:
User dashboards (every user sees different data)
Search result pages (content depends on the query)
E-commerce product pages with live inventory
Pages that show real-time pricing or availability
In Next.js, you use getServerSideProps for this. The server runs the function on every request, fetches fresh data, and sends a fully rendered page to the browser.
The downside? It's slower than static because the server has to do work on every request. And if your server is slow or your database query takes too long, the user waits.
The Middle Ground: ISR
Incremental Static Regeneration (ISR) is the sweet spot for most projects. It works like this:
The page is built once at build time (like SSG)
When someone visits, they get the cached version instantly
In the background, Next.js checks if the page is older than your revalidation time
If it is, it rebuilds the page and swaps the old one out
So users always get a fast response, and the content stays reasonably fresh.
For most websites — including this one — ISR with a 60-second revalidation is the perfect balance.
Quick Decision Guide
Content rarely changes → SSG
Content changes daily or weekly → SSG + ISR (revalidate every 60s)
Content is different for every user → SSR
Internal tool, SEO doesn't matter → CSR (plain React)
Mix of public pages + user area → SSG for public, CSR for authenticated pages
What We Do at Fiznex
For most of our client projects, we use SSG with ISR. Here's why:
Pages load fast (served from CDN)
Content stays fresh (revalidates in the background)
No server load for every page view
Great SEO without extra work
We only reach for full SSR when the project genuinely needs it — like a marketplace with live pricing or a dashboard that pulls real-time data.
Bottom Line
Don't overthink it.
Start with static. Add ISR if you need fresher content. Use SSR only when the page truly needs to be different on every request.
And if SEO doesn't matter (admin panels, internal tools), plain client-side rendering is perfectly fine.
Tags
Written by
