Let’s be honest: you’re not here to watch your entire site rebuild from scratch every time you fix a typo. You want speed. You want to see your change, and only your change, reflected instantly. That’s the dream, and Hugo’s --navigateToChanged flag is the closest you’ll get to a direct portal to that dream. It’s not magic, but it’s such a clever piece of engineering that it feels like it.
Alright, let’s get our hands dirty. You’ve hit that point, haven’t you? The point where running hugo server feels less like a build step and more like you’ve just asked your laptop to calculate every prime number. A site with thousands of pages will do that. It’s not Hugo’s fault; it’s just math. But we’re not here to complain about math, we’re here to cheat at it. The core strategy is brutally simple: build less stuff. Hugo is wonderfully, blissfully literal. It will happily build every single page it can find, regardless of whether you need it right now. Your job is to tell it what to ignore.
Right, let’s talk about fetching stuff from the internet. You’ve probably got a Hugo site that pulls in data from some remote API, or maybe you’re building an image gallery from a CDN. It’s fantastic until you run hugo server and go make a coffee while it decides to re-fetch every single resource, every single time. This is the digital equivalent of your friend who tells the same long-winded story whenever you see them. We’re going to fix that.
Right, let’s talk about the file cache. This isn’t some magical, abstract layer; it’s literally a directory on your disk where Hugo stashes stuff it thinks it might need again. Its entire reason for being is to stop Hugo from doing the same expensive work over and over. Think of it less like a “cache” and more like Hugo’s workshop whiteboard—it’s covered in half-scribbled calculations so it doesn’t have to re-derive the Pythagorean theorem every time it needs to build a page.
Alright, let’s get down to brass tacks. If you’re building a site of any real size with Hugo, you’ve probably noticed your build times starting to creep up from a blink to a coffee break. You’re running hugo server and then changing a single Markdown file, only to watch Hugo thoughtfully re-render… well, everything. It’s polite, but it’s also absurdly inefficient. This is where partialCached comes in, and it is, without a shred of hyperbole, the single most effective tool in your arsenal for slamming the brakes on runaway build times. Forget magic tricks; this is simple, brutal, and effective engineering.
Right, let’s get our hands dirty. You’ve probably noticed Hugo is fast, but maybe your site has grown, and that initial speed has started to feel a bit… theoretical. Before you start randomly tweaking things in a panic, you need to know what’s actually slow. Throwing --templateMetrics and --templateMetricsHints at Hugo is like switching from a polite conversation about the weather to getting a full diagnostic readout from a jet engine. It’s brutally honest, occasionally terrifying, and exactly what you need.
Right, let’s get into the good stuff. You’ve probably heard that Hugo is “blazingly fast.” It’s not just marketing fluff; it’s the architectural hill the framework’s designers decided to die on, and frankly, I respect the commitment. While other generators are busy waiting for a database or re-compiling the same JavaScript for the tenth time, Hugo has already finished building your entire site and is now just sitting there, smugly, wondering what to do with all its free time. The secret sauce is a ruthless, almost obsessive, focus on two things: doing as much work as possible in parallel and keeping everything it possibly can in memory.