I didn’t wake up one day hating Next.js. This wasn’t a rage rewrite. It was more like that quiet feeling you get when something that used to fit no longer does. My portfolio site had been on Next.js for about three years. It looked great. Custom UI, iOS-inspired design, bought-from-Figma kind of polished. But over time, maintaining it started to feel heavier than the site itself deserved. At some point I realized I was spending more energy keeping the framework happy than actually showing my work. So I moved it to Astro. And honestly, for this specific use case, it was the best decision I could’ve made. Next.js was too much for what I needed My portfolio isn’t a product. It’s not a SaaS. There’s no auth, no dashboards, no complex state. I just want to present projects, write a few articles, and have some custom UI that feels like me. Next.js can absolutely do that. But it brings a lot along for the ride. Routing conventions, rendering modes, config choices, version churn. None of that is bad, but for a simple site, it adds mental overhead. At some point I asked myself a simple question: why am I using a full React framework for something that barely needs JavaScript? Astro answered that question without trying to be clever. The build time difference was impossible to ignore This was the first hard signal that I was overengineering things. With Next.js, my portfolio build time was around 1 minute and 13 seconds. That’s 73 seconds. Not terrible, but also not great for a site that barely changes. 1 minute and 13 seconds After moving to Astro, the build time dropped to 13 seconds. 13 seconds That’s a reduction of 60 seconds, which comes out to roughly an 82% faster build. 82% faster build This wasn’t about benchmarks or bragging rights. It was about feedback loops. When your site builds that fast, you’re more willing to ship small improvements. You don’t hesitate to tweak a page or fix a typo. That matters more than people admit. Less JavaScript, fewer problems Astro’s biggest win for me is how little JavaScript it ships by default. Astro renders pages to static HTML and only sends JavaScript to the browser when you explicitly ask for it. If a component doesn’t need to be interactive, it stays server-rendered and never becomes client-side JS. That has real consequences: Faster page loads
Less work for the browser
Better performance on low-end devices
Cleaner output for search engines to crawl Faster page loads Less work for the browser Better performance on low-end devices Cleaner output for search engines to crawl Search engines still understand JavaScript, but plain HTML is always the safest and fastest path. Astro leans into that. For a portfolio and blog, that’s exactly what I want. Better performance doesn’t magically guarantee better SEO, but it removes a whole class of problems. Faster pages, cleaner markup, fewer hydration issues. All good things. I still like Next.js. Just not for this job. This part matters, because this isn’t a framework war post. I still like Next.js. I use it at work. I’d happily use it again for apps that actually need it. The ecosystem is strong, the team is solid, and React is still my default for interactive products. But my portfolio isn’t that. For this site, Next.js felt like bringing a full workshop to hang a picture frame. Liking a tool doesn’t mean using it everywhere. Version drift slowly killed my motivation One thing that really pushed me away was version drift. I started this portfolio on Next.js years ago. It lived through major changes. I was running something around Next 13, while the world moved on to 16. Every time I thought about adding a new feature, I first had to think about upgrading, migrations, and whether something subtle would break. That friction adds up. Especially for a personal project. I loved the UI. I still do. It was clean, polished, very “me” at the time. But maintaining it started to feel like a chore instead of a creative outlet. I chose simple on purpose this time When I rewrote the site, I tried a lot of UI ideas. I scratched my head more than I’d like to admit. And then I stopped. I decided to keep it simple. Maybe too simple. But simple enough that it gets out of my way. The point of a portfolio is to deliver information. Show what I’ve built. Share how I think. It shouldn’t be ugly, but it also shouldn’t require five sprints to add a new section. Beauty is subjective anyway. The most important thing is that I like it. And I do. The simplicity lets me focus on other projects instead of endlessly polishing my own homepage. Ditching Hashnode was part of the same mindset At the same time, I stopped using Hashnode as my primary blog. I like Hashnode. I respect what they’re doing. But writing there started to feel heavier than writing should be. There were network API calls for things that shouldn’t need them. Getting the latest article sometimes meant wrestling with APIs. The move from REST to GraphQL was conceptually nice, but in practice, it still felt like too much work for something simple. And yes, I hit the “sorry, your draft was not saved” error more times than I’d like. Now, I just create an .mdx file and start writing. Like this article. .mdx MDX and frontmatter changed how I write With Astro, my blog lives in the repo. Each article is an MDX file with frontmatter. Title, date, description, tags. All local. All versioned. Always up to date. No HTTP requests. No syncing issues. No editor crashes. MDX gives me the flexibility to drop in components when I need them, but most of the time I’m just writing markdown. That’s a good thing. It keeps the focus on content instead of tooling. One-time setup. After that, it just works. Everything is fast now. Almost suspiciously fast. The site feels instant. Page loads are snappy. Navigation is boringly fast. Sometimes it’s so fast it almost feels wrong, like something must be broken. But it isn’t. This is what happens when you stop shipping unnecessary JavaScript and let the browser do less work. I’m not abandoning platforms. I’m choosing ownership. I’ll still post articles on Hashnode, dev.to, Hackernoon, and similar platforms. They’re great for distribution and discovery. But my portfolio blog lives with Astro. MDX and frontmatter are staying. It’s simpler. It’s faster. And it feels like something I can maintain for years without fighting it. Final thoughts This wasn’t about chasing the newest thing. It was about matching the tool to the job. Astro isn’t perfect. Next.js isn’t bad. They solve different problems. For my portfolio, Astro gave me focus, speed, and long-term peace of mind. That’s worth more than any fancy setup or clever abstraction. For now, I’m happy here. And that’s enough.

This story contains new, firsthand information uncovered by the writer.

Figma

How Astro Made My Portfolio 82% Faster to Build

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Debunking the Myth That You Need a College Degree to Work in IT

Adding a Headless CMS to Astro in 3 Steps

An Intro to the Astro Framework: Benefits and Drawbacks

Creating an Astro Site: Add Lucide Icons to Astro

How to Building Fancy List Items in Astro

Implementing Dynamic Tags in Astro

Debunking the Myth That You Need a College Degree to Work in IT

Adding a Headless CMS to Astro in 3 Steps

An Intro to the Astro Framework: Benefits and Drawbacks

Creating an Astro Site: Add Lucide Icons to Astro

How to Building Fancy List Items in Astro

Implementing Dynamic Tags in Astro

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps