Why We Build Our Website Statically

When someone asks what our website is built with, surprise often follows: not with WordPress, not with a large JavaScript framework, but statically. This article explains what that means, what we work with, what we gain from it, what we accept in return and when a framework is the better choice anyway.

What “static” means

A static website consists of ready-made files (HTML, CSS, little JavaScript) that are generated once on publishing and then delivered unchanged. There is no database query and no rendering on the server for each page request. The browser gets a finished page and can start displaying it immediately. More in the article The Comeback of the Static Website.

How we work

• Astro generates finished static pages from templates and content. By default it delivers only the JavaScript a page really needs.
• Tailwind CSS provides the styling, TypeScript helps with code quality.
• Content lives as Markdown and JSON files in the project; there is no CMS and no database.
• Delivery is as files on our own server. Fonts and scripts come from there, not from third parties.
• Little JavaScript: a few small scripts control, for example, the menu, the switch between light and dark or the contact form. A page is not assembled in the browser first.

So we do not give up tools but runtime ballast: the result is plain HTML with very little script.

What we gain

• Speed: in testing with PageSpeed Insights, the home page, the app page and a blog article each reached 100 points on mobile and desktop (as of October 2026). Small files, early-loaded fonts and good caching contribute.
• Small attack surface: without a database and a server application, there is less to attack or maintain. The only server-side script is the small one for the contact form.
• Maintainability: fewer moving parts and manageable dependencies. Content is simple files that can be versioned.
• Data protection: no cookies, no third-party scripts, no fonts from foreign servers.
• Low-cost operation: a simple web server is enough.

What we accept in return

• A build step: changes have to be built and uploaded.
• No CMS for laypeople: anyone who wants to change texts edits files, ideally with us. For editorial teams we would connect a headless CMS.
• Dynamics need add-ons: anything that processes data (forms, search, login) needs additional building blocks.
• More discipline in structure: content and templates must be cleanly separated.

When a framework is the better choice

A framework such as React or Vue pays off when an application has a lot of state in the browser, updates in real time, shares many interactive building blocks or when a team is to work on a common standard. For client projects we therefore choose the tool that fits the task. You will find a detailed weighing in the article Vanilla JS vs. Frameworks.

Decision aid

A static website fits well when:

1. content is mostly read and rarely changed,
2. few personalized or real-time functions are needed,
3. speed, security and data protection matter,
4. changes may go through developers or a connected CMS.

A dynamic application fits better when users generate a lot of data, log in and collaborate in real time.

Briefly answered

Isn’t “static” old-fashioned? No. Modern generators combine the simplicity of static files with today’s development tools.

Is interactivity still possible? Yes, in a targeted way: small scripts for menu, forms or filters, individual interactive building blocks where needed.

How fast are static pages really? Usually considerably faster than dynamically generated ones. Images, fonts and caching also matter (see web performance).

Conclusion

Our website is built statically because it mainly shows content and is meant to be fast, secure and data-sparing. For other tasks we use other tools. The question is never “framework or not” but: what does this task need? If you would like to clarify that for your project, you will find our offer under development.