Next.js vs Astro vs HTML for a Small Website
An honest comparison of Next.js, Astro and plain HTML for a small site, covering setup, speed, editing and hosting, plus a table to help you choose.
· 8 min read
For a small website of five to fifteen pages, all three choices give you a fast site that costs nothing to host. Plain HTML wins when you want no tools and few moving parts. Astro wins when you want reusable components and a blog but still want pages that ship almost no JavaScript. Next.js wins when you already know React or the site is likely to turn into an app with logins, a database or server code. If someone who doesn't code will update the site, consider a fourth option: WordPress.
The rest of this article explains the trade-offs so you can choose with confidence instead of picking whatever is popular this year.
What each option actually is#
Plain HTML is a folder of .html files, a stylesheet and perhaps a small script. The browser reads exactly what you wrote. There is no build step unless you use a CSS tool such as Tailwind, and even then you only rebuild the CSS.
Astro is a static site builder. You write pages as .astro components (HTML with a small block of JavaScript or TypeScript at the top for data), and astro build turns them into plain HTML files. Interactive bits run as small scripts, and you can add React, Vue or Svelte "islands" only where you need them.
Next.js is a React framework. Pages are React components. It can render pages on a server, at build time or both. With output: "export" in next.config.ts, next build writes a fully static site to out/, which is how small brochure sites usually run.
All three can produce the same visible website. At Freeframe every template comes in all three versions (plus WordPress), with the same pages and design, so the choice is about how you work rather than how the site looks.
Setup: how long until you're editing#
HTML: unzip, double-click index.html, edit in any text editor. Nothing to install. If you change the design tokens in a Tailwind template you need Node.js to rebuild the CSS, but text and image changes need nothing.
Astro: install Node.js, then:
pnpm install
pnpm dev # http://localhost:4321Next.js: the same tools:
pnpm install
pnpm dev # http://localhost:3000Both frameworks take a minute or two the first time while dependencies download. After that, the dev server reloads the page as you save. The real setup cost isn't the install; it's that you now own a package.json full of dependencies that will need updating.
Performance: what visitors download#
All three are served as static files from a CDN, so time to first byte is similar. The difference is JavaScript.
- Plain HTML sends only the script you wrote. In the Freeframe HTML templates that's one small vanilla JavaScript file for menus, forms and dark mode.
- Astro sends no framework runtime by default. Its components render to HTML at build time, and only scripts you add (or islands you hydrate) reach the browser. A typical Astro page ships about as little JavaScript as hand-written HTML.
- Next.js sends the React runtime plus the code for each page, even in a static export, because pages hydrate in the browser. It also prefetches linked pages, which makes moving between pages feel instant once the first page has loaded.
For a brochure site, any of the three can pass Core Web Vitals comfortably. Large unoptimised images and third-party scripts (chat widgets, trackers, embedded maps) slow small sites down far more than the framework choice does. Fix those first, whichever stack you pick.
Editing: where the pain shows up#
This is where the options really differ.
Plain HTML repeats itself. There are no includes, so the header and footer are copied into every page. Adding a menu link means editing every file. A project-wide find and replace in your editor handles it in seconds, and for a site of ten pages that's genuinely fine. At fifty pages it becomes error-prone.
Astro and Next.js write things once. The header is one component. A list of services, team members or prices lives in a data file such as src/data/team.ts, and the page loops over it, so adding a person is one new entry. TypeScript tells you if you forgot a field.
Content and blogs: Astro is built for Markdown. Content collections turn a folder of .md or .mdx files into typed pages, which makes it the most natural choice for a site with a blog. Next.js can do the same with MDX or a few lines of code, but you assemble more of it yourself. In plain HTML, every blog post is a hand-made page.
Who can edit? None of these three suit a client who wants to log in and change text. They need a developer, a Git-based CMS added on top, or a different tool. That's the case for WordPress, covered below.
Hosting and running costs#
All three deploy to the same free static hosts: Netlify, Vercel, Cloudflare Pages or GitHub Pages.
| Stack | What you deploy | Build command |
|---|---|---|
| Plain HTML | The folder itself | None |
| Astro | dist/ |
pnpm build |
| Next.js (static export) | out/ |
pnpm build |
Plain HTML also works on old-fashioned shared hosting over FTP, and so does the built output of Astro or Next.js. The deploying guide has the settings for each host, and How to host a static website for free compares the free plans.
The difference appears when you want server features. Remove static export from Next.js and you can add Route Handlers, Server Actions and authentication, but you then need a host that runs Node.js. Astro can do the same with a server adapter. Plain HTML has no server side at all, so forms go to a service such as Formspree or Netlify Forms (see adding a contact form to a static website).
Maintenance: the cost nobody mentions#
A plain HTML site has no dependencies. You can leave it alone for five years and it will still work and still build, because there's nothing to build.
Astro and Next.js projects depend on dozens of npm packages. The site you deployed keeps working, because the output is static, but when you come back to make a change you may find a major version upgrade, a deprecated API or a security advisory waiting. Budget time for pnpm update and reading release notes once or twice a year, or pin your versions and accept that you're on an older release.
Next.js does more than Astro (server components, caching, routing, middleware), so its upgrade notes tend to be longer. For a static brochure site you use a small slice of it, but you still upgrade all of it.
When each one wins#
Choose plain HTML if#
- The site has up to around fifteen pages and the layout rarely changes.
- You, or the person maintaining it, want to edit files directly with no tools.
- You value never having to update dependencies.
- You're hosting on basic shared hosting.
Choose Astro if#
- You want components and data files but not React.
- The site has a blog, case studies or documentation written in Markdown.
- Shipping as little JavaScript as possible matters to you.
- You might add a React or Vue widget to one page later.
Choose Next.js if#
- You or your team already write React.
- The site will likely grow into something with accounts, a dashboard, payments or an API.
- You want to deploy to Vercel and use server features when you need them.
Choose WordPress if#
- A non-developer will update text, pages and posts after launch.
- You need plugins for forms, bookings, a shop or memberships without writing code.
- You're happy to pay for (and keep updating) PHP hosting.
See How to install a WordPress block theme for what that looks like in practice.
Decision table#
| Plain HTML | Astro | Next.js | |
|---|---|---|---|
| Tools to start editing | None | Node.js, pnpm or npm | Node.js, pnpm or npm |
| Learning curve | HTML and CSS | HTML plus a little TypeScript | React and TypeScript |
| Shared header and footer | Copied into each page | One component | One component |
| Repeated content (team, prices) | Edited in the markup | Data files | Data files |
| Markdown blog | Hand-made pages | Built in (content collections) | Possible with MDX or code |
| JavaScript sent to visitors | Only your script | Only interactive parts | React runtime plus page code |
| Static hosting | Yes | Yes (dist/) |
Yes with static export (out/) |
| Server features later | No, use services | With an adapter | Yes, without static export |
| Dependency updates | None | Periodic | Periodic, often larger |
| Best for | Small sites that rarely change | Content-led sites, blogs | Sites that may become apps |
A practical way to decide#
Ask three questions:
- Who edits the site after launch? If it's a non-developer, use WordPress. If it's you and you don't want tools, use HTML.
- Will it have a blog or lots of repeated content? If yes, Astro.
- Will it need logins, a database or an API within a year? If yes, Next.js.
If none of those apply, pick the one you already know. A finished site in a familiar stack beats a half-finished one in the "right" stack.
You can also start simple and move later. Because the Freeframe templates have the same design in every stack, you can launch the HTML version this week and switch to the Astro or Next.js version of the same template when the site outgrows it, without a redesign. Our choosing a stack page lists exactly what each version contains.
FAQ#
Is Astro faster than Next.js?#
For a static content site, Astro usually sends less JavaScript, because it doesn't ship a framework runtime unless you ask for one. Whether visitors notice depends on the page: images and third-party scripts often matter more. Measure your own pages with PageSpeed Insights rather than relying on general claims.
Is plain HTML bad for SEO?#
No. Search engines read HTML, and a static HTML page is the easiest thing for them to crawl. SEO depends on your content, titles, descriptions, links and speed, not on the tool that generated the markup. The SEO guide covers what to set.
Can I use Tailwind CSS with all three?#
Yes. Freeframe templates use Tailwind CSS v4 in every version. In HTML you rebuild the CSS with the Tailwind CLI; in Astro and Next.js the dev server does it for you. See How to customise a Tailwind CSS template.