Why I Moved My Portfolio to Astro: Engineering for Performance

For years, my personal site was a React Single Page Application (SPA). It was sleek, it had state-of-the-art transitions, and it was built with the same tools I use to build enterprise grade SaaS platforms. But for a professional portfolio and a boutique agency site, it was the wrong tool for the job.

I recently rebuilt everything using Astro. Here is the technical “why” behind that decision and how it reflects my philosophy on modern web engineering.

The Single Page Application Trap

React is incredible for building complex, state-heavy dashboards (like the recruitment marketing tools I build). However, for a content-driven portfolio, an SPA introduces unnecessary overhead:

The “JS Bloat” Problem: To show a simple paragraph of text, a React SPA forces the browser to download a large JavaScript bundle, parse it, and then execute it to “hydrate” the page. On a mobile device with a 4G connection, this leads to a “Poor” performance rating.

SEO Challenges: While Google is better at crawling JS now than it was five years ago, static content is still king. A site that exists as raw HTML from the moment it hits the server will always win the indexing game.

Over-Engineering: A portfolio is essentially a collection of documents (Case Studies) and a contact form. Using a massive client-side framework to render static text is like using a sledgehammer to crack a nut.

Why Astro? (The Islands Architecture)

Astro’s Islands Architecture was the primary draw. It allows me to ship zero client-side JavaScript by default.

If a component doesn’t need interactivity—like a project description or a blog post—it’s rendered as pure HTML at build time. If I need a complex, interactive element (like a filterable project gallery), I can drop in a “React Island” that only hydrates that specific part of the page. This “opt-in” interactivity is the gold standard for performance.

The Beauty of Flat-File Content (No Database Required)

One of the biggest wins in this migration was moving away from the need for a backend database or a heavy Headless CMS just to store a few dozen blog posts and case studies.

Git-Centric Workflow: My content now lives as Markdown files directly in my repository. There is no database to maintain, no SQL injections to worry about, and no “connection string” errors.

Version Controlled Content: Every edit to a project or blog post is tracked via Git. I can branch, pull request, and roll back content changes with the same precision I use for my source code.

Type-Safe Collections: Using Astro’s Content Collections, I get full TypeScript support for my Markdown frontmatter. If I forget to add a “publish date” or a “client name” to a new project file, the build fails locally before it ever hits production.

By removing the database layer, I’ve simplified the architecture, reduced hosting costs, and ensured that the site remains blazing fast and virtually unhackable.

Performance: The Bottom Line

Performance isn’t just a vanity metric; it’s a business requirement.

Moving to a static, content-driven architecture isn’t just about getting 100/100 on Google PageSpeed. It’s about reliability. It’s about ensuring that when a potential client or a recruiter clicks my link from a mobile device, the site is interactive in less than a second.

Choosing the Right Tool

The most important lesson from this move? Experience is knowing when to use less tech. I still love React and Laravel for the complex applications I build for my clients. But for my own brand, I want speed, accessibility, and a “brutalist” efficiency that only a static-first framework like Astro can provide.