Design & UX

How to Make Your Blog Load in 560ms

David Turnbull
Share

I’ve built a lot of blogs over the years. Each time the process begins, I ask myself: “How do I make this blog load faster than ever before?” Because, aside from personally appreciating a fast page load time, it also has a big impact on the bottom line — it increases page views, lowers bounce rate, and has been linked to improved sales numbers for sites like Amazon.

With my latest project, I’ve managed to make my blog load in about 560ms. This isn’t necessarily achievable by everyone — my blog is quite simple — but most people can surely get their blog loading in under one second.

Here are my suggestions.

1. Track your page load time

Before making any changes to your blog, run it through the following tools:

All of these provide a measurement of your current page load time, along with tips and tricks to improve that time. It helps to have a baseline measurement so you know what changes are having an impact, and it also helps to re-test as you go to get an even better idea of what’s making a difference.

2. Use a static blog generator

This is less of a tweak and more of an entire change in philosophy, but hear me out. Dynamic software like WordPress places a lot of load on servers, and that load is inevitably passed on to users. If you need WordPress, that’s fine — the remaining tips will still apply — but if you don’t need it, then I’d suggest checking out either Jekyll or Middleman. These tools allow you to generate a static, HTML-based blog on your computer, which you can then upload to whatever server you want. This means:

  1. Your server will only have to serve static files. There won’t be any intensive processing involved. This is far more effective than mere caching and has a huge impact on page load time.
  2. You’ll have much finer control over your website. WordPress is plenty flexible, of course, but hardly anything compares with the precision that comes with a static blog generator.

Admittedly, converting a WordPress blog to a static blog probably isn’t worth the effort, but it’s worth considering a static site generator for your next project.

3. Simplify your blog’s design

Most blogs have too much going on. Many have obnoxious designs, huge images, embedded videos, social sharing buttons, advertisements, animations, and more.

Some of this stuff is necessary, but it’s rare that all of it is needed. As such, I’d suggest conducting an audit on your blog’s design. Maybe even print a copy of your homepage, sit on the couch, and consider two things:

  1. What is absolutely necessary?
  2. What could be removed?

You don’t have to make your blog as sparse as mine, but do be critical and try taking the epicenter approach to design:

Epicenter design focuses on the true essence of the page — the epicenter — and then builds outward. This means that, at the start, you ignore the extremities: the navigation/tabs, footer, colors, sidebar, logo, etc. Instead, you start at the epicenter and design the most important piece of content first.

Most of the time, simplifying a blog doesn’t involve any actual sacrifice. It might feel like you’re losing something, but the readers come for the content, not for the bits and pieces in the sidebar.

4. Choose a host server near your site visitors

If your website is hosted on a server in New York, a visitor from New York will have a faster page load time than someone from the opposite side of the world. Because of this, it’s worth knowing where visitors are coming from.

For a lot of SitePoint’s readers, the answer will be, “the United States,” but:

  1. If that’s not the case, it might be worth hosting the blog elsewhere.
  2. The United States is a big place.

Something I noticed, for instance, is that a lot of my blog’s visitors were coming from the west coast. As such, I moved my blog to a server that’s hosted in San Francisco. This didn’t cost anything extra, but it means that many of the visitors are getting that extra pleasant experience.

As for how to track where your visitors are coming from, all of this data is available through Google Analytics. Just set up a map-based widget. It’ll only take a moment to figure out the best place to host your website.

5. Switch to Digital Ocean (or Linode)

All the optimization in the world means nothing if your blog is hosted on a server that’s chugging along with poor performance. And if you’re feeling like your host is a little sickly, I’d suggest switching to one of the following:

  1. Digital Ocean
  2. Linode

Both of these services, aside from providing very affordable hosting, have two main benefits:

  1. They use solid-state drives, which is a huge boon to performance.
  2. They are absolutely barebones, so no performance-hogging junk is installed on your server by default.

The downside of course is that you have to know how to operate a server via the command line but that amount of control means you have a lot of flexibility with improving performance even further.

(There are traditional hosting companies that use solid-state drives, but none that I’ve used, so I can’t personally recommend any of them.)

6. Install nginx

Most of the web servers in the world are running Apache. But while Apache is flexible and feature-rich, it’s far from the best option if you’re concerned about performance. In that realm, nginx is the king of the hill.

nginx is a fast-growing alternative to Apache that has fewer features and certain limitations, but it comes with huge performance gains. There are, however, a few things to keep in mind:

  • You’ll probably need to install nginx on your own server. This can be tricky for beginners but there are plenty of helpful guides to assist you.
  • Installing WordPress can be even trickier, but Digital Ocean has a one-click option that you might want to check out.
  • If you’re using a static blog generator, using nginx has no downsides and it’d be a big waste to not make the most of it.

Switching to a new web server is not a simple change but, as with static blog generation, do a little research. It won’t take long to see the benefits.

7. Deliver assets via a CDN

Generally, when a user visits a website, all of the resources — the images, the JavaScript files, etc — are downloaded from a single location: the server. But while this might sound perfectly normal, it’s a problem for two reasons:

  1. A single visit can place a lot of load on the server.
  2. There’s a better approach available.

The alternative is to use a content delivery network (CDN). A CDN is used to off-load the hosting of resources like images and CSS files, so when a user visits your blog, your server handles only the bare minimum of processing; everything else is loaded from an external server that’s optimized for speedy delivery.

This is useful because:

  1. Content delivery networks operate from data centers around the world, so resources can be delivered from locations closer to your visitors.
  2. By not delivering these resources from your own server, you’re far more immune to traffic spikes and other sources of slow-down.

You can even be cheaper than the standard approach. I pay $5 per month for a Digital Ocean droplet and off-load all of the resources to MaxCDN for $60 per year. For the amount of performance I get, that’s a great deal.

8. Deliver (some) assets with a third-party CDN

A lot of modern websites share common assets, like jQuery, and it’s not the best idea to host these resources yourself. Instead, the better approach is to deliver them from third-party servers, like Google’s:

<script src="//ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js">
</script>

This gives you the benefit of using a CDN (for free), and many visitors will already have a Google-hosted copy of jQuery cached in their browser, avoiding the need to download the library again.

There are third-party CDNs available for more than just jQuery though, many of which you can find here:

9. Minimize HTTP requests

For every resource that’s loaded onto a page, an HTTP request is required. So when a CSS file is loaded, that’s an HTTP request. Or when a social media share button is embedded on a page, that can be 2-3 HTTP requests. But even if these requests only retrieve a small amount of data, the requests themselves are one of the biggest sources of page load time.

To combat this:

  1. Embed social buttons only when they’re needed. Your audience probably only uses a small handful of the most popular sites.
  2. Where possible, combine files. Instead of having multiple CSS files, for instance, put all of your styles into a single file or have a workflow in place that automates this process.

Also, refer to one of the previous points about simplifying your blog’s design. If your blog is loading slowly due to HTTP requests, there’s probably too much happening.

Conclusion

Website performance is a big topic, and there are plenty of other things to consider to get every ounce of speed from your blog and server. In this post, we’ve covered some fundamentals that provide the biggest impact.

What strategies are you using (including ones that I haven’t mentioned)? Share them in the comments below.