How I Made this Website Hella Fast Without Overcomplicating Things

ben profile image Ben Halpern May 06, 2016

I hope your experience getting to this website was an expedited one and your browsing of it is swift.

When I set out to build this website, I knew I wanted to keep things light, maintainable and super duper fast. I do not care too much about complex UI behavior or ad delivery or implementing features quickly so it has been a great opportunity to be disciplined and deliberate.

Caching, gzipping, content delivery

This is a read-heavy content website, so whenever possible, pages are fully cached at the CDN layer through Fastly in order to deliver low latency, low bandwidth page loads. I also do the gzipping in the Fastly configuration instead of within the application because this is a Ruby on Rails app and as far as I know there is no simple way to gzip within the application without adding a small amount of overhead to each request. It is minimal, so in a lot of cases it still makes sense, but since my pages were already loading very quickly, the overhead represented a bigger chunk of the total milliseconds. The bottom line is that each page is delivered quickly and is less than 10kb in size.

Cutting corners on page reloads

In order to make navigating from page to page as fast as possible, I knew I wanted to use some magic to cut corners so browsers do not have to make a full page request each time. The standard way Rails developers typically do this is through a gem called Turbolinks. Turbolinks is fine but I wanted a bit more magic. I thought that it would be nice if I could pre-fetch the next page on hover and instantly serve it on the click event. I found a small library called InstantClick that did just this.

Customizing InstantClick

While InstantClick was pretty much drop-in-and-work, I found a few use cases where I was able to smartly augment its API. I modified InstantClick to allow the site’s podcast player to keep playing as you navigate the page by telling InstantClick to replace the whole page except a designated div which only changes when I tell it to. Even though this modifies the behavior of the whole website, I am still able to mostly think of the site as a simple server-rendered CRUD application which is really nice. The routing still happens on the server and there is no logic duplication between server and client. I will open source my fork of InstantClick when I feel the time is right. I think it could be a really nice little library for the web.

Disciplined CSS and JavaScript

It is easy to get caught up in how cheap it is to keep piling on JavaScript and CSS, but I made it a core goal to be deliberate and disciplined with my choices in order to lessen page bloat and keep my application manageable. This site does not use jQuery or any JavaScript frameworks. My modified version of InstantClick is basically the only library and it is about 2.7kb gzipped. Certain pages, like the wysiwyg article form on the backend, call on their appropriate JavaScript files as needed, but for most pages on the site, it is not necessary.

Constraint-Driven Feature Building

It is easy to loosen constraints when you really want to implement a feature, but I have made not doing that a priority and so far it has worked out splendidly. I try not to work on this website on any sort of deadline. This gives me time to really meditate on each feature and build a nice website. This is a fully personal project so I do not have to convince anyone to buy into my approach or meet other people's deadlines. I have rushed a few things if time seemed of the essence, but in general, things are moving quite slow and steadily, which I think is for the best.

Image Credit: DC Comics
markdown cheatsheet