Serving Pages Faster

Posted 2021-10-05 by Andrew Phoenix
Developer Dive ,  Best Practices , 

There are a wide variety of things that we do in order to try to make your websites load as quickly as possible; some of them are things that content creators can do, and some are things that require access to the site infrastructure to accomplish. A lot of these things are related to each other, meaning if you adjust one it may have an effect on another, either positive or negative, so these things are always done in conjunction with each other.

Here is a breakdown of the sorts of things that we do when serving sites and applications. We use analogies, anthropomorphism, and simplifications to make this a bit more approachable.

Page Size

While it may seem a bit obvious, one of the easiest ways to improve page load times is to reduce the size and amount of stuff that is put on every page. There are a few ways to do this.

You can reduce the size of images by optimizing images and using modern file types intended for the web. This may mean using .webp formats, or optimizing .jpg formats, depending on the project.

You can also make other static content like Cascading Style Sheets (CSS) and JavaScript (JS) faster by optimizing it. This could mean:

  • compressing it - encoding it in a specific way to have it use up less space
  • minifying it - removing extra bits like code comments or spaces that are important for developers, but not website viewers
  • including only what is necessary

It is also important to break up your web content into appropriately sized pieces. If you have a recipe website, you typically do not want to have 20 full recipes on the same page; you want to have a single recipe on a single page.

Write Good Code

There are a number of ways that a website can be written that causes page loads to be slower than they might otherwise be. Some CSS or JS can stop pages from loading until they are dealt with, so it is important to make sure that any CSS or JS is written properly on the page so that doesn't happen.

Reduce Server Response Time

One of the most important parts of delivering a website quickly is the server response time. When you request a page - you click a link, or put the URL in an address bar and hit enter - the response time is the time between when you make the request and when the server starts sending you the information for your browser to build the page. To make this as quick as possible, we do something very simple: we use highly optimized computers to respond as quickly as possible to requests.

Some pages have multiple servers that they use to serve a single page. If there is a database, for example, the database is a separate server than the application or web server, and images or other static content will come from yet another server called a "static" server. Each of these are optimized for the kind of content that they are sending out, and each one is made to respond to specific kinds of requests as quickly as possible.

Some websites are build differently! The way server response times are reduced for those websites is typically similar - we use the right type of server, and the right size of server for the job.

Effective Server Side Caching

A website may have an application server, a database server, and a static server for images. When a page is requested, here is what the application server does:

  • it looks up its instructions for building that type of page
  • it asks the database server for the data on the page
  • it asks the static server for the images on the page
  • it gets the information from the other two, and then builds a page of HTML, CSS, and JavaScript to give to your browser
  • it sends you the page which is then displayed to you

Some website may serve the same sort of content to many different people. For example a recipe site tends to give the same recipe page to everyone who requests a specific recipe, so it is a bit wasteful to build the page every single time someone wants a specific recipe, so we tell the server to save a version of that page instead of rebuilding it every time someone wants to view it. When one of these saved pages is requested, here is what the application server does:

  • it looks to see if it has a saved version
  • it sends you the saved version

This is obviously much faster, but it's important to note that data can change over time, so it is important to have a good caching policy which tells the application server how often to rebuild those saved versions.

Some websites are built differently! The way caching works is very complex, and happens at a lot of levels.

Content Delivery Networks and Browser Caching

While having optimized servers is great, it is better to bypass using those servers as much as possible. A Content Delivery Network (CDN) allows you to do this.

When a page is requested from a site without a CDN, then your traffic has to go from wherever you are in the world to the place that the actual application server is. Most of our servers are in Montreal; if someone from Perth, Australia is making a request to a site, that request has to go to the opposite side of the world before it the request can be processed and then it has to go all the way back. If there were a single wire between Perth and Montreal, this would not be particularly noticeable, but web traffic makes a lot of hops, and this can be quite slow.

A CDN allows you to push cached versions of your site to servers all over the world, so when a request is made in Perth, the CDN server in Australia will handle the request and serve the result back as quickly as possible without having to make its way across the world.

Sometimes a request doesn't even have to leave your computer to be fulfilled. When an image is requested, the browser can be told "download this image and then show it any time it is requested". This is called browser caching, and while it does not necessarily help you with first impressions, it can greatly reduce load speeds of subsequent visits to a website.