Why We Ditched the SPA for Our Company Site
Our previous site was a React app. It worked fine. It was also wildly overengineered for what it needed to do — serve some text, a few images, and a contact form.
So we rebuilt it with Hugo. Here’s why.
The Old Setup
The React site had a build pipeline, client-side routing, a Node backend for the contact form, and about 400KB of JavaScript. For a site that was essentially a brochure with a blog.
It loaded in about 2.5 seconds on a mid-range phone. Google PageSpeed scored it in the 60s. It was fine. But “fine” isn’t good enough when your business is building fast websites for other people.
What We Switched To
- Hugo for static site generation — builds in under 200ms
- FormSubmit for the contact form — no backend needed
- Umami for analytics — self-hosted, cookieless, privacy-first
- Listmonk for the newsletter — self-hosted, no third-party data sharing
Total JavaScript shipped: nearly zero. Build time: under a second. PageSpeed score: 98.
Why Static Won
For content-driven sites, static generation is almost always the right call:
Performance. Pre-rendered HTML loads instantly. No JavaScript bundle to parse. No API calls to wait for. The browser gets exactly what it needs and nothing more.
Security. No server to hack. No database to inject. No dependencies with CVEs to patch every week. The attack surface of a static site is essentially zero.
Cost. We host this on a single Hetzner VPS that also runs our other services. The marginal cost of serving this site is effectively nothing.
SEO. Search engines get fully rendered HTML on the first request. No hydration delays, no content shifting, no “please wait while we load the page” spinners.
When SPAs Still Make Sense
We’re not anti-SPA. We build plenty of them for clients. Single-page applications are the right choice when you have:
- Rich interactivity — dashboards, editors, real-time collaboration
- Authenticated experiences — apps where most content is behind a login
- Complex state management — multi-step workflows, drag-and-drop interfaces
The mistake isn’t building SPAs. It’s building SPAs for content sites that don’t need them.
The Takeaway
Match your architecture to your requirements, not to what’s trendy. A blog doesn’t need React. A marketing site doesn’t need Next.js. Sometimes the best technical decision is the boring one.
If you’re building a content site and wondering whether you need a JavaScript framework, the answer is probably no. And if you’re building something that genuinely needs one, we can help with that too.