I am still an ardent supporter of WordPress, but I have never been one of those developers who tries to use one tool—or application, in this case—for every job. I like to explore new options, learn new programming languages, and experiment with new applications. In my experience, when it comes to software, there is often something better down the line.
A few years ago, when I was already years-deep into building dynamic web sites, I read about the resurgence of static web sites, and I ran across Hugo in its early stages of development. I was impressed then, but there were still some issues that Hugo’s developers hadn’t yet resolved. I’ve been keeping an eye on Hugo’s progress ever since. The issues that originally made me decide to wait to try Hugo are now resolved.
Recently, when I was addressing some hacking attempts on the WordPress sites I manage, I realized that I’m the only person that works on several of them. A few of them have relatively rare content changes, and some of them have had none since I built them. They’re informational sites only; they don’t need a database backend, and WordPress is really overkill for them. Why not convert them to static sites?
Now seemed like the perfect time to take the Hugo plunge.
I have several sites that meet my criteria for becoming static websites:
- I am the only contributor of content, or the only one who posts new content for the site.
- The sites do not require e-commerce solutions. (However, I do have a client site that’s using WordPress for e-commerce without an e-commerce plugin that I may convert to Hugo down the line.)
- The sites do not require any dynamic, database-driven pages. (Hugo can generate pages from data, but not dynamically on a site.)
Those aren’t hard-and-fast criteria. Now that I’ve experimented with Hugo, I can think of ways to integrate dynamic, database-driven pages into a Hugo-generated site, but for now, I’m still getting used to Hugo.
So, before I touched a client’s site, I decided to convert my own WordPress site—this site—to Hugo.
Running WordPress, my site took up 72 MB of disk space.
After conversion to Hugo and the removal of all the WordPress files, it’s taking 8.1 MB.
I tested the same article in GTmetrix with the site running WordPress and then with my Hugo-generated static site.
With WordPress, using WP Super Cache and Autoptimize, the page loaded for GTmetrix in 1.8 seconds, with a total page size of 765 KB and 16 requests.
Hugo loaded the page in 1.2 seconds, with a total page size of 46.9 KB and seven requests.
I was expecting a bigger difference in loading speed with Hugo than 0.6 seconds, but that is a 33% improvement.
While the page load speed isn’t thrilling with the switch to Hugo, I’m way ahead in terms of security. With Hugo, there is no interface for hackers to brute-force. There is no database to gain access to.
I’ll update Hugo on my computer, but it’s in the repositories for the Linux distribution I use, so that’s automatic. I no longer have to do WordPress updates, test the plugins I was using in WordPress when they’re updated, or worry about my site crashing when there’s a major update to WordPress' core.
What About Adding Content with Hugo?
Adding content to Hugo is simple and straightforward now that I have just a little experience with the platform. I actually find it easier and faster than WordPress' Visual Editor. I don’t think it will be as easy for my average client: see my first criterion for becoming a static site above.
The Pros of Deploying a Hugo Site
The list of pros is too long to list here, but a few that really stood out for me are:
- Hugo comes with its own server, so building and testing a site can be done locally without the need to build a LAMP or WAMP server for local development.
- Hugo is lightweight and fast! The server rebuilds my site in milliseconds every time I save a file so I can review my changes in real-time.
- It’s possible to bundle asset files of the same MIME type into one resource.
- No caching plugin is necessary for Hugo; the files are statically generated and uploaded to the web host. Caching is unnecessary.
- I can deploy my Hugo-generated site to my hosting account using a simple rsync command. Basically, it’s just a matter of uploading files.
- The Hugo Community is active and very responsive. I got stuck once with an overlapping issue regarding a code issue in a theme I was testing and my own ignorance of the Go language I was using to customize my site. I got a helpful response within minutes of posting and was able to resolve the problem I was having.
The Bottom Line
I am very pleased with my Hugo experience. If you’re considering taking the Hugo plunge, I encourage you to give it a shot. Since you can build and test a site locally using Hugo’s built-in server, there’s really no reason not to.