Hugo: Static Site Generator, Editions and Build Speed

What is Hugo?

Hugo is an open-source static site generator written in Go. It reads Markdown content, templates and a configuration file, and writes a folder of plain HTML, CSS and JavaScript that any web server or CDN can serve. It ships as one executable, and its own site says it renders a large site in seconds, often less.

Hugo belongs to the static site generation family: pages are built once, ahead of time, instead of on every request. That puts it next to Astro in the Jamstack toolbox, with a different trade-off: Hugo uses Go templates and no JavaScript runtime, while Astro uses a JavaScript component model.

How a Hugo site works

A project is a folder with a few conventional directories (per the Hugo docs):

my-site/
  archetypes/   templates for new content
  assets/       CSS, Sass, JS and images for the asset pipeline
  content/      Markdown pages
  data/         JSON, TOML, YAML or XML data files
  i18n/         translation tables
  layouts/      templates
  static/       copied as-is to public/
  themes/       optional themes
  hugo.toml     site configuration
  public/       generated site (created by the build)

You write a page as Markdown with front matter at the top:

+++
title = 'My first post'
date = 2026-10-23
draft = false
+++

Hello, **Hugo**. This Markdown becomes an HTML page at build time.

A template in layouts/ wraps that content in your site's HTML. Two commands cover most of the daily work:

hugo server -D    # local dev server, includes drafts
hugo --minify     # build the site into public/

New content created with hugo new content starts as a draft, so it stays out of a normal build until you set draft = false. Hugo also handles multilingual sites, taxonomies such as tags, shortcodes, several output formats (HTML plus RSS or JSON) and image processing such as resizing and cropping.

Standard, extended and deploy editions

Hugo is released in editions. The standard edition covers the core. The extended edition adds LibSass support for Sass (the Hugo docs mark LibSass as deprecated and recommend Dart Sass, which works with any edition). The deploy edition adds direct upload to an AWS S3 bucket, Google Cloud Storage or Azure Storage, and extended/deploy has both. The docs recommend the standard edition unless you need the extras. You only need Go installed to build Hugo from source or to use Hugo Modules. The install guide lists every platform.

Is Hugo really fast?

Build speed is Hugo's main selling point, but treat the numbers you see online with care. Hugo's documentation describes its speed in qualitative terms and publishes no benchmark, and your build time depends on page count, template complexity, image processing and the machine. Measure your own build before you compare generators. And a fast build does not make a fast site: visitors only feel what you ship, which is HTML, CSS, JavaScript and images.

Example: a documentation site

A team keeps 300 Markdown pages in Git. Every push triggers a CI job that runs hugo --minify and uploads public/ to a static host in front of a CDN. Hugo's host and deploy guide lists AWS Amplify, Azure Static Web Apps, Cloudflare, Firebase, GitHub Pages, GitLab Pages, Netlify, Render, Vercel, and plain rsync or FTP among the options. There is no application server to patch or scale.

Common mistakes

• Floating theme versions. A theme update can change your layout. Pin the theme commit or module version.
• Forgetting drafts. A page missing from the live site is usually still draft = true.
• Using extended-only features on the standard binary. Check which edition your CI installs, not only your laptop.
• Expecting runtime behaviour. Hugo has no server runtime. Forms, search and comments need a third-party service or a serverless function, and for per-request rendering you want server-side rendering instead.
• Skipping the image cache in CI. Processed images are cached in the resources directory. Persist it between builds or CI redoes the work every time.
• Stale content. Data is frozen at build time, so a headless CMS needs a webhook that triggers a rebuild.

Hugo, performance testing and monitoring

Static output removes the application server from the request path, but the page can still be slow because of heavy images, third-party scripts or a poorly configured cache. After each deploy, run a Lighthouse audit and track the Core Web Vitals. LoadFocus Page Speed Monitoring runs scheduled Lighthouse audits from 25 cloud regions and alerts you when a metric regresses. For the setup, see how to monitor Core Web Vitals with alerts and reports, and for the fixes, 10 ways to improve your website speed.

FAQ: Hugo

Is Hugo free?

Yes. Hugo is open source, and you only pay for wherever you host the generated files.

Do I need to know Go to use Hugo?

You do not need to install or write Go to build a site. You do need to learn Hugo's Go template syntax to write layouts, which is the steepest part of the learning curve. Themes let you start without writing templates.

Should I use the standard or the extended edition?

Start with the standard edition. Switch to extended only if a theme or your asset pipeline needs it, for example LibSass, and prefer Dart Sass for new Sass work.

Can Hugo do server-side rendering?

No. Hugo generates files at build time. For dynamic pages, add client-side JavaScript or serverless functions, or choose a framework that renders on the server.

Where can I host a Hugo site?

Anywhere that serves static files: Cloudflare, Netlify, GitHub Pages, GitLab Pages, Vercel, AWS Amplify or your own S3 bucket and CDN, among others.

Does Hugo support multiple languages?

Yes. Hugo has built-in multilingual support, with translated content and translation tables in the i18n directory.