Why is Speed Important

Rolling Around at the Speed of Light

Hugo is “The world’s fastest framework for building websites," and by that I think they mean that it’s quick to compile, and it’s true. Hugo is quick as heck - I’ve never seen a faster system.

So what?

The build time is not the bottleneck, right? I mean, I spend at least 10 times the time writing code, so what does it matter if my build times are a little long?

The reality is a fast build time is invaluable.

Many web developers are used to being able to make a change, wait a few seconds, and see what the final implementation will look like. When I started working in this industry, this wasn’t always the case, especially if you were working on the backend. But, now with the adoption of CI/CD tools and the constant speed improvements implied by Moore’s Law (which is kinda still holding?), we’re living in a time that’s faster than ever.

The ‘Problem’ of Slowness

Back in the day, I had a workstation computer with 16GB RAM and dual screens, and that was pretty strong (heck it’s still pretty strong today). We were building a .NET storefront with a javascript front end. I don’t even think we had any major build steps besides the backend server, which is primarily where I was working. I remember when build time came around I could get up from my desk, pour some coffee, and walk back and I would still have about 20 seconds of build time. You’d do this at the start of the day too - and if you didn’t have keys you’d have to wait for the guy who did to open up the building, and you still had a 10 minute spin-up time on your machine before you could do anything new.

This was the standard - and it’s still the standard in a lot of places. If you’ve got a long build pipeline, whether because you’re working on code that needs those types of builds, or because your code is a mess, then you’re constrained in this way. The cost is… well it’s not easy to measure. Personally, I like having distinct breaks during the day. In these kinds of constrained workflows, I usually don’t build more than every half-hour. But this can be a problem…

Going fast feels good

I love bashing out code, trying things out and messing with what I can see. When I started working with Angular, I thought it was something of a miracle that you could iterate so fast. Little did I know that most of the high-end development shops were already operating like this.

To be fair, on my old projects the .NET didn’t need to recompile if you were only working on front-end stuff; and working on that was fast! But working backend stuff… that kinda sucked in comparison.

Nothing beats saving your changes and knowing in moments whether or not you’d ruined the entire build. I’m not sure if the other tools that help me go fast also got quicker (I feel like the answer is yes!) but unit testing, snapshot testing, and regression testing was a thing you used to do at the end because that took even longer than just building the actual project. On lots of my current projects, I couldn’t imagine not running my unit test suite with watch flags enabled, auto-updating my snapshots on commit, and linting after saving my files. It used to bog down my system before, but now it’s obvious - I need this, and it keeps you faster (and cleaner).

Is Speed the most important?

If you’re building a project and you get to pick the stack, speed is important, but it’s also important to know what kind of speed is important. For me on the Yockyard, the end-user’s speed is the most important in two ways:

1. I’m a customer for my own system - if I think it’s too much of a pain to add new sites and it’s too slow, then I want to write less and less. That’s not great. I’ve read over and over again that users on Jekyll are always afraid of the build, and it’s the most common complaint of the system. For me, Hugo’s been pretty great, and wicked quick.
2. Hugo doesn’t put a bunch of stuff into my website that I don’t want. It’s barebones and it’s intricate to set up, but once it’s going it runs itself and it does it well. I’ve worked with Gatsby and React, and one thing that’s always in the back of my mind is that they could be slowing down because of React and its relative weight.

React is great, and it’s a huge benefit to the web development community. But React can be slow and it can easily become a UX bottleneck, especially if I’ve coded something carelessly. Additionally I know I tend to code carelessly.

Time is Money

Build times on local don’t cost as much as the developer pushing the buttons. But what does cost you money is time on that build server. Every second that your build takes to complete is directly transferable to a dollar amount.

So by the simple economic principle of “pay less money for the same thing,” your build process should be as fast as possible.

Beyond the basics of speeding up your build on someone else’s computer, there’s no cost for having a more agile and quicker build. For all the supposed benefits of break time and splitting up your work into intervals, it really doesn’t add up to much when you can do all of that and have a faster build. There’s nothing stopping you from taking breaks, segmenting your work, and taking a walk every once in a while. Really, you can just do those things without waiting for a build to finish.

So with that in mind, if you can reduce your build times there is no reason not to. The flip-side of this is that build times usually don’t contribute to your primary goals directly: you’re usually not making tools, websites, or really anything with the explicit goal of “it’s gotta build fast,” - well unless you’re Hugo! - your goals are usually things like “sell more Foo,” or “automate Baz.” Simple stuff like that, it’s not “get an artifact published to prod within Y minutes of commiting.”

So Speed is the Best?

Speed is important, but it’s usually not the most important thing. “Time is Money” and all, but if your operational objectives don’t align with the reality of a fast build or if you are constrained by tools that mandate slowing down your build, then the truth of the matter is you’re going to have slow build times. This is the reality we live in: sometimes you can’t have the best or the most streamlined process. Instead you need to work with the resources and means provided, but hopefully you’ll work to get those build times down anyway.

Slow build times aren’t the end of the world but if any part of this sticks with you, it should be that a fast build is a good build.