Static Pages for Performance and Accessibility

Your server is running. No problems - right?

Well, quite possibly, at least - you have monitoring in place to catch anything that happens. And nothing has happened yet. Or maybe something did once, but you fixed it quickly. The monitoring wasn’t functioning perfectly then, but now it’s better. The database is functioning as well, everything is nicely configured. It worked great the last time you tested it just a few days ago. Or was it over a week ago? Who remembers such things? Granted, you should update a bunch of programs and stuff, of course. But you don’t have time for that right now. It can wait until next week. No problem - right?

Granted, you have a lot of third-party JavaScript on the page for comments and interactivity and stuff. But they are probably running fine, you most likely have some uptime promise from them. And everyone must be complying with GDPR and all that; you noted that in the terms of service too. No problem - right?

Everything looked good when you tested the page at the office. And everyone else has good connections and the latest version of Chrome, at least almost everyone. Sometimes it takes a while for the comments to appear on the page, but that’s life. Plus, you have a tool that reports errors in client-side JS. That tool is super useful! It has indeed found many bugs, but most of them occur only a few days apart. It’s just a few users experiencing them. No problem - right?

Yes, maybe there are some problems now and then. But it doesn’t have to be that way. Imagine if your page could be available anytime, anywhere, always loading at lightning speed, and could be read by all browsers that exist and will exist? It can - if you make it a static HTML site.

What is a Static Page?

A static page is a page that has been pre-generated into a text file that browsers understand (complete HTML). No advanced server is needed, nor a database. All that’s required is to send the finished text file to the user. The text file can even be opened directly in your browser without a server; it’s somewhat like having a printed piece of paper of the finished web page: you can show it to anyone without any extra steps or tools.

Comparing this to a “dynamic” page that is generated by a server: every time a user wants to see a specific page, it is generated anew by the server. This also means that the underlying database must be queried (=read) with each page view, as the content itself is usually stored in a database. In the aforementioned analog terms: to show the web page, you need to open the site template, retrieve the content for that page, paste that into the template, and then print everything out. You have to do this every time someone wants to see your website. Compare this to doing the job once and printing a whole box of papers ready for distribution.

Dynamic elements can also be generated in the browser. For example, product reviews in e-commerce are often generated in the browser. Most of the time, there’s no reason to generate content dynamically in that manner, except that it might be an easier way to get content onto a site. This type of dynamic content is often even harder to manage in the long run and worse for the user experience than dynamic content generated by a server. A completely static page, of course, has all these elements pre-generated, and it’s usually simple to do this by fetching the content in advance, e.g., via APIs.

How Does Performance Improve with a Static Page?

The performance of a static page is virtually always better than that of a “dynamic” server-generated page. The main reason is that it requires far less work to get the page to the user. It is completely finished and only needs to be sent over the network. A simple web server that can do this, like NGINX, is definitely faster than an application server-database combo, such as Node and Postgres. (Note that the application server likely also has a so-called “reverse proxy” in front of it - i.e., in all probability just NGINX! :)

Another major reason that makes static pages faster is that the finished pages can reside virtually anywhere. It’s extremely simple to replicate a static page to different locations (to be physically close to users) - all that’s required is a copy-paste. Sure, you can replicate servers and databases as well, and you can have caching at various levels (like a CDN) even with a dynamic page. But both of these are incredibly difficult to get right. In contrast, there are many services that can take a static page and distribute it all over the world completely automatically.

When it comes to dynamic content generated in the browser, the difference is often even greater. The example with product reviews above, for instance, requires that code runs in the browser; reviews are fetched from third-party servers, and the result is generated into HTML code and displayed. Something that often takes seconds. Pay attention to this the next time you’re shopping online - how long does it take for the entire page to load? Does the content on the page jump around as more content shows up? We have grown used to this, but one might wonder why we accept it; because it doesn’t have to be like that.

How Does Accessibility Improve with a Static Page?

Since static pages have fewer moving parts (the architecture for the production environment is drastically simpler), the risk of bugs and other issues is also much lower. Faster pages with fewer connections to third parties are more accessible on older mobile phones and poorer internet connections. The best solution for everyone involved is the simplest possible solution (even Einstein would agree).

The accessibility of static pages is especially better when comparing them to pages that generate content in the browser. Since static pages are completely finished when they reach the user, screen readers and other tools can immediately understand the structure of the page. Additionally, users who cannot or do not want to enable JavaScript can read the entire page. A large part of client-side JavaScript is also optimized for (the latest version of) Google Chrome. This makes it not at all impossible for some functions that are only supported in Chrome to sneak into the code - which is bad news for those who cannot or do not wish to use that specific browser.

Start This Journey Now!

There are countless tools that can generate static pages. Personally, I like those that work with Markdown files, as they are extremely easy to work with. Most of the time, I have used Hugo, which I can warmly recommend.

Start by installing Hugo. Don’t worry, the program is also available as a standalone executable (.exe). Then create a new Hugo site in the static folder:

hugo new site static -f yml

(I personally find the YAML format for configuration easier to work with than the default TOML option, hence -f yml.)

Next, choose a theme (design) for your site at themes.gohugo.io. It’s easy to edit these or create a completely custom design, but for this example, a ready-made theme works just fine. I have chosen the “PaperMod” theme here. Go into the site’s folder and download the theme. (If you don’t have git installed, you can manually download the theme into the themes folder. See the instructions .)

cd static
git clone https://github.com/adityatelange/hugo-PaperMod themes/PaperMod --depth=1

Then modify the site’s configuration. Here, I select the theme we just downloaded and give a title to the site.

config.yml

theme: PaperMod
title: My Static Site

Now we come to the fun part - our first page! This will be the main page of the site. Write something nice and insert images if you want. (Note the _ in the file name; it’s important and necessary due to how Hugo works.)

content/_index.md

# Hello everyone!

This is my new static site - cool, isn’t it?!

Start Hugo with hugo server, and then check out your new site.

hugo server

That was easy! If you’re thinking this will be your blog site, create a new folder for the blog posts and an index page for them (note again the _ in the file name).

content/blog/_index.md

---
title: Blog
menu: main
---

Welcome to my blog!

Then write your first post. I’ve chosen a picture from New York as the cover image for the post. Download it, or any other image of your choice, to static/image.jpg if you also want a picture for your post.

content/blog/post.md

---
title: Static Sites are Cool
cover:
  image: image.jpg
---

I was going to write a blog post but didn’t get very far...

Surf around your new site and feel free to create more exciting content! When you finish, you can generate the entire site into the public folder with a command. This folder can be uploaded to any hosting provider. Alternatively, you can choose a service that automatically generates your site from your Git repository, such as statichost.eu.

hugo