How Astro Renders Pages

By Syncfusion®, Inc. · Last updated November 14, 2026

What rendering means, build time vs request time vs the browser, SSG, SSR, CSR and hydration, Astro's static and on-demand modes, client-side islands, static rendering in depth, keeping static sites fresh, the output setting and why hybrid was removed.

What Rendering Means

• Rendering = turning your components and data into HTML that a browser can show.
• Every page must be rendered at some point. The big question is when and where.
• The answer decides how fast the page is, how fresh its data is, and what it costs to host.
• In this lesson, you will learn the three places rendering can happen, and the words people use for them.

Simple lesson: rendering makes the HTML. Where and when it happens shapes the whole site.

A Real-World Example

• Asha's blog posts change maybe once a week. They can be made into HTML once, ahead of time.
• Next month she adds a page that greets the logged-in reader by name. That page is different for every visitor.
• The same site now needs two ways of rendering.
• Astro lets each page choose.

Press ▶ Run. Then switch between the two pages with the links. Watch the times.

What happened:

• Both pages were rendered once, during the build. The Terminal shows it.
• Clicking the links does not change the times. The browser only shows the ready HTML.
• Press ▶ Run again: that is a new build, so the times change.

What You Will Learn

In this lesson, you will learn:

1. Where and when rendering can happen.
2. What SSG, SSR, CSR and hydration mean.
3. Astro's two render modes, and where client-side rendering fits.
4. What static rendering can and cannot do.
5. How static sites stay up to date.
6. What the output setting does.
7. How to see the difference yourself.

Where and When Rendering Happens

There are three moments:

• Build time = on your computer (or a build server), when you run astro build. Before anyone visits.
• Request time = on a server, when a visitor asks for the page.
• In the browser = on the visitor's device, after the page has loaded, by running JavaScript.

Simple lesson: HTML can be made at build time, at request time, or in the browser.

Rendering Terms Explained

You will see these four terms in every framework's docs. Here they are in plain words.

Static Site Generation (SSG)

• SSG = make every page's HTML at build time.
• The result is a folder of plain files. Any web host can serve them.
• Very fast, very cheap, very safe. But the data is only as fresh as the last build.

Server-Side Rendering (SSR)

• SSR = make a page's HTML on a server, at request time.
• Each visitor can get a different page: their name, their cart, today's prices.
• Needs a running server, which costs more and is a little slower.

Client-Side Rendering (CSR)

• CSR = send almost empty HTML plus JavaScript. The browser builds the page.
• Good for very interactive apps. But the first view waits for the JavaScript, and search engines see less.

Hydration

• Hydration = the browser runs JavaScript on HTML that already exists, to make it interactive.
• The HTML came from SSG or SSR. Hydration "adds water": it attaches click handlers and state.
• In Astro, only small islands are hydrated, not the whole page. You meet them in Astro Islands.

Simple lesson: SSG builds ahead, SSR builds per request, CSR builds in the browser. Hydration wakes up HTML that already exists.

Astro's Render Modes

Static Rendering

• Astro's name for SSG.
• It is the default. Every page so far in this course was static.

On-Demand Rendering

• Astro's name for SSR.
• A page is rendered on demand when you turn it on for that page, or for the whole site.
• It needs an adapter: a small package that runs Astro on your host's server. You add one in On-Demand and Mixed Rendering.

Client-Side Rendering in Astro

• Astro does not render whole pages in the browser.
• But an island can render only in the browser with client:only. Use it for parts that cannot run on a server, such as a map that needs window.

The lab below has one page of each kind. Press ▶ Run, open HTML sent to browser, then visit /live twice.

What to compare:

• Static page: the time never changes until the next build.
• On-demand page: each visit makes new HTML. The Terminal counts the requests.
• Browser page: the HTML sent to browser only says "Loading…". The text is made later by the script.

Simple lesson: static by default, on-demand when a page needs request data, browser-only for small islands.

Static Rendering in Depth

The Build Step Renders Every Page Once

• astro build runs every component script one time per page.
• For dynamic routes, getStaticPaths() decides how many pages there are.

The Output Is Plain Files

• The dist/ folder holds .html, .css, .js and image files.
• Static host = a service that only serves files: GitHub Pages, Netlify, Cloudflare Pages, Vercel and many more.

No Server Runs When a Visitor Opens the Page

• The host just sends the file. Nothing of yours runs.
• That makes static sites fast, cheap and hard to attack.

Request Data Needs On-Demand Rendering

• A static page is made before any visitor exists.
• So it cannot read the visitor's cookies, headers, session or query string.
• Example: ?name=Asha in the address does nothing on a static page. It was already built.

Press ▶ Run. Both links add ?name=Asha. Only the on-demand page can read it.

Simple lesson: a static page knows nothing about the visitor. Anything per-request needs on-demand rendering.

Data at Build Time

Data Does Not Change Until the Next Build

• A static page shows the data from the moment it was built.
• New posts, new prices, new comments: none appear until you build again.

• The Terminal shows one API call, during the build.
• However many readers visit, the API is not called again.

Keeping Static Sites Fresh

• Rebuild on push = most hosts rebuild when you push to Git.
• Webhook = a web address that starts a build. A CMS can call it when someone presses "Publish".
• Scheduled build = rebuild at set times, such as every night, with your host or GitHub Actions.
• For data that changes every minute, use on-demand rendering instead.

Static Rendering Use Cases

• Blogs and documentation sites.
• Marketing and landing pages.
• Portfolios and personal sites.

Simple lesson: static data is fresh as of the last build. Webhooks and schedules keep it up to date.

The output Setting

output: "static" (Default)

• Every page is static, unless the page says export const prerender = false.
• You do not need to write it. It is the default.

output: "server"

• Every page is on demand, unless the page says export const prerender = true.
• Use it when most of your site needs request data, such as a dashboard app.
• It needs an adapter.

Press ▶ Run. The config says output: "server". Look at the Terminal: λ marks on-demand pages, ▶ marks static ones.

Why hybrid Is No Longer Needed

• Astro 4 had a third value, output: "hybrid", for "mostly static, some on-demand".
• Since Astro 5, "static" already allows on-demand pages with prerender = false. So hybrid was removed.
• If an old guide says hybrid, use "static" (the default) instead.

Simple lesson: output picks the default for every page. prerender changes it for one page.

TL;DR

1. Rendering = turning components and data into HTML.
2. Three moments = build time, request time, in the browser.
3. SSG = HTML at build time. SSR = HTML per request on a server. CSR = HTML built in the browser.
4. Hydration = JavaScript waking up existing HTML. Astro hydrates only islands.

5. Astro's modes:

   • static rendering = SSG, the default,
   • on-demand rendering = SSR, needs an adapter,
   • client:only islands = browser-only parts.
6. Static limits = no cookies, headers, sessions or query strings.
7. Fresh static sites = rebuild on push, webhooks, scheduled builds.
8. output = "static" (default) or "server". hybrid was removed.

Common mistakes

Check Yourself

Exercises

What to Remember

• Rendering makes HTML at build time, at request time, or in the browser.
• SSG is fast and cheap. SSR is fresh and personal. CSR is for rich interactivity.
• Astro is static by default. On-demand pages need an adapter.
• Static pages cannot see cookies, headers or query strings.
• output sets the default. prerender changes it per page.

Next: On-Demand and Mixed Rendering, where Asha adds an adapter and pages that react to each visitor.