We ship client work on both, including our own site (Astro). Here’s the decision as we actually make it.
What they optimize for
Astro optimizes for content sites. It renders to plain HTML at build time and ships zero JavaScript by default — you opt in per component. For a marketing site, that means the fastest possible pages with no discipline required.
Next.js optimizes for applications that also have marketing pages. You get React everywhere, one codebase for app and site, and a huge ecosystem — at the cost of shipping a framework runtime to visitors who came to read a page.
Where each wins
Choose Astro when the site is content-led (pages, case studies, a blog), SEO and Core Web Vitals are priorities, and interactivity is islands — a menu, a carousel, a form — not the whole page. Markdown content collections make a growing blog genuinely pleasant to maintain.
Choose Next.js when the marketing site shares components with a React product, you need server-side logic (auth, personalization, dashboards), or your team already lives in React and the consistency outweighs the extra kilobytes.
The performance gap, honestly
A well-built Next.js site passes Core Web Vitals. But “well-built” is doing heavy lifting — it takes deliberate effort to avoid hydration costs that Astro avoids by default. On identical designs we consistently see Astro ship a fraction of the JavaScript. Visitors feel it; so does the Chrome UX Report that feeds your rankings.
The boring answer
Both are excellent. The mistake isn’t picking the “wrong” one — it’s picking a full application framework for a five-page brochure, or hand-rolling a blog platform when content collections exist. Match the tool to the job’s actual shape.
We built US Construction on Next.js (client stack) and this site on Astro (content-led). Same studio, different jobs, different tools — that’s the point.