Does moving to Astro actually make a site faster? I measured mine

I rebuilt jhoox.com on Astro and then measured what it bought me, because I was fairly sure I had just done a week of work for a rounding error.

I had. The framework saved 400 bytes of CSS and made the home page HTML bigger.

The site did get dramatically lighter, by about six megabytes on one page. That had nothing to do with Astro, and finding it was an accident.

What I measured, and what I am not going to quote

Transfer size of the built output: raw and gzipped bytes for every HTML file, the stylesheet, every JavaScript file, and the images each page requests.

No Lighthouse scores, no Core Web VitalsGoogle’s speed measurements, taken from real visitors rather than a test run. This site went live days ago. Search Console needs weeks of traffic before those numbers mean anything, and a lab score on my laptop mostly measures my laptop. Bytes over the wire are what I can state honestly today.

Every number below comes from the production build of the page you are reading.

The framework moved almost nothing

Four hundred bytes off the stylesheet, and that came from deleting dead rules during the rewrite rather than from anything Astro did.

The home page HTML got bigger, by about a kilobyte gzipped. Not a regression to fix. It is Open Graph tags, canonical URLs and JSON-LD that the old page simply did not have, and I added that weight deliberately because search engines want it. Worth saying plainly though: the rebuild made the first document larger, not smaller.

The JavaScript row is the one I am actually pleased with. The site ships zero JavaScript files. The product carousel needs about a kilobyte of script and Astro inlines it into the HTML rather than making the browser open a second connection for 1,094 bytes. Nothing else on the site runs any client-side code.

Six megabytes were sitting in plain sight

The old page loaded four PNG screenshots straight off an iPhone, 1024×1536, roughly 1.6 MB each. Six and a half megabytes on a page whose text weighed two kilobytes.

The new one loads two JPEGs at 356 KB total. Eighteen times less, and well over 99% of every byte I removed from that page.

Two uncomfortable things are true about that.

It has nothing to do with Astro. Converting PNG to JPEG is a two-minute job with sips. I could have done it to the old site last year and skipped the rebuild entirely, at least as far as speed goes.

Nobody noticed for months. The page had been live like that the whole time. I did not find it by profiling. I found it because rebuilding forced me to touch every asset and the file sizes were sitting right there in ls -l.

So why keep the framework

If the performance case is this weak, the fair question is whether the rebuild was worth doing. It was, just not for the reason I would have given at the start.

Four pages by hand is fine. Forty is not. The moment posts have categories, tags, a feed, structured data and an archive, every one of those becomes something you can forget to update on one page out of forty. Nobody catches it. It quietly rots.

What I actually bought was failure at build time instead of in production. Post frontmatter is validated by a schema, so a missing description or an over-long title fails the build instead of publishing a broken <title> and waiting for Search Console to mention it three weeks later. It has already caught me twice, and it does not catch everything — a diagram can lose most of its shapes and still render perfectly happily. Ad slots are injected by one plugin in one place, so they cannot drift between posts. The sitemap, the feed and the category pages are generated from the same content, so they cannot disagree.

None of that shows up in a byte count, and all of it is the real reason to run a generator. I would rather have said so from the beginning than dress it up as a speed story.

What I would do differently

Measure the assets before choosing the solution. I picked a framework and then went looking for what it improved, which is backwards. Fifteen minutes with du -sh at the start would have found the 6 MB of PNGs and correctly told me the rebuild was a maintenance decision.

And I would be suspicious of any rebuild justified by speed. If a site is slow it is overwhelmingly likely to be one specific asset, and the framework serving it is not what saves you.

Field numbers once this has been up long enough to have any, including whether the ad units eat the margin I just gained on images. That one I genuinely do not know yet.

The measuring habit did turn out to transfer. The next thing I counted was the App Store keyword field, where the number that looked alarming also turned out not to be the problem.