Rebuilding syntorium.com: WordPress to Astro, measured.

The site you’re reading this on used to be a WordPress install: a purchased agency theme, Elementor, Slider Revolution, and the accumulated weight that stack brings. It worked, but it was slow, it looked like the theme it was, and its sitemap was full of the theme’s demo pages. We rebuilt it the way we build client platforms — and because “fast” is a claim everyone makes, we measured it.

The numbers

Same homepage, same network, same day. Old is the WordPress site; new is this one.

	WordPress	Astro	Change
Requests	130	15	−88%
Bytes transferred	~3.0 MB	144 KB	−95%
HTML document	246 KB	70 KB	−72%
Full load event	4.5 s	0.65 s	−86%
Time to first byte	~2.1 s	~0.56 s	−73%

No caching tricks, no cherry-picking — the new site is simply doing less. There is no jQuery, no slider library, no page-builder runtime, no Google Fonts round-trip, and no analytics pixel burning your bandwidth. The one piece of JavaScript that ships is a single animated SVG on the homepage; every other page is HTML and CSS.

The stack

Astro 7, fully static. Every page is pre-rendered at build time into plain HTML. Content — 16 case studies, 12 service pages, this journal — lives in markdown files with typed frontmatter (Astro content collections), versioned in git next to the code. Publishing is a push to master.

One Vue island. The animated circuit graphic on the homepage is the only hydrated component. It pauses itself when the tab is hidden or it scrolls out of view, and it honors prefers-reduced-motion.

A design-token system, not a theme. The whole visual language is ~400 lines of CSS custom properties — an oklch palette, a type scale, and a handful of component classes. Tailwind v4 provides utilities; its reset is switched off. Every component uses CSS logical properties, so the future Arabic (RTL) build is a dir attribute away, not a rewrite.

Cloudflare Workers, static-assets mode. The site deploys straight from GitHub to Cloudflare’s edge. A very small Worker handles the two things static files can’t: relaying the contact form to email, and answering 410 Gone for the old theme’s junk URLs. Every WordPress-era URL that mattered 301-redirects to its new home, so nothing indexed goes dark.

Self-hosted fonts. Geist and Geist Mono ship as woff2 subsets from our own domain. The visitor’s browser talks to exactly one origin.

The tradeoffs, honestly

There is no CMS. Content edits are markdown commits. For a studio where everyone writes in an editor anyway, that’s a feature — the entire site, content included, is reviewable in a pull request. It would be the wrong call for a client whose marketing team publishes daily; that’s what our headless-WordPress builds are for.

Static means static. The contact form needed real infrastructure — a Worker endpoint that validates, filters bots, and relays to email. That’s ~150 lines with unit tests, and it’s the only server-side code on the whole property.

A rebuild is a chance to tell the truth. The old theme shipped with counters claiming things about us that weren’t real. Migrating forced an audit of every number on the site; what’s published now — projects, clients, retention — is what we can stand behind. That was the most valuable part of the exercise, and no framework does it for you.

What we’d tell a client

This is the same playbook we run on client rebuilds: measure the current site, port the design system to tokens, pre-render everything that can be pre-rendered, put the one dynamic endpoint behind a tiny worker, and map every old URL before cutover. The framework matters less than the discipline — but if the site is mostly content, static-first is very hard to argue with in 2026.