Successful websites need to be fast, scalable and secure. In this article we survey the state of the art of high-performance websites, in particular SSL encryption, HTTP/2, CDNs and browser caching. We’ll cover the major performance optimizations and show how we did it in our setup.

Building a static website today is easier than ever. There are so many great things you can use to build a stunning landing page, blog or whatever you want. With static site generators like Jekyll, Hugo, Octopress or Hexo you can even take this to the next level and build your site hassling much less with HTML, CSS or JavaScript. Github pages, for example, are rendered with Jekyll.

So almost anyone can build a great website today. There is one last step before becoming rich and famous, though: You need to host the site somewhere on the internet to make it accessible to everyone. That’s going to be just as easy, right? Well, not exactly.

Example of a static website hosted in central Europe and loaded from the US.

Putting the site on a server and setting up a domain for it is simply not enough these days. For a great website to be successful, it needs to excel in three things: speed, scalability and security.

State-of-the-Art Hosting

Especially with static sites, these requirements are not all that hard to achieve — in theory. But let’s take a look at what needs to be done in practice.

HTTPS (SSL/TLS Encryption)

I know what you are thinking: Do I really need SSL for my website? The simple answer is: You do!

HTTPS does not only protect sensitive information like passwords, payment data or simply the user’s identity, but also provides authentication to make users confident they are surfing the legit website. HTTPS further ensures integrity, meaning no one can alter your content by, say, injecting ads without your permission. SSL simply builds trust. Browsers acknowledge that by highlighting secure websites or, in case of Google Chrome, labeling non-HTTPS websites as Not Secure. Also, with all current browsers, HTTPS is mandatory for HTTP/2– and you really want that for speed, but more on that later. Furthmore, Google boosts your SEO rank, if your site uses HTTPS.

Browsers highlight secure websites which builds trust.

Regarding the setup, things have become much easier with the Let’s Encrypt project. They generate certificates for free and there is tooling to fully automate domain authorization and certificate signing. But even with Let’s Encrypt, you still need to figure out how to install certificates on your server (or CDN), make sure the certificates are renewed on time (expiring every 3 month) and probably enforce their usage by configuring HSTS headers to prevent protocol downgrade attacks.

But HTTPS is not only notoriously hard to set up from scratch, it also effects website performance if you don’t take precautions:

Encryption is always hard on the CPU and TLS encryption will certainly add some overhead to your server-side processing. Keep that in mind for server capacity planning. An autoscaling server infrastructure that monitors throughput, deals with load spikes and ensures availability will be discussed below. The initial TLS handshake adds 2 additional roundtrips to the TCP handshake, which itself already needs 2, resulting in a 4 roundtrip handshake. Depending on the distance between client and server this can amount to more than a second only to set up the first connection. To speed up the handshake, you need to make sure that your server supports TCP Fast Open as well as TLS False Start and Session Resumption. These will halve the time of your handshake. There are even more considerations (e.g. dynamic packet sizing), of which Ilya Grigorik from the Google web performance team gives a great round-up. The most important optimization, though, is to use HTTP/2 with all its benefits. Getting rid of domain sharding and using a single HTTP/2 connection instead can already save you expensive connection setups.

In essence, HTTPS is required for customer trust and security, but even with state-of-the-art tooling it impedes fast loading times and thus can diminish customer satisfaction. Also, the complexity of setting things up smoothly keeps many website providers from using HTTPS in the first place.

HTTP/2

If you have HTTPS, you definitely want HTTP/2 (also called h2). The second major protocol version of HTTP has lots of optimizations and features that fix common HTTP/1.1 problems. It comes with server push to transfer multiple resources for a single request, header compression to drive down request and response sizes and also request pipelining and multiplexing to send arbitrary parallel requests over a single TCP connection. With server push, you can for example push the CSS and JS right after shipping your HTML without waiting for the actual request.

Multiplexing and pipelining make a huge difference, in particular for websites with many assets such as images or videos. Take a look at this live comparison as well as the following example: