I’ve maintained a website for nearly fifteen years. These sites started as slow WordPress blogs on shared servers and progressed over the years to managed solutions like Squarespace. I don’t update my site often and never loved the idea of paying for dynamic websites that relied on relational databases to serve something that receives as little traffic and changes as infrequently as my personal site.
I briefly experimented with a simple static HTML site but found the site didn’t perform as well due to the lack of image optimization and dynamic loading. As I’m not a web developer by trade, my designs always suffered from optimization and performance limitations. So I hosted the site on GitHub Pages and felt that performance withstanding, the static site was the best solution for my purposes.
I’ve landed on Gatsby as my preferred static site-generating engine for this site and my other personal site. Gatsby and others like it create sites optimized for speed, backed by GraphQL to load the static content dynamically. This creates a blazing fast website that costs nearly nothing to maintain. The communities that have emerged around these frameworks have also provided a way to learn and a quick on-ramp through templates designed by professionals.
While experimenting with a few different static site generators, I’ve observed several genuine advantages to running a static site for personal use.
- Cost: Static site generates shift the computational requirements of running a site from the servers that host the content to a build pipeline. Rather than requiring each request to a website to run a series of database queries to build a page for each request dynamically, static sites create all pages when a change occurs to the content and distribute the static version of these pages to a storage service, such as Amazon S3, that can host the content. As websites are generally small, and object storage services capable of hosting are relatively inexpensive ($0.023/GB), maintaining a website can be nearly free.
- Performance: Removing those database transactions also improves performance. A WordPress site that you host yourself will dynamically generate each page when a user navigates to it. This dynamic page generation is wasteful for most websites that don’t often change or require customization based on the user. This waste comes in the form of running a server required to perform the dynamic operations and the time it takes to serve the content to the end-user. Static site generators create assets that are happily distributed to Content Delivery Networks (CDNs) to accelerate site loading times. The difference for users is truly staggering.
- Maintenance: Servers require maintenance, including patching, tuning, and configuration. If you’re only posting a few times a year, logging in to patch and maintain each month can be a real burden. You’ll also have to back up your servers regularly to protect against disruption. It’s not just the servers, either. If you’re running in the cloud, you’ll likely need to configure the network and the firewall as well. There’s no server to patch with static sites as the files are hosted and served through completely managed services.
- Security: Servers require patches, and when you neglect to patch, you run the risk of a malicious party taking over your site. Couple this with attack vectors that exist through the Content Management System, such as WordPress and its plugins, and the network hardening required to run a public website yourself, and the time commitment begins to stack up. You can, of course, opt for a fully managed hosting service for a fee. Static sites don’t have any entry points for a malicious party to exploit. The underlying managed service is ultimately responsible for securing the infrastructure.
- Portability: Moving a server is a lot of work. Believe me; it’s what I do for a living. You can’t simply download a server and move it to a new cloud provider to get a better price or improved performance. Instead, you can quickly deploy the static assets to new services with few configuration changes required with static sites. Build services read universal config files to get started quickly. Static sites provide the ultimate cloud-agnostic, portable solution.
How to Get Started
As you can probably tell, I’m passionate about this shift to static sites. I’ve experienced performance improvements while seeing my operation and maintenance costs plummet. Coupled with new frameworks that optimize the static assets for hyper-fast distribution and an ecosystem of build pipelines, there’s never been a better time to get started. Here’s what I’d recommend.
- Choose a Framework: There are a ton of frameworks out there, with more popping up every day. For a directory to help get you started, check out Jamstack. I’d recommend starting by selecting a templating language you’re familiar with or aspire to understand better. Then, if you want to get started quickly, take a look at the available community-developed templates for each framework as well.
- Create a Repository: Log into GitHub or BitBucket and create a git repository to store the source code for your site. The repository will host the site’s source code, ready for processing and distribution. The repo will also automatically trigger a build when new code is committed. You can connect this repo to an iPad or multiple laptops to make deploying from anywhere easy. A centralized repo also makes collaboration possible.
- Select a Build Environment: There are a few different ways to build your static site. First, you can choose to run the build entirely offline, using the framework’s CLI to generate the static assets. While this is one approach, it requires that you always deploy from the same computer/laptop. Therefore, I prefer one of the many cloud-hosted code deployment services, such as Netlify, AWS Amplify, or Vercel. You can also find build environments specific to the framework selected, such as Gatsby Cloud. These services let you build and run your site and are also free for smaller sites such as this one.
- Deploy and Host: Many build environments, such as Netlify, can handle the site's hosting along with the build. However, if you’d prefer to build locally or choose an agnostic build pipeline such as Jenkins, you may need to select and configure a place to host your site. Most of the major cloud providers, including AWS, have static website hosting (on AWS, through Amazon S3) and Content Delivery Networks.
- Connect Your Domain: Finally, you’ll want to make the site your own. Purchase a domain and point it to your hosting provider. If you choose to host through AWS Amplify or Netlify, you can even deploy an SSL certificate for free.
And with that, you’re up and running. There’s a bit of work to get it going, but once configured, your static site will live on with little required maintenance from you. When you want to update the site, update the source code, run the framework’s CLI to test the changes, and push the new code to your repo. The build pipeline will take it from there.
In closing, static sites provide a relatively inexpensive and performant option for most personal sites with infrequent updates. These sites are happy to run for years with little maintenance, and the portability provides an easy option for moving if prices change. Finally, the lack of a server to secure reduces the attack vector, preventing your personal brand from being dragged through the mud by some script kiddy. In my limited time running static sites on serverless infrastructure, I’ve been blown away by the performance and have had a blast learning this new generation of frameworks and tools.