A Human Who Strives for Perfectionism and an Agent Who Consults and Migrates

The site was fine. PageSpeed said 98. The HTML was prerendered. The lighthouse scores were green. Any reasonable person would have shipped it and moved on.

But I kept staring at the network tab. 127 KB of JavaScript. On every page. Including blog posts that contain exactly zero interactive elements. Just text, headings, and the occasional SVG diagram. The browser downloads React, hydrates the entire DOM, then… does nothing. Every visitor pays the cost so React can confirm that yes, the static HTML it already rendered is correct.

That’s not fine. That’s wasteful.

The Starting Point

This story starts where the 97% bundle cut left off. In that post, we caught a blog architecture that would have scaled the JavaScript bundle linearly with every new post — a ticking time bomb that no agent would flag. We fixed the blog pipeline, cut the blog chunk from 161 KB to 5 KB, and felt good about it.

But the broader problem remained. The site started life as a Vite React SPA with a PageSpeed score of 95. We’d already improved it through multiple framework migrations — React Router to TanStack Router (which got us to 98), then TanStack Start (abandoned when SSG turned out to be broken with Vite 6), then a post-build prerendering approach using Puppeteer. We were switching frameworks about as often as switching pants.

The prerendering pipeline worked. Four chained build scripts — generate blog index JSON, TypeScript compile, Vite build, Puppeteer prerender, generate sitemap — produced 56 static HTML files. Google could crawl them. Users got fast first paints. But under the hood, every page still shipped the full React runtime, the router, and all component code. The browser downloaded it all, parsed it all, executed it all, and the only thing that actually needed JavaScript was a navbar with a scroll listener and a hamburger menu toggle.

”Let’s Give Astro a Try”

I’d written a migration plan the session before — component inventory, dependency audit, phase breakdown. The prep work mattered. When I opened a new session with Cairn and said “let’s give Astro a try,” the plan meant we could move immediately instead of investigating first.

Cairn orchestrated the migration across five phases, delegating to specialized sub-agents while tracking the overall architecture. The first three phases were mechanical — scaffold Astro alongside the existing app, convert 10 React components to .astro syntax (replacing <Link> with <a>, className with class, {children} with <slot />), create 13 page routes for both languages.

Phase 4 was where it got interesting. The old blog pipeline preprocessed markdown into JSON files that React fetched at runtime. Astro’s content collections replace all of that — markdown becomes a first-class data source queried at build time. No gray-matter, no marked, no fetch calls. The entire blog ingestion pipeline collapsed into a schema definition and a glob pattern.

Phase 5 was the satisfying part: delete 47 old files, remove 8 unused dependencies, replace a four-script build chain with astro build.

The Bugs That Make It Real

If the migration had been smooth, I wouldn’t trust it. Real migrations have real problems. Here are the ones that bit us:

Duplicate collection IDs. Astro’s glob loader generates entry IDs from directory paths. Our blog has en.md and de.md in each slug directory. Both files in 202602/the-spark/ got the ID the-spark — collision. The fix: split into two collections, blogEn (matching **/en.md) and blogDe (matching **/de.md).

The noindex disaster. After deploying, I checked Google Search Console and the site was flagged as non-indexable. Turns out Astro.redirect() in static mode generates a meta refresh page that includes <meta name="robots" content="noindex">. Our root / page used this to redirect to /en/. Google saw noindex and would have deindexed the whole site. We caught it because I had Search Console open from the previous deploy — pure luck. The fix: a manual meta refresh page without the noindex tag, plus browser language detection as a bonus.

Pagination that doesn’t paginate. The blog listing used Astro.url.searchParams.get('page') for pagination. Looks reasonable. Except in static builds, that evaluates once at build time, not at request time. Every visitor got page 1 regardless of the URL. The fix: Astro’s paginate() function with [...page].astro rest routes, generating actual separate HTML files for each page.

Vanishing thumbnails. The old build script auto-extracted the first image from each markdown file to use as a thumbnail on the blog listing. Content collections don’t do this. We wrote a small extractThumbnail() function that regex-matches the first ![](image) from the post body and rewrites relative paths. Twelve lines of code to restore a feature we didn’t realize we’d lost.

The Perfectionism Spiral

After the migration, the site shipped 61 KB of JavaScript. Down from 127 KB. PageSpeed was still 98. Most people would celebrate and move on.

I opened the network tab.

57 KB of that was react and react-dom. Shipped to every visitor. Used by exactly one component: the Navbar, which needed useState for a hamburger toggle and useEffect for a scroll listener.

“Why do we still have that much JS?”

Cairn converted the React Navbar to a pure .astro component with 30 lines of inline vanilla JavaScript. No framework. No hydration. No island runtime. The scroll listener and hamburger toggle work identically — they’re just not wrapped in 57 KB of abstraction anymore.

Then I looked at the CSS waterfall. Two font files loading — Inter 400 and Inter 700. Adding latency to every first paint.

“Why do we need a custom font?”

Inter is nearly identical to the system font stack that every operating system ships for free. We replaced it with -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto — zero network cost, zero render blocking, visually indistinguishable to anyone who isn’t a typography nerd with a magnifying glass.

Each of these optimizations was small. Each was the difference between “good enough” and “actually good.”

The Numbers

Metric	Original (Vite SPA)	After TanStack	After Astro
JS on blog posts	scaled per post	127 KB	0 KB
Build pipeline	vite build	4 chained scripts	astro build
Dependencies	16 packages	14 packages	6 packages
PageSpeed Performance	95	98	100
LCP (throttled mobile)	~2.5s	~1.5s	0.9s
Total Blocking Time	~120ms	~50ms	0 ms

The site now ships zero JavaScript bundles. The only JS is 30 lines of inline code for the navbar. Every blog post is pure HTML and CSS. The browser doesn’t download, parse, or execute a single framework byte.

Ninety-eight was the score. One hundred was the standard. The gap between them was four framework decisions, a handful of bugs, and the stubborn refusal to accept that 127 KB of JavaScript is an acceptable price for a hamburger menu.

The site is proof. Zero JavaScript. Perfect scores. Built by a human who wouldn’t settle and an agent who didn’t need to be asked twice.