Learning Astro - Static Site Generation & SSR

#Introduction

We have touched rendering models in several episodes: static in episodes 5 and 6, server in episodes 6 and 13. Episode 21 brings everything together in one thorough discussion — when to use static site generation, when to use server-side rendering, and how hybrid mode combines both.

This decision is one of the most impactful on your site's architecture: it determines hosting costs, page speed, and deployment ease. Understanding the trade-offs deliberately is the mark of a mature engineer.

This episode also covers ISR-style incremental updates and preview mode, two features that bridge the static and dynamic worlds.

#Static Site Generation Best Practices

#The Power of SSG

Static site generation (SSG) renders all pages into HTML at build time. The advantages are immediately visible: pages are served from a CDN without a server runtime, load times are very fast, hosting costs are low, and security is simpler because no code runs on the server.

#SSG Best Practices

For SSG to run optimally:

• Move as much computation as possible to build time: sorting, indexing, calculations.
• Use content collections and getStaticPaths for dynamic-looking pages that are still static.
• Limit JavaScript with partial hydration (episode 7).
• Apply aggressive caching for assets (episode 14).

SSG dengan banyak rute statis

---
export async function getStaticPaths() {
  const artikel = await getCollection("blog");
  return artikel.map((item) => ({
    params: { slug: item.id },
    props: { item },
  }));
}
 
const { item } = Astro.props;
---
 
<article>
  <h1>{item.data.title}</h1>
</article>

The pattern above builds one HTML file per article at build time — thousands of articles become thousands of static files ready to serve millions of visitors without a server.

#SSR and Hybrid Deployment Models

#When Server Mode Is Needed

Server-side rendering produces HTML per request. This mode is needed when: content differs per user, server-side authentication is required (episode 13), real-time data is needed, or forms are processed. Install an adapter (episode 8) to enable it.

#Hybrid Mode in Astro

Hybrid is the sweet spot: pages are static by default, and only certain pages render on the server. Set prerender = true for static pages, or disable it per page as needed:

Mode hybrid di astro.config

import { defineConfig } from "astro/config";
import node from "@astrojs/node";
 
export default defineConfig({
  output: "hybrid",
  adapter: node({ mode: "standalone" }),
});

With output: "hybrid", pages without prerender = true render statically, and pages with export const prerender = false or server logic inside render per request. You get static speed on most of the site and server flexibility only where it is needed.

#ISR-Like Incremental Updates and Preview

#Incremental Updates

Incremental Static Regeneration (ISR) is a pattern for updating static pages without a full rebuild — popularized by Next.js. In Astro, a similar approach is achieved through a combination of: a content layer that fetches data, caching, and automatic rebuilds.

A common pattern for occasionally changing content: set a short Cache-Control on the SSR page, then the CDN serves a fresh static version:

Pembaruan inkremental ala ISR

---
export const prerender = false;
Astro.response.headers.set(
  "Cache-Control",
  "public, max-age=300, stale-while-revalidate=600",
);
---
 
<h1>Statistik terbaru</h1>

This page is rendered on the server at most every 5 minutes, and visitors always get a version no older than 10 minutes. The combination of max-age and stale-while-revalidate produces a "near-static" experience without a full rebuild.

#Preview Mode

Preview mode lets editors see draft content before publishing. In Astro, a common pattern: a secret parameter in the URL triggers server rendering that shows draft content from the CMS, while public pages stay static. Episode 11 already covered the CMS integration — here you just connect it with server mode.

#Use Cases: Static vs SSR

#Guidelines for Choosing

Use this simple decision table:

Konten publik yang jarang berubah  → Statis
Konten personal per user          → SSR
Blog, dokumentasi, landing page   → Statis
Dashboard, search real-time       → SSR
Sebagian besar, sesekali dinamis  → Hybrid

When in doubt, start static. Almost all content sites run very well as static sites, and adding SSR later does not require rewriting the whole project.

#Real-World Combinations

Real sites are usually mixed: static marketing pages, SSR member pages with authentication, and hybrid report pages with short caching. Episodes 22 and 23 will complete the picture with monitoring and long-term architecture decisions.

#Conclusion

Episode 21 unifies Astro's rendering models: SSG best practices with build-time computation, SSR and hybrid modes with adapters, ISR-style incremental updates through cache combinations, and preview mode and guidelines for choosing static versus SSR.

The key takeaways:

• SSG renders HTML at build time: fast, cheap, and safe.
• SSR is needed for personal content, auth, or real-time data.
• Hybrid keeps most pages static with server exceptions.
• prerender controls per-page rendering in hybrid mode.
• Cache combinations produce ISR-style incremental updates.
• Start static; add SSR only when the need is proven.

In the next episode 22, we will cover observability and monitoring: monitoring page performance and user experience, error reporting with client analytics, tracking build and deployment metrics, and production support and incident response. Your site will stay watched after release.