Best static site generator: Astro, Hugo, Eleventy or Next.js

A static site generator takes your content (usually Markdown), applies templates and produces a folder of HTML, CSS and JavaScript files ready to serve. There is no database or application server in the path of each visit, which makes the site fast, cheap and hard to take down. If the concept is new to you, start with what a static site is.

The usual question is which generator to use. Four names show up on almost every list: Astro, Hugo, Eleventy and Next.js. All four produce good sites, but they start from different philosophies, and the wrong choice shows up months later, when builds get slow or the site ships too much JavaScript.

Which criteria matter when choosing?#

1. How much JavaScript reaches the browser. A blog does not need a framework running on the client. Less JavaScript means faster loads, especially on phones.
2. Page count and build time. With dozens of pages, any generator works. With thousands, build time starts to matter every day.
3. Interactivity. A search box or a carousel is one thing; a dashboard with complex state is another.
4. Language and ecosystem. If you already use React, reusing components counts a lot. If you do not want to depend on Node.js, that rules options out too.
5. Odds of needing a server later. Login, personalized content or pages rendered on demand call for server rendering. The difference between the models is in SSR vs SSG vs static.

When is Astro the best choice?#

Astro is a framework for content sites. By default, pages are prerendered at build time as static HTML, and Astro strips out all client-side JavaScript automatically. When one part needs interactivity, you mark only that component with a directive such as client:load, client:idle or client:visible, and it becomes an "island" with its own JavaScript. Islands can be written in React, Preact, Svelte, Vue or SolidJS, even mixed on the same page. Astro requires a recent Node.js version; the minimum is in the installation docs.

An .astro page mixes a block of code that runs at build time with the output HTML:

---
const posts = [
  { slug: "hello-world", title: "Hello, world" },
  { slug: "second-post", title: "Second post" },
];
---

<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>My blog</title>
  </head>
  <body>
    <h1>My blog</h1>
    <ul>
      {posts.map((p) => <li><a href={`/blog/${p.slug}/`}>{p.title}</a></li>)}
    </ul>
  </body>
</html>

In a test, astro build turned this page into a dist/index.html with no <script> tag at all.

Pros: zero JavaScript by default, islands in the framework you prefer, content collections in Markdown and MDX, and the option to render pages on demand with an adapter if the site grows.

Cons: the ecosystem moves fast. Major versions tend to swap internal pieces, such as the Vite version, the compiler or the default Markdown processor, and remark and rehype plugins may start needing extra setup. Upgrading between major versions means reading the migration guide.

When is Hugo the best choice?#

Hugo is a generator written in Go, optimized for speed: according to its docs, it renders a complete site in seconds, often less. It ships as a ready-made executable and does not need Node.js.

hugo new project my-site
cd my-site
hugo server   # local server with live reload
hugo          # production build into public/

In recent versions the create command is hugo new project (older tutorials use hugo new site).

Pros: very fast builds even with thousands of pages, no node_modules, built-in taxonomies (tags, categories) and multilingual support, ready-made themes.

Cons: templates use Go's template syntax, which has its own learning curve if you come from JavaScript. Interactive components are up to you, in plain JavaScript. The LibSass embedded in the extended edition was deprecated in version 0.153.0, and Dart Sass is now the recommendation for Sass.

When is Eleventy the best choice?#

Eleventy (or 11ty) is a minimalist generator on Node.js. It transforms templates into pages and accepts many languages: HTML, Markdown, JavaScript, WebC, Nunjucks, Liquid, Handlebars, Pug and more. It runs on any recent Node.js version. It imposes no front-end framework or asset pipeline: the HTML you write is the HTML that comes out.

A minimal config using ES modules ("type": "module" in package.json):

// eleventy.config.js
export default function (eleventyConfig) {
  eleventyConfig.addPassthroughCopy("src/img"); // copy images as they are
}

export const config = {
  dir: { input: "src", output: "_site" },
};

With a src/index.md and npx @11ty/eleventy, the output goes to _site/. In a test, building one page took under half a second.

Pros: easy to understand, no client JavaScript unless you add it, flexible with templates, great for blogs and docs.

Cons: no ready-made interactive components and no image or CSS pipeline by default (there are official plugins for images). Large projects require you to organize the structure yourself.

When does Next.js make sense for a static site?#

Next.js is a full React framework with server rendering. It can also export a static site: with output: "export" in next.config, next build creates an out/ folder that any file server can serve.

// next.config.mjs
/** @type {import('next').NextConfig} */
const nextConfig = {
  output: "export",
  trailingSlash: true, // emits /about/index.html instead of /about.html
  images: { unoptimized: true }, // no Next.js server, so no on-demand image optimization
};

export default nextConfig;

The docs list what stops working in a static export: dynamic routes without generateStaticParams(), cookies, rewrites, redirects, headers, proxy, ISR, Server Actions, draft mode and image optimization with the default loader.

Pros: if your team already uses React and Next.js, you reuse components and know-how. You can start static and move to a server later without changing frameworks.

Cons: it loads the React runtime on every page. In a test, an export whose only page said "Hello" referenced more than 100 KB of compressed (gzip) JavaScript. For a blog, that is weight with no payoff. To host the server version, see how to host a Next.js app.

How do the four compare side by side?#

Which one should you pick for each scenario?#

When in doubt, Astro is the most versatile choice for a new content site. If the site is just text and you want the fewest moving parts, Eleventy. If page count is the problem, Hugo. Before deciding where to publish, compare how much static site hosting costs. And if your site turns into a SPA with client-side routes, watch out for the 404 on refresh error, which takes server configuration to fix.

How to do this on Square Cloud#

Square Cloud has a static sites runtime, plus Node.js and other language runtimes. You run the generator's build (Astro, Hugo, Eleventy or Next.js with export) and deploy the output folder by ZIP upload, CLI or GitHub. The platform has no build step: build on your machine or in an external CI such as GitHub Actions, and upload the result.

Every web app gets an HTTPS *.squareweb.app subdomain, and traffic goes through a global CDN, with automatic TLS and unlimited traffic (fair use policy). Custom domains start on the Standard plan: you create the DNS records at your registrar, and the domain stays registered in your name. Cookieless web analytics, collected on the server, comes with every plan and shows visits, routes, countries and status codes.

Plans are paid, starting at R$12.49 a month on Hobby, and a web app uses at least 512 MB of the plan's RAM pool. See website hosting.