We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Web & Content Delivery
Pre-rendering pages to static HTML at build time. The fastest possible page loads because there's no server-side computation on each request.
In short
Static Site Generation (SSG) is a technique where every page is rendered to plain HTML files ahead of time, during a build step, instead of being generated on each request. Those finished HTML, CSS, and JavaScript files are served directly from a CDN, so there is no database query or server-side rendering work when a visitor loads the page, which makes loads close to instant.
In short
Static Site Generation (SSG) is a technique where every page is rendered to plain HTML files ahead of time, during a build step, instead of being generated on each request. Those finished HTML, CSS, and JavaScript files are served directly from a CDN, so there is no database query or server-side rendering work when a visitor loads the page, which makes loads close to instant.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Static Site Generation across a run of lessons, not one page. These 4 alone are about 62 minutes of step-by-step reading, every one with a quiz.
Pre-building HTML pages at build time, the fastest possible delivery for content that does not change per request.
Generating HTML on the server for each request, fast first paint, SEO-friendly, and dynamic content.
Managing and optimizing CSS, JavaScript, images, and fonts for fast page loads.
Updating static pages after build time without rebuilding the entire site, the best of SSG and SSR combined.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Static Site Generation (SSG)pay once,
yours for life
With SSG, the work of building a page happens once, when you deploy, not every time someone visits. A build process runs your templates and data through a generator, and the output is a folder of static files: one HTML file per route, plus the CSS, JavaScript, and images they need.
Compare this to the two alternatives. Server-side rendering (SSR) builds the HTML on the server for every single request, so it can show the latest data but adds compute and latency to each visit. Client-side rendering (CSR) ships an empty HTML shell and a JavaScript bundle that fetches data and draws the page in the browser, which delays the first meaningful paint. SSG sidesteps both by having the finished page ready before anyone asks for it.
The catch is that the content is frozen at build time. If your data changes, you have to rebuild and redeploy, or use a hybrid approach that re-renders specific pages on a schedule or on demand.
A static site generator runs in three steps. First it loads your content, which can be Markdown files, MDX, JSON, or data pulled from a headless CMS or an API. Second it passes that content through page templates or React components to produce HTML strings. Third it writes those strings to disk as .html files, alongside a manifest of assets.
Frameworks like Next.js and Astro let you control which pages get generated. In Next.js you export a function such as generateStaticParams that returns the list of dynamic routes, for example every blog slug or every product id, and the build loops over that list and emits one HTML file per entry. A site with 754 pages produces 754 HTML files in a single build.
Because the output is just files, deployment is trivial. You upload the folder to a CDN such as Cloudflare, Vercel's edge network, or Amazon CloudFront backed by S3. The CDN caches every file at edge locations near users, so a request in Tokyo is served from a Tokyo node without ever reaching your origin. Time to first byte typically lands under 100ms because there is nothing to compute.
SSG is the right call for content that changes rarely and is the same for every visitor: marketing pages, documentation, blogs, course material, and product catalogs. These benefit most from the speed, the low cost, and the strong SEO that comes from shipping complete HTML that crawlers can read without running JavaScript.
It is a poor fit for highly personalized or real-time content. A user dashboard, a stock ticker, or a shopping cart that differs per session cannot be baked in at build time. For those you reach for SSR or CSR, or you statically generate the shell and hydrate the dynamic parts on the client.
The main trade-off is build time and staleness. A site with tens of thousands of pages can take many minutes to build, and any content edit means a rebuild. Modern frameworks soften this with Incremental Static Regeneration, where the first request after a page's cache window expires still gets the cached page and triggers a fresh render in the background, which is then served statically, so you get fresh content without rebuilding the whole site.
Consider a documentation site with 500 articles written in Markdown. At build time the generator reads all 500 files, renders each through a shared layout, and writes 500 HTML files plus a search index. The whole build might take 90 seconds and run once per content update in CI.
When a reader opens an article, the CDN returns the prebuilt HTML in tens of milliseconds. There is no database, no server process, and no cold start. The same setup serves ten readers or ten million readers at nearly the same cost, because the CDN absorbs the traffic and the origin is barely touched.
This is exactly why developer docs, learning platforms, and JAMstack sites lean on SSG. You trade a little build complexity and the need to redeploy on changes for pages that are fast, cheap to host, resilient to traffic spikes, and easy for search engines to index.
Vercel and Next.js
Next.js popularized SSG with generateStaticParams and Incremental Static Regeneration, and Vercel serves the output from its global edge network.
Cloudflare Pages
Hosts statically generated sites and serves the prebuilt files from 300+ edge locations for sub-100ms time to first byte.
Amazon S3 plus CloudFront
A classic pairing where built HTML lives in an S3 bucket and CloudFront caches and distributes it globally with no servers to run.
GitHub Pages
Serves Jekyll-generated static sites for free, which is how a large share of open-source project documentation is published.
SSG renders pages to HTML once at build time and serves the same files to everyone, so there is no per-request compute. SSR renders the HTML fresh on the server for each request, which lets it show up-to-date or personalized data but adds latency and server cost to every visit.
Yes, but the dynamic parts run in the browser. You generate the static shell at build time, then client-side JavaScript fetches user-specific data after the page loads. Truly per-user pages are better suited to SSR or hybrid rendering.
You change the source content and trigger a rebuild and redeploy, usually automated through CI. To avoid rebuilding everything, frameworks offer Incremental Static Regeneration or on-demand revalidation, which rebuild only the pages that changed.
Search crawlers receive complete HTML immediately, with all the text and metadata present, so they do not have to execute JavaScript to see the content. Combined with fast load times, this tends to improve indexing and ranking.
Build time grows with page count, so a site with tens of thousands of pages can take several minutes to build. Incremental Static Regeneration helps by generating pages on first request after expiry instead of regenerating the entire site every time.
ISR
Incremental Static Regeneration: a Next.js feature that re-generates static pages in the background after a specified time interval, combining SSG speed with fresh data.
SSR
Server-Side Rendering: generating HTML on the server for each request. Slower than SSG but always returns fresh data. Good for personalized or frequently changing pages.
CDN
A network of servers distributed globally that caches content close to users. Netflix uses CDNs to stream video from servers near you, not from one central location.
Content Delivery
The process of distributing and serving content to users from locations geographically close to them for faster load times.
Edge Computing
Running computation at the network edge, close to the user, instead of in a central data center. Reduces latency for real-time applications like IoT and streaming.
HTTP Caching
Browser and proxy caching controlled by HTTP headers like Cache-Control, ETag, and Last-Modified. Eliminates redundant network requests for unchanged resources.
This page explains the idea. The "Static Site Generation (SSG)" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Static Site Generation (SSG) lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Static Site Generation (SSG) in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
