Why this site is still Astro, not Next.js

brandon-ta.com is a content site: a blog, ten project pages, an About page with dated bio versions, and a contact form, in English and Vietnamese. It is built with Astro 5, and the obvious question in 2026 is why it is not Next.js.

The useful answer is not a benchmark of two frameworks. It is what this particular site ships. Every number below was measured on its production build on 16 September 2026, gzipped.

What a page costs

Page	HTML and inlined CSS	JavaScript	Total
Home	27.0 KB	5.2 KB	32.2 KB
Projects index	24.1 KB	5.2 KB	29.2 KB
A project page	24.9 KB	5.2 KB	30.0 KB
About	25.6 KB	5.2 KB	30.7 KB

The 5.2 KB is the client router behind the page transitions. Everything else is HTML and CSS rendered at build time. Nothing on these pages needs React, so none of it loads.

Next.js can serve a fast static page too. What the App Router does not do is leave React out: it ships the runtime so it can hydrate and navigate. For an application that is the right trade. For fifty-odd pages of mostly text it is a cost with nothing to spend it on.

The one place the numbers were bad

Blog posts were the exception, and until today an embarrassing one. Every post loaded 102.7 KB of JavaScript as soon as the browser went idle:

File	Size
React runtime	57.0 KB
framer-motion	38.9 KB
Client router	5.2 KB
The island itself	1.7 KB

All of that drew a reading-progress bar: four yellow edges and an “N% read” pill, whose only job is to set a width and a height as you scroll. Astro made it easy to do badly. One client:idle directive on a React component quietly put React and an animation library on every post.

It is now an Astro component with a short plain script. Same bar, same pill, same numbers. A post loads the 5.2 KB router and nothing more until the reader gets near the comments, and framer-motion is no longer in the build at all.

Where React still earns its place

Comments. Giscus renders inside a React island marked client:visible, so it costs nothing until the comment section scrolls into view. When it does, it brings 71.1 KB: the React runtime and Giscus itself. That is a feature a reader asked for by scrolling to it.

That is the whole argument for Astro here: every kilobyte of JavaScript on this site has to be attached to something a reader actually uses, and the framework makes that the default rather than the exception.

What Astro gives a content site without extra work

• Content Collections with Zod schemas. Blog posts, projects and bio versions are three collections, and a missing or mistyped frontmatter field fails the build before it reaches a page.
• English and Vietnamese routes under src/pages/[locale]/, with each Vietnamese page built from its own content file rather than translated in the browser.
• Static output by default, with a server function only where the site needs one: the endpoint that sends the contact form by email.

When the answer would change

If this domain grew a product behind a login, with accounts, per-user data and dashboards, Next.js would be the better home for it, and keeping two frameworks side by side would stop being worth it.

Nothing like that lives here. The eight products each have their own repository, and the seven with a backend each have their own Supabase project, so this site gets to stay what it is: text, a few pages of evidence, and as little JavaScript as it can get away with.