What happens to performance when a site leaves Astro?

Five sites in the showcase were re-scanned and came back as plain JS frameworks (Next.js, SvelteKit) instead of Astro. Two had never had PageSpeed or CrUX data collected, but three did — so we could compare their scores from when they were still Astro against fresh scores on whatever they show now.

Caveat on github.github.com/gh-stack/: this one wasn’t a clean migration, and we don’t scan often enough to date it precisely — this project doesn’t run on a fixed schedule, just whenever someone kicks off a scan. It showed as Starlight (Astro’s docs framework) on every scan we have between 2026-05-27 and its last Starlight sighting on 2026-07-30. The next scan after that, on 2026-08-02, showed cms: Forwarded, cmsType: parked instead — so the actual change happened sometime in that ~3-day gap, not necessarily on 2026-08-02 itself. The scanner is now fingerprinting whatever that URL redirects to, not necessarily an intentional Next.js rebuild of the same docs. Treat its numbers below as “old Starlight docs vs. wherever this URL currently forwards,” not a like-for-like framework swap.

PageSpeed (lab data)

“Astro” scores below are from our last PSI run while each site still detected as Astro — the 2026-07-16 scan. “Now” is a fresh PSI run on 2026-08-14. Note the ~4-week gap: we don’t have data from in between, so this is “last known Astro score” vs. “current score,” not a tightly-bounded before/after. Lighthouse always audits the exact page URL, so this data isn’t affected by the CrUX issue below.

Two of three dropped in mobile performance after leaving Astro. github.github.com/gh-stack/ took the clearest hit — mobile down 22 points, desktop down 10 — but per the caveat above, that may reflect a redirect target rather than a genuine rebuild. The other two are essentially flat.

CrUX (real-user field data) — this section didn’t hold up

Only github.github.com/gh-stack/ had enough real traffic for Chrome to report field data. Comparing our last CrUX snapshot while it was still Astro (2026-07-12) against a fresh pull (2026-08-14), phone INP improved from 200ms (failing) to 130ms (passing) — enough to flip Core Web Vitals. That looked like a genuinely interesting finding: lab score down, real-user score up, same site, same window. It’s what we led with when we first published this.

It doesn’t hold up, and we want to say clearly why. github.github.com is a shared GitHub Pages origin — CrUX only reports data at the origin level, not per page, so every number above was the combined real-user experience across every project hosted on that origin, not /gh-stack/ specifically. Pulling the full weekly trend (via CrUX’s History API, which our regular scanner doesn’t query) makes this obvious: origin-wide mobile INP actually peaks at 233ms on 2026-07-18 — two weeks before the migration, while gh-stack was still Astro, then falls to 147ms by 2026-08-08, before the migration had time to matter. Desktop INP sits flat at 32–42ms across the whole five months we have data for, migration or not. Neither pattern tracks the framework change; it’s noise from whatever else shares that origin, and there’s no way to separate gh-stack’s own real users from the rest.

Lesson for us, not just a caveat for this post: CrUX is only trustworthy at the granularity it’s actually collected at. For a shared origin like github.github.com — many independent projects under one domain — that’s too coarse to say anything about a single page. The field data here isn’t evidence of anything migration-related for this site, in either direction, and we shouldn’t have presented it as if it were.

Takeaway

What actually holds up: lorenzofiori.art and typable.studio are clean, like-for-like Next.js migrations on their own domains (so no shared-origin problem), and both come out roughly flat on PageSpeed. github.github.com/gh-stack/’s PageSpeed drop (mobile −22, desktop −10) is still worth noting, but now carries two independent caveats: the parked/redirect classification uncertainty above, and the fact we have no usable real-user data to corroborate it either way. Not enough here to say Astro is faster or slower than what these sites moved to. The more interesting finding of this post turned out to be about our own data pipeline, not about Astro.

None of this data makes the case either way, but for what it’s worth: we still think Astro is the best platform to build with, and nothing here changes that. Which makes the more interesting question the one this data can’t answer — not “is Astro fast enough,” but why these particular sites left. Was it a specific feature they needed, a team already fluent in another framework, client work forcing the stack, or just where the project happened to end up? If you know the story behind any of the sites in this showcase, we’d like to hear it.