Why this site uses Astro and not Next.js
We build with Next.js, yet this site does not use it. A strict CSP, static HTML and zero JavaScript by default tipped the balance.
We build applications with Next.js and Django. Even so, the studio’s own site is built with Astro. It isn’t a matter of taste: it’s applying to our own site what we tell every client, that you choose the tool for the problem, not out of habit.
The problem to solve
Before writing any code we set three goals anyone can verify:
- A+ on securityheaders.com and MDN Observatory, which requires a strict CSP with no
'unsafe-inline'for scripts. - Lighthouse ≥ 95 in all four categories, on mobile.
- A content site: text in MDX inside the repository, no sign-in, built to last for years.
With those goals, the question wasn’t “which framework do we know best?” but “which one meets all three without fighting it?”.
Next.js and a strict CSP
The Next.js documentation on CSP is clear: to use a nonce, the page must be rendered on every request. Static pages are built before any request exists, so there is nowhere to put the nonce. With nonces, every page becomes dynamic, static optimization and incremental regeneration are disabled, and the HTML can no longer be cached by the CDN.
That left three options in Next.js, and none of them fit:
| Option | What it costs |
|---|---|
| Nonce and dynamic rendering | Every visit runs the server and the HTML isn’t cached. It hurts when the server is far from your visitors |
'unsafe-inline' in script-src |
Observatory takes 20 points off: goodbye A+ |
| Hash-based integrity | The documentation itself marks it as experimental |
What Astro does
Astro computes the hash of every script and style it emits at build time and sends it in each static page’s CSP header. You don’t have to choose between static HTML and a strict policy: you get both. In another post we go through the details and the gaps we had to close.
Two more advantages matter for a content site:
- Zero JavaScript by default. A page that needs no interactivity ships no runtime. This site doesn’t have React installed: the few interactive details (the menu, the project filter, the form) are small hand-written scripts.
- Validated content. Text lives in MDX with a Zod schema. If a client case study is missing its dated consent, the build fails.
The costs, in plain sight
No decision is free. These are the costs of this one:
- The site doesn’t showcase Next.js. We make up for it where it matters: the projects we present are built with Next.js and Django.
- Less familiarity. Astro is written in HTML, TypeScript and CSS; what’s new is content collections and routing. The learning curve was short.
- Framework dependency. The content is MDX with an explicit schema, so it can move to another tool if it ever needs to. That’s the real insurance, more than any vendor’s promise.
The result
On October 8, 2026 we measured production with Lighthouse across the site’s seven templates, on mobile and desktop: 100 for performance, accessibility, best practices and SEO on almost all of them, and never below 95. Security headers score A+ on both tools. You can rerun the measurements from the home page.
When we would choose Next.js
If the project is an application, with sessions, per-user data and screens that change on every interaction, Next.js (or Django) is still our choice: there, per-request server rendering isn’t a cost, it’s what you need. For a content site that has to be fast and verifiably secure, Astro does the job with less effort.
Need to decide the stack for your project? Tell us what you need and we’ll tell you what we’d use and why.