The front page of JeremyMorgan.com loads less than a second, most of the time, from various parts of the world.
The website was fast before when it loaded in 3 seconds with the old design. Now it's even better, and I'll show you how I have it set up.
I chose to build this site with Hugo and host it on Netlify. In this article, I'll describe how I arrived at this decision.
The Old Site Setup
Sometime around 2011, I decided I wanted to move from Wordpress to a static site generator. My reasoning was simple: I write an article, publish it, and it doesn't get modified too much after that. Certainly not enough to justify being served from a database. So it made sense to have a system that would generate an HTML page for each article and serve it up statically.
I decided to go with Octopress, which at the time was a very popular wrapper for Jekyll and it served me well.
That move alone cut my load time down considerably. I then became mildly obsessed with page load speed and did many things to ensure it loaded quickly, including:
- Image optimization (Some of the Tools I used)
- Minification of CSS and JavaScript
- Using a CDN for certain assets
I was certainly happy with this setup. My workflow for many years was to create a new article, generate it on my laptop or desktop machine, and SCP the files up to a FreeBSD server running Nginx. It worked that way for a long time. Looking back, that was a crappy workflow, but I only wrote an article every couple of months, so it worked.
I spent a lot of years customizing my installation and contributing code and fixes to the Octopress project.
Problems Piled Up
As much as I loved Octopress at first, and I appreciate all the work from Brandon Mathis and others, Octopress started becoming a huge pain.
The biggest problem for me wasn't Octopress itself, but the Ruby dependency nightmare. I won't go into too much detail, but it became very hard to manage. Octopress required older gems to operate, so as Ruby and certain gems progressed forward, it became challenging to maintain a buildable Octopress installation.
I could no longer build from my laptop because of all the old software I'd have to maintain. I set up a Linux server with old software and used it to build. I then moved things to a container, so I could maintain the old versions of Ruby and those gems to produce the output. For instance, you can't run a version of Ruby newer than 1.9.3.
So I started researching solutions a couple of years ago but never got around to converting things. For a few years, this is what my workflow looked like:
It was ok, but the Achilles' heel in this operation was always the Octopress build, and I knew it. Maintaining all that old software for a simple build step was easy as long as I didn't touch anything.
Last month, my server failed. The server that was building the Octopress images. So I spun up another server, installed Docker and the container and it wouldn't work. I tried everything I could think of, and the fact was clear.
I could spend hours upon hours building another container with ancient software to make Octopress work, or I could spend that time changing to another CMS.
So I started seriously evaluating options for another static site generator.
Why I Chose Hugo
I spent a lot of time evaluating different options. I will go into more detail in a future article, but it came down to these:
These are all static site generators, and they could all solve my problems very well. I know Go, JavaScript, and Python, so I can modify things. This is just a plain blog that's a set of files in a structure. Any of these could work. But what were my requirements?
- Static file generator
- Must build fast
- Must be easy to customize
- Must be portable (Mac, OSX, Linux)
Now the last one might seem a little silly, but I never know what platform I'll be on when I'm writing. I might be on a Mac, Windows, or Linux, depending on what I'm writing about and where I'm taking screenshots. I want to build and view the page locally before pushing to dev, and eventually production. So this was important to me. But here's what I found after a lot of evaluation:
All of these static file generators met these needs.
So that made the choice difficult. I got a version of JeremyMorgan.com up and running with all three of these generators on all of the platforms no problem. I was able to customize things, and they all built pages quickly. But I had to choose one.
I ended up choosing Hugo out of fear of being caught in another dependency hell situation. Gatsby is cool and really powerful but seems overly complicated for what I'm doing. It also has a ton of dependencies within the JavaScript ecosystem, which is well known for making breaking changes at a whim.
Pelican is dependent on the Python ecosystem, which is much less flaky, so it was a close second place. Hugo, however, builds from an executable. So even if it gets abandoned or dependencies start to break, I can always just use the executable to generate the site until I find an alternative.
That's why I chose Hugo. It has a simple layer of protection against dependencies getting away from you. Not everyone cares about breaking changes and backward compatibility. Projects get abandoned, and that's part of the price you pay for open-source software. Hugo is portable, simple, and written in Golang, so I could just fork it or modify it if it gets abandoned. I've been pleased with my choice.
Why I Chose Netlify
The next question was where to host it. When my server crashed, I decided to take my static files and move them to an Amazon Lightsail setup. It was super easy and quick, but I knew that another hosted server wasn't going to be the best setup.
There are few reasons in 2020 to set up an entire Linux server to host a static website.
My requirements for a hosting setup:
- Must be fast
- Must be secure
- Must be something I can deploy easily
So I examined my options. Here's what I considered:
- Another Linux/FreeBSD server with Nginx
- Azure Windows VM with IIS
- AWS Amplify setup
- Netlify
I started putting together servers and doing tests. I found that hosted web servers simply could not keep up with the speed of AWS or Netlify, no matter how I optimized them. This is partially due to edge servers. I tested my speed from the following locations:
- Portland, OR
- Dulles, Virginia
- Orlando, Florida
- Dallas, Texas
- San Francisco, California
- Sao Paulo, Brazil
- London, UK
- Rose Hill, Mauritius
I did spot tests from all over the world, but these are the cities I focused on the most. I wanted to see what would be overall fastest out of all of them. I chose a page with lots of text and images on it. I was surprised at the results.
The hosted FreeBSD server and IIS server were fast, but not in the same league as Netlify and AWS once I left the United States. I want things to be fast for all of my website visitors not just the ones near me. That was a big consideration for me.
Netlify was the speed winner in almost every region.
After a long run of tests during all different parts of the day, Netlify came out as the winner. AWS Amplify was close. If I spent a ton of money on prime AWS assets, I'm sure I could beat the scores, but I don't make money off this website, so that's not an option.
So looking at my requirements, Netlify met them all.
- It's fast (the fastest)
- It's secure (from all the information I've found)
- Workflow is incredibly easy.
With Netlify, I connected my Github repo to it. I can commit to any branch to store changes. I can commit to a dev branch that I can push it to a preview. When I push to master, it's automatically published to JeremyMorgan.com.
Why Are Load Times so Fast?
Here's why this site loads so fast.
- It's a static site. Only HTML, JavaScript, and CSS
- It's not as cluttered as it used to be
- I'm using minimal CSS and elements
- Optimized JPEG images
- It's minified before publishing
- Netlify is really fast and serves it fast everywhere
So that's my secret sauce. The combination of these items means my site loads in under a second on the main page, and pages with heavy images and text come in around three seconds. Super fast.
My site loading quickly is important to me because of the purpose it serves. I provide tutorials and information about development, and I don't want people to have to wait to see it. I want it to be available in countries with poor internet access. Hugo and Netlify help me achieve that goal.
If you'd like to set something like this up and have questions feel free to contact me, and I'll share what I know.
I'm not done optimizing the speed of this site and I'll share more tips in the future!
Top comments (19)
This is an article about speeding up your static site build, not speeding up your page load.
If you are using netlify it doesn't matter how long your build is. Once the build is finished the server gets switched.
I think other static site hosters will have a similar setup.
Hugo is fast but you should be prepared to learn Go. If that is not something you want to do, stick with a static site generator in a language that you know.
I don't know Go, but I'm using Hugo for 1 year now...
Thank you for this beautiful and detailed write-up.
I checked a few pages of your website. You can further improve the speed by lazy loading the images.
Another area of improvement is making fewer HTTP requests. Like you can merge your main.css and syntax.css file, this way browser will have to fetch only one CSS file. You also load three separate JS files, which you can concatenate together into a single file.
Thanks! That's among my next steps. I am on the fence about lazy loading but I will be combining CSS and JS even further, as well as pushing some assets out to their own domain/CDN. Right now I'm very happy with Netlify's speed.
Please do write on it when you finish it. I picked some new tools from your post on image optimization, so I would love to pick new tips on combing CSS and JS.
I am curious. Is it necessary? Doesn't Netlify CDN handles all the assets?
Netlify supports HTTP/2, which eliminates the need to bundle your files to reduce requests.
I'd add a few items for your next comparison:
And some of those hosting include free simple statistics, that could replace Google Analytics, and thus remove the need for JS in your site, unless your pride requires to have Google Analytics numbers :)
Which one does provide free statistics?
Hexo is just a static site generator
Firebase has basic statistics
Github hosting don't provide any stats
And I don't know about Zeit
Thanks for providing that information. I recently purchased a dot com domain name but haven't done anything with it. I was thinking about moving my blogger page to it but am not sure how yet. Maybe I should just try to get it up and running first. First, I'll need to consider how (and who) to host it. I bought it on Dynadot because of the awesome price and was thinking about doing the blog first, then setting up my own email address on it. I don't really need the email, I just like the idea of having my own. Thanks again.
I chose same-ish tools:
My website loads in half a second (200ms for the DOM content) and the code is terribly unoptimized. In my experience, small filesizes and HTTP2 are the most important factors unless you're using rails, in which case you might as well give up.
I saw bug in your blog articles, there is a word blog in top. 😄
I don't know about how it works with Hugo, but in general zeit.co is also a great, free hosting choice!
Nice 😄 , Some questions:
You have hosted Hugo in Netlify, But Which CDN you have used ?
All this setup is free or you pay yearly price ?
Netlify is free. Hugo is also free of course. Netlify has their own CDN so you won't need another one.
Why Netlify and not Zeit?
I have never heard of Zeit and did not include it in my analysis. I will take a look at it in the future, however.
Thank you for sharing this useful information!
It took almost 4 seconds to load here (I am currently located in Israel).
Also, are you using SSR?
Thanks