Astro Website Templates / Static Web Guide
Astro Static Rendering vs Server Rendering
Choose Astro static or on-demand rendering by content freshness, authentication, runtime requirements and the services your pages need.
Astro static rendering prepares pages during a build. Server rendering, also called on-demand rendering, prepares a route when it is requested using a compatible runtime. Choose per project and route requirements, especially content freshness, private data and hosting support.
A static page can still include browser interactions and use external services. A server-rendered page can still be mostly ordinary readable content. The distinction concerns when and where the response is generated, rather than whether the design contains movement or buttons.
What static rendering means for a template
A static template combines source content, layouts and components during the build. The host serves the resulting public files. If you change a source article, the public version changes after the next build and deployment.
This can be a straightforward model for service descriptions, documentation and editorial pages whose publication can follow a deliberate release process. It also gives the maintainer a concrete output to inspect before publication.
However, a build-time copy of external information is still a snapshot. If a page displays availability or pricing fetched during the build, decide how often it must be refreshed and what happens when the upstream source is unavailable.
What on-demand rendering changes
A route rendered on demand can use request-specific information when preparing its response. That can matter for authenticated content or information that must be retrieved at request time.
The deployment now needs a compatible runtime and adapter. Review logs, environment settings, runtime limits and service availability as part of the operating plan. These are additional responsibilities even if the page looks identical to a static version.
Astro’s Astro 5 on-demand rendering guide documents the rendering modes and adapter requirement. Use the integration version appropriate to your project and host instead of combining configuration from unrelated examples.
Understand the Astro 5 settings
With the default static output, ordinary pages are prerendered. After configuring an adapter, a particular route can opt into on-demand rendering with:
---
export const prerender = false;
---For a project intended to render routes on demand by default, Astro 5 supports output: ‘server’ in its configuration. A selected route can then opt into prerendering with prerender set to true.
These are rendering controls, not a complete deployment configuration. An adapter compatible with the destination runtime is still required for on-demand routes. Do not switch the setting merely to silence a route error without understanding which part of the website now needs a server.
Separate browser features from server requirements
An accordion, navigation menu or local calculator can run in a visitor’s browser on a static page. Such features do not automatically require a server-rendered document.
A contact form can submit from a static page to an external form service. The form still needs a real endpoint, validation, failure handling and a delivery test. A static interface does not remove the underlying service requirement.
Private account information needs a different analysis. Do not generate it into public HTML during a static build, and do not treat hidden browser elements as access control. Identify where authentication and authorisation actually happen before selecting an implementation.
Choose by route responsibility
| Route | Question that guides the decision |
|---|---|
| Service description | Can updates wait for a rebuild and deployment? |
| Documentation article | Is the published revision deliberately versioned? |
| Public availability page | How fresh must the displayed information be? |
| Account dashboard | How is the requesting user’s access verified? |
| Enquiry form | Which service receives and processes the submission? |
This table is a planning tool, not a rule that a particular page name mandates one rendering mode. For example, a public availability page could fetch selected data in the browser, render on demand or publish a clearly dated snapshot, depending on the requirements.
Consider content editing and preview
Static publishing can suit a repository workflow where changes are reviewed and released together. Editors must understand that saving a source file is not always the same event as updating the public website.
On-demand rendering can retrieve content at request time, but that does not automatically supply a CMS, revision history or editorial approval. Those features belong to the content system and publishing process.
For source-driven articles, Astro content collections explain one structured approach. Keep the content model decision separate from the decision about when a route renders.
Compare failure and recovery behaviour
Ask what happens if an external service is unavailable. A static build may fail, preserve the previous release or publish a fallback, depending on the implementation. A runtime request may fail for a visitor or return cached or fallback content.
Write down the intended behaviour for important routes. A useful failure message should tell the visitor what to do next without exposing private diagnostics. Keep logs available to the maintainer and provide a practical recovery path.
Match the product to the deployment
Inspect a template’s configuration and requirements before purchase or launch. A screenshot cannot tell you whether a page is prerendered, personalised or connected to a live service.
The InvoicePilot listing is an Astro marketing example to evaluate against a concrete plan. Do not assume that a product marketing template includes the runtime behaviour of the software it describes.
Use the production build guide to verify the selected output and publication path. The Astro website templates overview places rendering requirements within the complete template decision.