On Static Sites
Why we prefer static generation for most web projects, and when dynamic approaches make sense.
The pendulum of web development swings between dynamic and static. We started with static HTML, moved to server-rendered pages, then to single-page applications, and now—blessedly—back toward static sites with islands of interactivity.
At Oaksyl, we default to static. Here is why.
Speed
A static site is just files on a server. No database queries, no template rendering, no runtime computation. When a request comes in, the server sends the file. Done.
This matters. Every 100ms of latency costs conversions. Users abandon sites that feel slow. Search engines rank faster sites higher. Static generation lets you deliver content at the speed of the network, not the speed of your server.
Reliability
Fewer moving parts means fewer things that can break. A static site does not have database connection limits to hit, memory leaks to debug, or server crashes to recover from. It scales effortlessly because serving files is what CDNs were built for.
Security
No database means no SQL injection. No server-side code means no RCE vulnerabilities. A static site has a dramatically smaller attack surface than a dynamic equivalent.
Cost
Static hosting is cheap. Often free. You pay for storage and bandwidth, not compute. For most sites, this means operating costs measured in cents, not dollars.
When Dynamic Makes Sense
Static is not always the right choice. You need dynamic rendering when:
- Content changes frequently — Real-time data, user-generated content, or rapidly updating information
- Personalization is required — Content that varies by user, location, or preferences
- Authentication is central — Pages that require login and show different content to different users
Even then, we prefer hybrid approaches. Static shells with dynamic islands. Edge functions for personalization. Client-side fetching for real-time data.
The Modern Static Stack
Tools like Astro, Eleventy, and Next.js (with static export) make static generation ergonomic. You write components, not templates. You get hot reload in development and optimized builds for production.
The result is the developer experience of a framework with the performance and reliability of static files.
Our Approach
For most marketing sites, blogs, and documentation, we use Astro with static output. For applications that need interactivity, we use progressive enhancement—static first, then layer on JavaScript where it adds value.
This approach serves our clients well. Their sites load instantly, rank well, and cost little to operate. And when they need to make changes, the codebase is understandable and maintainable.
The web was always meant to be documents, connected by links. Static generation honors that original vision while giving us modern tooling. It is a return to simplicity, powered by everything we have learned.
Want to discuss whether a static approach fits your project? Get in touch.