Astro vs Next.js for a Developer Portfolio Site
Published:
Umair Akhter
5 MIN READ
The two most common framework choices for a developer portfolio in 2026 are Astro and Next.js. Both are excellent. They solve different problems. Choosing the wrong one won’t ruin your site, but it will add friction you didn’t need.
I’ve shipped production sites in both. This is the comparison I wish I’d had before choosing.
What each framework is optimized for
Next.js is optimized for React applications. It’s built by Vercel, ships with an excellent developer experience, and handles everything from static sites to real-time applications. Its default mental model is “React app that can also do server-side rendering.”
Astro is optimized for content-heavy sites. It’s framework-agnostic, ships zero JavaScript by default, and treats HTML as the output rather than a side effect of component rendering. Its default mental model is “static site that can also include interactive islands.”
For a portfolio with a blog and some interactive tools — which is exactly what this site is — those differences have practical consequences.
Bundle size comparison
Here’s the real-world difference on a simple blog post page:
| Framework | Default JS shipped | Time to Interactive |
|---|---|---|
| Next.js (App Router) | ~85–120KB | ~400–600ms |
| Astro (static page) | 0KB | ~50–100ms |
Next.js ships the React runtime, the Next.js client runtime, and the hydration payload for every page — even pages that have no interactivity. You can reduce this with careful configuration, but you’re fighting the defaults.
Astro ships nothing by default. If your blog post has no interactive elements, it ships no JavaScript. If it does — a comment form, a tool, a demo — it ships only the script for that specific island.
For a portfolio, most pages don’t need JavaScript. Shipping 100KB of framework runtime to display a list of blog posts is a real performance tax, even if it doesn’t feel that way on a fast connection.
Deployment and cost
Both frameworks deploy easily to Cloudflare Pages, Vercel, and Netlify.
The practical difference: Next.js has features (Server Actions, API routes, Edge Runtime) that are best used with Vercel, which is Next.js’s own hosting platform. That’s not a lock-in, but it’s a gravitational pull. Astro has no hosting affiliation and works identically across all major static hosts.
For a personal portfolio with low traffic: both are free on their respective free tiers.
For a portfolio that might get traffic spikes (submitted to Hacker News, featured in a newsletter): Cloudflare Pages on Astro is essentially infinitely scalable on the free tier because it’s static files on an edge network. Next.js on Vercel is free up to 100GB bandwidth per month, after which you’re on a paid plan.
Developer experience
This is where Next.js has a real edge. The App Router, React Server Components, and the overall DX are genuinely excellent. If you already think in React, Next.js feels natural immediately.
Astro has its own component syntax (.astro files) which takes a few hours to internalize. Once you’re comfortable, it’s fast to work in — but there’s a learning curve that doesn’t exist if you already know Next.js.
My honest take: if you’re starting from zero, the Astro learning curve is worth it for a content site. If you already have a Next.js portfolio and it works fine, the friction of migrating is not worth the performance gain.
When to choose Astro
- You want the fastest possible load times with minimal configuration
- Your site is primarily content: blog posts, project pages, a contact form
- You want to use Markdown for blog posts with typed frontmatter
- You’re deploying to Cloudflare Pages for free edge hosting
- You don’t need complex client-side state across pages
When to choose Next.js
- You already know React deeply and want to stay in that ecosystem
- You’re building features that require server-side logic: authentication, database queries, real-time updates
- You’re building something that looks more like an application than a site
- You’re deploying to Vercel and want the tightest possible integration
The hybrid approach
Both frameworks support a “mostly static, some dynamic” model. Astro’s hybrid rendering mode lets you mark specific routes as SSR while keeping everything else static. Next.js does the same with its static generation and server-side rendering options.
For a portfolio that needs one server-side endpoint (a contact form, an API that proxies a third-party service), hybrid mode in Astro is cleaner than Next.js for this use case because the static side genuinely ships zero JavaScript.
What I chose and why
I built this site with Astro. The reasons:
- The tools I’m shipping — Word Counter, Text Case Converter, Base64 Encoder/Decoder — are small interactive islands. Astro’s island architecture is exactly right for this.
- The blog posts are Markdown. Astro Content Collections handle this better than anything else I’ve tried.
- I’m hosting on Cloudflare Pages for free. Astro’s static output is a perfect fit.
- I don’t need persistent client-side state between pages. If I did, I’d reconsider.
If I were building a portfolio that also served as a SaaS dashboard, or that had user accounts and real-time features, I’d choose Next.js. For a site that shows work and publishes writing, Astro is the right call.
The framework decision matters less than the decision to ship. Both Astro and Next.js will produce a good portfolio if you spend the time on the content. A mediocre portfolio on the wrong framework beats a perfect portfolio that never launches.
Pick one. Build the thing. That’s the only part that matters.