Astro Crash Course #11 - Server Side Rendering
Chapters6
Describes the default buildtime prerendering model and why some pages need to be rendered on demand.
Net Ninja shows how to switch Astro from static prerendering to on-demand server-side rendering using adapters and a simple prerender flag.
Summary
Net Ninja demonstrates a practical shift from Astro’s default static prerendering to server-side rendering on demand. He begins by recalling how pages were previously built at buildtime, resulting in a static site where even dynamic data like book reviews stayed pre-rendered. The tutorial then explains why buildtime rendering isn’t ideal for content that changes frequently, such as product lists or user dashboards that require authentication. A server adapter is introduced as the key to enabling on-demand rendering, with Net Ninja choosing Netlify as the deployment target and guiding viewers through the installation steps using npx astro add netlifi. After wiring the adapter, he shows how to mark a page as on-demand by exporting a prerender flag set to false in the page’s front matter. Data fetching is demonstrated via a dummy JSON API, pulled directly in the front matter with fetch, ensuring fresh content on each request. The visual output renders a list of products, proving the page updates live from the API data. The session concludes by reiterating when server-side rendering is advantageous: for rapidly changing data or authenticated user dashboards where pre-built pages would become stale. Net Ninja emphasizes that SSR is optional and only necessary when data changes require up-to-date rendering on demand.
Key Takeaways
- Astro renders pages at build time by default, creating a static site ready to serve as-is.
- To render pages on demand, add a server adapter (e.g., Netlify) via the command shown (npx astro add netlifi).
- Add a prerender flag exported in the page’s front matter and set it to false to enable on-demand SSR for that page.
- Fetch data from an API directly in the page (front matter) so each request gets fresh data; this uses fetch to pull a JSON endpoint and render products.
- Using SSR is ideal for frequently changing content or authenticated user dashboards where static pages would be outdated or unsuitable.
Who Is This For?
This is essential viewing for Astro developers weighing the trade-offs between static prerendering and on-demand SSR, especially if you’re dealing with dynamic content or user-authenticated sections.
Notable Quotes
"Okay then my friends. So far when we've been making this website we've been doing so in such a way that all the pages are built by Astro at buildtime right and we end up with a static site with a bunch of pre-rendered pages that we can then deploy."
—Sets up the problem: static prerendering as the default approach in Astro.
"However, sometimes building and rendering all the pages at buildtime doesn't suit what we need from a website."
—Explains why SSR might be required for dynamic content.
"We can opt in to that by adding a server adapter."
—Introduces the solution for on-demand rendering.
"export const prerender = false. And this is us telling Astro that we don't want it to render the page at build time, but instead render it on demand on the server when a request comes in for it."
—Shows the exact mechanism to enable SSR for a page.
Questions This Video Answers
- How do I enable server-side rendering in Astro with a Netlify adapter?
- What is the prerender flag in Astro and how does setting it to false affect rendering?
- Can I fetch fresh data on every request in Astro using SSR?
- Which Astro server adapters are available and how do I choose one for my deployment?
- What are the pros and cons of SSR vs static prerendering in Astro pipelines?
Astro SSRserver adaptersNetlify (Netlifi) adapterprerender flagfetch API in Astro front matterdynamic content renderingon-demand rendering
Full Transcript
Okay then my friends. So far when we've been making this website we've been doing so in such a way that all the pages are built by Astro at buildtime right and we end up with a static site with a bunch of pre-rendered pages that we can then deploy. Even with all the book details pages we've used the get static path function to build out a page for each and every book uh review markdown file that we have. And all of these pages are pre-rendered, pre-built, and after the site gets deployed, the server doesn't need to do anything to render any new pages or content, right?
It's all done beforehand. However, sometimes building and rendering all the pages at buildtime doesn't suit what we need from a website. And sometimes we need pages rendering on the server on demand. For example, it might be that your site uses maybe an external API to fetch content and that content could change constantly. For example, it could be a list of products which get updated frequently throughout the day. And for something like that, having a statically built page wouldn't really be appropriate because it would likely show out of product content as the product data changes. Another example would be a user dashboard page.
We couldn't statically build that page because it would change for each user and also probably update quite frequently too and it would require them to authenticate. So ideally when you've got a lot of data changes you need to build and render those pages on demand on the server when the request comes from the client and we can do that with Astro. We can tell it that for certain pages we want it to be rendered on the server on demand and not at build time. So to demo this I've already added a new product folder and inside that an index page component.
So the path to reach this page would just be forward/roucts. Inside this component, I've already done some very basic setup by making the front matter section with the layout import and also this product interface ready for the data we'll be fetching. I've also added a basic template that uses the layout. The next thing I want to do then is tell Astro to render this component not at buildtime but on demand on the server. And to do that, the first thing we'll need to do is add something called a server adapter to the project. So, like we've already talked about in this series several times, by default, Astro renders everything at buildtime.
And thereafter, the server doesn't need to do any work because everything's already been built into static HTML pages, and the only thing left to do is serve them to the browser. However, when we need the server to do some work, like rendering pages on demand, we can opt in to that by adding a server adapter. Now, there's a bunch of different server adapters available, and depending on where you deploy your Astro site to, you'll want to choose an adapter appropriate for that service. Out of the box, Astro maintains four server adapters for Cloudflare, Netify, Netifly, Netifi, Node, or Versel.
I'm eventually going to be deploying this site to Netifi. So, I'm going to select that one right here. Now, when you click on that, it's going to show us some installation instructions. And the easiest way to add the adapter is to use this command right here, which is npx astro add netlifi. So let's copy that command and then head back to the code. Okay, so I'm going to paste that command in right here and then press enter. And when I do that, we'll have to walk through a few questions. The first one is to give permission for Astro to run an install command.
So I'm going to hit enter to select yes for that. And then after that, it's going to want to make changes to the Astroconfig file to register the new server adapter. So we can hit yes for this as well. And once that's done, the Netifi server adapter is ready to be used. And we just need to do one more thing to mark a page component as an ondemand one. So not one that's going to be pre-built. So let's come back to the products component then. And at the top of the front matter, we should say export and then a constant.
And this is going to be called pre-render. And it must be called this exactly. Then we set that equal to false. And this is us telling Astro that we don't want it to render the page at build time, but instead render it on demand on the server when a request comes in for it. And that means that every time a user requests this page, it's going to get a newly rendered up-to-date version of the page and not a pre-built one. So we've added the adapter, we've added this export to the top of the component. And now we just need to make the page as normal.
So then I've already made this interface right here called product, right? Which only defines a title property which must be a string. And now I want to fetch the product data from some endpoints. Now for the sake of this tutorial, we're going to be using a dummy JSON API which returns some dummy JSON data. But in reality, you might be using your own endpoint or database. But anyway, we can fetch data directly from this front matter using the fetch API. And then whenever a request for this page hits the server, the fetch for the data gets run, making sure we get the freshest data available.
And then the page gets built and sent back to the browser using that data. So I'm just going to paste this fetch in. And it's all really simple. We just make the fetch request to this dummy JSON endpoint. And then we pass the JSON. We access the products property on it, which is then going to return an array of products. So then in the template down here, we can output those products. So let's do that. I'm going to use some curly braces and then I'm going to say products domap and invoke it. Then I'm going to take each product in the callback function and I want to return a little bit of template for each one inside parenthesis.
And the only thing I really want to return is a div tag where we can just output the product title by using curly braces and then saying product.title inside them. Then we can save this file. Just test it out in the browser. All right, so that works. There we go. And if we refresh, we can see, yep, it's still working. Awesome. So, that is how we opt into server side rendering. Again, that's important if your data is going to change frequently and you don't want to keep building your site several times a day or for dynamic content such as a user if they have to authenticate and we need that user data for a user dashboard or
More from Net Ninja
Get daily recaps from
Net Ninja
AI-powered summaries delivered to your inbox. Save hours every week while staying fully informed.



