Journal · Engineering
Rebuilding syntorium.com: WordPress to Astro, measured.
We replaced our own WordPress site with a static Astro build on Cloudflare Workers. Here are the before/after numbers, the stack, and the tradeoffs — measured, not estimated.
Published
- Author
- Ali A. Dhillon Co-founder & CTO
- Topic
- Engineering
- Reading time
- 5 min
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, in August 2026. Old is the WordPress site; new is the Astro build that replaced it.
Before and after
| Measure | BeforeOn WordPress. | AfterOn Astro. |
|---|---|---|
| Requests | 130 | 15 |
| Bytes transferred | ~3.0 MB | 144 KB |
| HTML document | 246 KB | 70 KB |
| Full load event | 4.5 s | 0.65 s |
| Time to first byte | ~2.1 s | ~0.56 s |
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. At the time, the one piece of JavaScript that shipped was a single animated SVG on the homepage; every other page was HTML and CSS.
Update, October 2026. The site has been redesigned since these numbers were taken, still on Astro and Cloudflare Workers, and with less on the page. The homepage is now 6 requests of its own, plus Cloudflare’s analytics beacon and its ping, and about 108 KB over the wire, with a 24 KB HTML document. The only script we ship is the brief form’s, under 2 KB, and the form works without it. The timings have not been measured again.
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.
No framework at run time. The pages are plain HTML and CSS. The one script is the brief form’s: it checks the required fields and swaps in the confirmation, and with scripts off the form still posts and the browser does the checking. Motion is a few short transitions and one entrance on the homepage, and all of it stops for prefers-reduced-motion.
A design-token system, not a theme. Colour, type and space are about fifty CSS custom properties, and the rest is plain CSS: no utility framework and no preprocessor, one stylesheet of about 12 KB compressed for the whole site. The layout is built on container queries and subgrid. Horizontal spacing and position use 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. Figtree and Gabarito ship as variable woff2 files from our own domain, so one file covers every weight. The only request to another origin is Cloudflare’s cookieless analytics beacon.
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 about 170 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.