Astro vs Next.js for a portfolio or a landing page
When Astro fits a portfolio or landing page and when Next.js is the right call, with HTTP Archive Core Web Vitals data and this site's measurements.
For a portfolio or a landing page, Astro is the better default: it pre-renders every page to HTML and ships no JavaScript unless a component asks for it. Next.js is the better call when the site is really an application, with logins, per-user data and server-side writes. This site is Astro; Clockful, the time tracker I built during my internship at Neoteric, is Next.js.
TL;DR
- Astro for content: every page pre-rendered to HTML, zero JavaScript by default, interactivity opted into per island.
- Next.js for apps: logins, roles and per-user data; its static export gives up cookies, redirects, Server Actions and more.
- Public data: in HTTP Archive's August 2026 mobile data, 71.0% of Astro origins pass Core Web Vitals against 35.1% of Next.js origins, partly because people build different things with each.
What does each framework say it is for?
Astro's docs are direct: "Astro is the web framework for building content-driven websites like blogs, marketing, and e-commerce." It calls itself server-first, with zero JavaScript by default. The same page says other frameworks "excel at building more complex, application-like experiences in the browser: logged-in admin dashboards, inboxes, social networks, todo lists".
Next.js calls itself "a React framework for building full-stack web applications". In its App Router, layouts and pages are React Server Components by default, and you opt into client code with the "use client" directive.
Those two lines answer most of the question. A portfolio is a content site with a contact form. A dashboard is an application.
How much JavaScript reaches the browser?
In Astro, every UI component, React included, renders to HTML and CSS, and its client JavaScript is stripped out. Interactivity is opt-in per component, through islands: client:load hydrates at once, client:idle when the browser is idle, client:visible when the component scrolls into view. A page without islands ships no framework runtime.
Next.js renders on the server too, and Server Components keep their code out of the bundle. The client still runs React, though, to hydrate Client Components and handle client-side navigation, and everything a "use client" file imports joins the bundle. That pays off in an app with many screens and shared state; on a five-page portfolio it is overhead to manage.
Here is the Astro path on this site:
- 01 Build Every page becomes HTML, with its CSS inlined in the head.
- 02 CDN Vercel serves the files; the contact form is the one function.
- 03 Text first The H1 is the largest paint and waits for no script.
- 04 Small scripts Component scripts load as small modules, with no framework runtime.
- 05 Effects last Loops and clips wait for the first interaction; shaders draw only in view.
There are no framework islands here at all. Every component is an .astro file, and the interactive parts (the pause button, the credentials tour, the writing rail) are plain scripts that Astro bundles into small modules. On the home page they come to under 10 KB, gzipped.
Can both produce a static site?
Yes, at a different cost. Astro's default is static: "By default, your entire Astro site will be prerendered". If one route needs a server, such as a contact endpoint, you add an adapter and mark that page with export const prerender = false. Everything else stays static.
This site skipped even that: no adapter, and the contact form posts to a plain Vercel Function next to the static files (how the contact form works).
Next.js can produce a static site too: with output: 'export', next build writes one HTML file per route into an out folder. The docs list what you give up, including cookies, redirects, Proxy, Incremental Static Regeneration, Server Actions and dynamic routes without generateStaticParams(). Many of those are the reason to pick Next.js in the first place.
What about content, translations and page transitions?
A portfolio is mostly writing. Astro's content collections load Markdown and MDX from folders, validate frontmatter with a Zod schema and generate TypeScript types from it. This post is one of those files: its title, description and sources are checked before the page builds. The site's three languages run on Lingui, all of it static (how the multilingual setup works).
For page transitions, Astro supports the browser's native cross-document view transitions (the CSS @view-transition rule), and its <ClientRouter /> adds SPA-style ones when you want more control. This site uses only the CSS rule: pages crossfade with no JavaScript, and readers who ask for reduced motion navigate instantly.
What does public data say?
The HTTP Archive Tech Report takes real-user Core Web Vitals from the Chrome UX Report per origin, and detects technologies on each site's home page and one inner page. Astro and Next.js in the August 2026 dataset, mobile, all origins:
| Mobile, August 2026 | Astro | Next.js |
|---|---|---|
| Origins assessed | 43,850 | 374,612 |
| Good Core Web Vitals (LCP, INP, CLS) | 71.0% | 35.1% |
| Good LCP | 80.6% | 53.1% |
| Median JavaScript per page | 405 KB | 853 KB |
Read it as a picture of two populations, not a verdict on two frameworks. By their own docs, Next.js targets applications and Astro targets content sites, so part of the gap is what people build with each. The report can't separate a framework from the site built on it.
What did this site measure?
This site is Astro 7, Tailwind 4 and one variable font, served as static files from Vercel.
Two honest notes:
- I did not build the same site in Next.js, so I can't tell you what it would have scored. That is why the comparison above uses public data.
- The framework didn't earn the score alone. On the afternoon of 7 October the home page fell to 67-74 with no framework code involved: animation loops running during load, a class that restyled every element in the offscreen sections, and scripts forcing layouts. Fixing those brought it back. What Astro gave me is the starting point: zero JavaScript, so there was nothing to remove.
The same pattern shows up in Lighthouse runs on 16 developer portfolios: the immersive 3D sites scored far below the minimal ones. The whole build story is in how this site was built.
Since then I have measured one real move: yws.lu, a client site I built in Next.js in 2025. It scored 23-45 on Lighthouse performance, and 94-100 after the rebuild in Astro (Lighthouse 13.5, local, the median of 3 runs). The details are in the yws.lu case study.
When is Next.js the right call?
Pick Next.js when most screens depend on who is looking at them. Clockful, the role-based time tracker from my internship at Neoteric, is that kind of project: logins, roles, per-user data, and Postgres row-level security on every table.
The Next.js docs cover that ground in one guide: authentication, sessions in cookies, authorization in a data access layer, and Server Actions for writes. Astro can render on demand too, but its own docs point to other frameworks for logged-in dashboards. Next.js also wins when the landing page belongs to an existing Next.js product: one codebase beats two stacks for one marketing page.
When is Astro the right call?
When the site is content first: a portfolio, a landing page, docs, a blog, a small business site. You can still write React, Preact, Svelte, Vue or SolidJS where you need interactivity, and only those islands ship code. Hosting is a CDN plus a build, with a server function only where you need one.
Which one fits your kind of site?
| Your site | Pick | Why |
|---|---|---|
| Portfolio, CV, blog | Astro | Static HTML, zero JS by default, content collections |
| Marketing landing page | Astro | Same, plus an island for the one interactive widget |
| Landing page inside a Next.js product | Next.js | One codebase, one deploy |
| Dashboard with logins and roles | Next.js | Server Components, auth guide, Server Actions |
| App with per-user data on every screen | Next.js | Built for on-demand rendering |
| Content site with one or two dynamic routes | Astro | Static by default, prerender = false per route |
How do you decide for your project?
Write down what the site must do in its first year. If the list says "log in", "dashboard" or "per-user data", start with Next.js. If it says "pages, posts, a contact form", start with Astro, then measure on a mid-range phone.
The rest of what I've built is on my work page; Clockful, the role-based app, is on my CV.
Sources
- Astro docs: Why Astro? (opens in a new tab) (accessed )
- Astro docs: Islands architecture (opens in a new tab) (accessed )
- Astro docs: On-demand rendering (opens in a new tab) (accessed )
- Astro docs: Content collections (opens in a new tab) (accessed )
- Astro docs: View transitions (opens in a new tab) (accessed )
- Next.js docs: Introduction (opens in a new tab) (accessed )
- Next.js docs: Server and Client Components (opens in a new tab) (accessed )
- Next.js docs: Static exports (opens in a new tab) (accessed )
- Next.js docs: Authentication (opens in a new tab) (accessed )
- HTTP Archive Tech Report: about the data (opens in a new tab) (accessed )
- HTTP Archive Tech Report: Astro vs Next.js (opens in a new tab) (accessed )