Astro or Next.js for a business website?
I build with both frameworks and the choice comes down to one question: is this still a website, or a tool people use? Here's the rule, what each vendor's documentation says about JavaScript, and what my own two sites send on first load.
I build with both, and the choice comes down to one question: is this still a website, or a tool people use? Astro suits a site that explains the business and brings in enquiries. Next.js suits a site that's turning into a product. I measured my own two sites on 25 October 2026 and again on 5 November, and the framework turned out to decide only part of what a page sends on first load.
The one question I ask first
Before I pick anything, I ask whether the site's main job is to explain the business and bring in enquiries, or whether we're building a tool that people use. Then I sort the project.
- A site that explains the business and brings in enquiries: Astro. For a service business that's most of it, which means a home page, pages for each service and area, case studies and articles, and a contact flow. Astro sends no JavaScript, the code that runs in the visitor's browser, by default. Where a particular function needs some, I add it.
- A website that's turning into a product, with user accounts, dashboards, personalised content, payments, complicated bookings, live data or permissions: Next.js. A form doesn't count, and neither does some animation or a content system, because Astro handles all of those. The line is when the complexity is persistent and connected, where users, data, rules and behaviour depend on each other.
- Something that isn't a custom website problem: neither. Someone says they need an AI platform and what they need is a booking flow, some CRM automation or a quick way to test an idea. I'd use the simplest thing that works reliably.
What I'd say to a client
You don't need to load an application before someone can understand what you do or get in touch.
When I say no to the build
The sort has one more outcome, which is no build at all. I'll turn down a project with no clear business outcome, nobody who owns the content and no plan for maintenance. You can make something technically impressive that turns into a very expensive abandoned project. The technology has to earn its place.
The same rule, in five minutes
I made a short video on this question. It covers the one question I ask first, when I pick Astro, Next.js or neither, and the tests on my own two sites.
The video uses figures from 20 October 2026, before I changed how the Astro site serves its images. Two of its claims no longer hold on the later figures, and the section called What this does and doesn't show says which.
What my own two sites send on first load
Both vendors' documentation points at less JavaScript in the browser. Astro's documentation lists "Zero JS, by default" as a feature. Next.js's documentation says layouts and pages are Server Components by default, which are parts of the page built on the server instead of in the visitor's browser, and it gives reducing the JavaScript sent to the browser as a reason to use them. I read both pages again on 5 November 2026. What a finished site sends depends on what gets added after that, which is why I measured.
Both sites are mine. Rod Fernandez Design is built on Next.js. Zeta Hybrid Tech, my experimental site, is built on Astro, and both are hosted on Netlify. I ran Google PageSpeed Insights on mobile on 25 October 2026 and again on 5 November 2026, each time in two sets of three runs, about three minutes apart within a set and about ten minutes between the sets, and I also ran desktop once on each day. Each figure is the median of three runs, which means the middle one when the three are put in order. The tests load a page once without scrolling, so they measure what comes down on first load. The Astro site changed between the two tests, and the next section covers how.
| Measure | Next.js - Rod Fernandez Design | Astro - Zeta Hybrid Tech |
|---|---|---|
| Mobile score out of 100, first set and second set, 25 October | 93 and 93 | 89 and 85 |
| Mobile score out of 100, first set and second set, 5 November | 95 and 96 | 91 and 95 |
| Desktop score, first set, 25 October and 5 November | 99 and 97 | 95 and 95 |
| JavaScript downloaded, mobile, 25 October and 5 November | 200 and 199 KiB | 52 and 53 KiB |
| Total page weight on first load, mobile, 25 October and 5 November | 472 and 473 KiB | 3,491 and 509 KiB |
| Of that, images, 25 October and 5 November | 80 and 80 KiB | 3,342 and 357 KiB |
| Largest Contentful Paint, mobile, first set, 25 October and 5 November | 2.6 s and 1.8 s | 2.9 s and 1.3 s |
Google PageSpeed Insights API, run from a server rather than my laptop, on 25 October and 5 November 2026. Each row was worked out on its own. The JavaScript, page weight and desktop rows are from the first set on each day, and the images row is from the second set, the only set that recorded images. Individual mobile scores on 5 November, first set: Next.js 98, 90, 95; Astro 92, 71, 91. Second set: Next.js 93, 96, 98; Astro 95, 79, 96. In the two Astro runs that scored 71 and 79 the page also made requests to other websites (in the second set, Google and Microsoft Clarity analytics), and JavaScript was 230 and 257 KiB; in the other four it was 53 KiB. Page weight was 509 KiB or less in those four and 687 and 713 KiB in the two. KiB is a kibibyte, about a thousand bytes. Largest Contentful Paint is how long the biggest thing on screen takes to appear.
How I read the numbers
On 25 October, read the JavaScript row alone and Astro sent about a quarter as many bytes: 52 KiB against 200 KiB. Read the weight row and it flipped. The Astro page was the heavier one by a long way, 3,491 KiB against 472 KiB, and images made up 3,342 KiB of it. That was the design: big images, and scroll animation.
The Astro site's 52 KiB was mostly one page script of about 46 KiB, which is the GSAP animation library with its scroll plugin plus the code that drives the animations. The rest was a small script of about 2 KiB and two analytics files of about 2 KiB each. I added the animation library and the analytics on purpose. That's what Astro's no-JavaScript default came to on that site. I haven't split the Next.js site's 200 KiB into what's React, the code library Next.js is built on, and what's my own code, so I can't say how much a different build would save.
Then I changed how the Astro site serves its images. On 1 and 2 November I made smaller copies for smaller screens, and set the images below the first screen to load as a visitor scrolls to them. On 5 November the same page fetched 3 images totalling 357 KiB, against 13 images and 3,342 KiB on 25 October, and the total came to 509 KiB. The test loads a page once without scrolling, so that's the cost of the first load, not of a whole visit. The JavaScript hadn't moved, at 53 KiB, and the Next.js site had barely changed, at 473 KiB. The first load lost about 2,980 KiB, and almost all of it was images.
So I wouldn't read this as Astro against Next.js. My position is that the framework sets what ships by default, and what you add after that sets the rest. A framework can't make big images disappear, and on this one pair of sites that was the difference between a heavy first load and a light one.
What this does and doesn't show
The scores moved too, and I can't say how much of that is the images, because other changes went in between the tests as well. The Astro site's mobile scores are the least steady figures here. On 25 October the second set scored 77, 85 and 93 on the same downloads each time. On 5 November four of the six Astro runs scored 91 to 96 with 53 KiB of JavaScript. The other two, 71 and 79, were runs where the page also made requests to other websites, which took the JavaScript to 230 and 257 KiB. That doesn't explain everything. On 25 October a run that also made outside requests, with 230 KiB of JavaScript, scored 89, above a run without them at 87, and the 77 had the same downloads as the 93. The Next.js site stayed between 90 and 98 in all six. PageSpeed Insights is a lab test, and as these runs show, the same page can score differently minutes apart. That's why I look at more than one run, along with what the page downloads and what a real visitor gets, and why I'm not chasing the smallest number at the expense of the design.
Two sites aren't a benchmark. They differ in what they say, what they're for and how they're designed, so this can't tell you which framework is faster, only what each of mine sent on two days. The video I made on the same question used figures from 20 October. Its mobile scores, Next.js 95 and Astro 89, match my first-set medians (Next.js on 5 November, Astro on 25 October). Two things it says no longer hold. It puts the Astro page at about three and a half megabytes, against under half a megabyte for the Next.js site, which was true on 25 October. On 5 November the two first loads were 509 KiB and 473 KiB, within about 40 KiB of each other. And it says the Next.js site stayed between 94 and 99, where my six runs on 5 November ran from 90 to 98. I'll run the same tests again around 25 November 2026 and show what moved.
What a request using GPTBot's name gets
On 25 October I fetched both home pages twice, once sending the name GPTBot, which OpenAI's documentation describes as the crawler used to collect content that may train its models, and once sending an ordinary browser's. I repeated it on 5 November. Both times both sites came back as full pages of HTML, which is a page's text and structure, with the text already in it. Counting every word left once the code and tags are stripped out, that's about 1,830 words for Rod Fernandez Design and about 1,455 for Zeta Hybrid Tech, identical either way and on both days.
The limit: I sent GPTBot's name from my own machine. That shows what each site hands to a request that says it's GPTBot. It doesn't show what OpenAI's crawler receives from its own network, and I haven't measured whether the framework changes how AI tools read a site. What I look for is whether the page arrives as content, or as an empty box waiting for JavaScript to fill it.
Where to start
If you're choosing for a project, write down what the site has to do now and in six months, then see which of the three groups above it falls into. The lightest reliable way to support both is usually the right build. If you're looking at a site you already have, open PageSpeed Insights on mobile and run it three times a few minutes apart, then compare the three scores. In Chrome's developer tools, the Network tab lists the size of each file a page downloads. How I build is on New Website Builds.
Pages worth acting on
What to read next
Why I don't start with WordPress (and where it's still the right call)
A first-person case for choosing the platform last, with the one comparison I've measured and five questions to ask before you agree to any platform.
Read articleAI Websites vs Normal Websites: What Actually Changes?
A practical guide to the difference between a normal business website and one that's built to support AI tools, automation, cleaner lead handling, and future search changes.
Read articleWebMCP: The Next Step in Building Websites for AI Agents
A plain-English look at WebMCP, the proposed standard that lets AI agents use websites instead of just reading them, and what it means for local businesses.
Read articleQuestions local business owners usually ask next
Want me to look at your site?
The Free Website Review looks at what's working, what's getting in the way and the clearest next step for your site, regardless of whether you hire me.