What makes a fast website

As an addendum to my longer piece on how the Winterhead site was designed, this is a closer look at the problem of slow websites and some common methods to avoid these issues.

A slow website is bad for business

On average, websites are getting more bloated consistently over time. This bloat can be felt directly though slower loading times, since websites are getting larger more quickly than typical internet speeds are increasing. Mobile internet speeds also tend to be lower, and have higher latency and more variable quality (dependent on reception and network load), meaning that the web feels like a slower medium today than it did years ago. Much of this bloat is made up of images, but other common culprits are JavaScript resources, style sheets, and web fonts.

Approaches to making high performance sites

Part of the reason this site is so fast is that it is a static site generated with Jekyll. The exact same design would likely be perceptibly slower using a common content management platform such as WordPress or Squarespace. The reason for this is that the content of a website built with Jekyll can be served as static pre-generated HTML files.

A dynamic CMS (such as WordPress) deals with requests individually and builds the page when it is requested, which adds latency as well as a requirement that the web server can build pages dynamically with server-side scripting. Dynamically generating pages is a powerful feature and for some sites is essential, but it comes with a significantly more expensive and often slower server configuration requirement. Sidestepping this requirement by serving static HTML files instead (built ahead of time with Jekyll or another static site generator) is an economical option that works well for many smaller projects.

If you’re only going to the corner store, ride a bicycle.

Though the website is built with Jekyll, it could be easily implemented with another set of technologies, but a simple design often calls for the best performing and most economical solution. Static sites are a great choice for text-heavy sites – even image-accompanied text! For a site that relies on server-dependent interactive elements (like a shopping cart, for example), a dynamically generated site might be a more appropriate choice. In a sense, Jekyll or another static site generator isn’t a direct alternative to a dynamic site, but rather a radically different solution which could work depending on requirements.

I committed to a performance budget of 300 kB for a typical page, which is roughly one seventh that of a typical website. Many pages weigh in at only 100 kB, which is remarkably lean. The only exception is the map on the about page which pushes past 1 MB (1000 kB) because it features a Mapbox map (though the map element is out of the critical path so it does not slow down the initial page load). Modern websites are unbelievably bloated and I make sure that my projects are as lean as possible.

Other factors that contribute to fast loading pages:

  • Use SVG where possible for images: infinitely scalable images with smaller file sizes (often many times smaller than using other image formats).
  • Serve images and other resources using content delivery networks for lower latency and robust performance. In particular, I use CloudFront and imgix.
  • Avoid using too many web fonts: only four weights and styles are used for the typography of this site. At 25% to 75%, fonts make up the single largest of any given page’s weight for this site, far outweighing most other resources.
  • Keep requests and page sizes down. A typical page has only 100 KB total weight and 10 HTTP requests.