A Web Performance Primer
- Reduce Required Requests
- Use CSS for Your Main Images
- Use a Faster Web Server
- Implement Caching
- Enable Compression
- Eliminate Plugins
- Use a Top Tier Host
- Use a Content Delivery Network
- Employ Anycast DNS
- Test Your Site
This page is a guide to getting a website to load in less than 200ms. There’s no magic to it. There’s no single trick. It’s about fundamentals, and they’re easily taught.
Follow these steps and you’ll have a site that ranks somewhere between the top 10% and the top 1% of all web sites in loading speed.
Let’s get started.
- Reduce Requests
The most important thing you can do for your website’s performance is reduce the number of requests that are made when your site loads. Many slow websites, if you look at their loading timeline (here), you will see that they require dozens, or even hundreds, of requests to be made in order for the page to load.
Reduce this number. As much as possible.
There are many ways to do this, but the best ways involve removing bloat from your site’s functionality. Consider removing things like extra images, social plugins, and other third-party functionality that you may not need.
The best way to proceed is often to start over, with your site’s barebones functionality, and then slowly add features back one at a time. The key is to pick only the most necessary and most quickly loading components when you do so.
When watching your site load using the Pingdom tool above, watch for all the different things that load. Find that stuff in your code, and try to remove it if possible. Find a way to do the functionality another way (without making external requests) if you can.
My site (the site you’re on), for example, only has one type of social functionality. It’s just three social buttons, and they load very quickly. Most everything else is text—except for some core images, which is the next topic.
- Use CSS For Your Main Images
Ok, so now we have our site running lean and mean. Hopefully we have very minimal functionality on the site. Maybe only one or two external calls. Next we’ll talk about your main site images.
CSS Sprites are a way to implement images in your CSS. Going back to the first rule, which is reducing the number of requests that are required to load your page, the idea of CSS images is that your main site images are loaded into your CSS file, so that once a visitor loads that they never have to ask for your main site images again.
My header image above, for example, is a CSS image, so I don’t waste an image load on it. You should consider doing this for the main images on your site, such as your header/logo/etc.
- Use a Faster Web Server
Ok, so now we have reduced our requests, and made our main images (logo/header/footer/whatever) into CSS sprites. Now it’s time to look at our server.
Many sites still run Apache as their web server software. Apache is great, but it’s designed to do pretty much anything and everything. If you’re running a simple site, another option is probably better.
I run, and recommend, Nginx.
Nginx is fast, and it’s far easier to configure because simplicity is part of its identity.
Once you’ve switched over to Nginx, you need to simplify it as well. You want to make sure you’re not running SSL unless you have to. You want to disable as many modules as you can. Minimalism is your guiding principal, this is true for your website overall and for your web server in specific.
- Implement Caching
Caching is a way of cheating on our rule #1. It works by telling your browser that the content you got earlier from the server doesn’t need to be retrieved again, and that you can just use the copy you already have.
You want to cache as much of your site as possible. In general, you want to cache the stuff that doesn’t change often. And the less often it changes the longer you want to set the cache times for.
Caching can dramatically increase the load time of your site—again, because your users are actually pulling far less of it down each time.
- Enable Compression
Compression is key to performance because for every given thing that you do have to download—which is hopefully far less by now—can be downloaded with far less being transfered over the wire.
You can get significant performance gains from compression, and it should be used wherever possible.
- Eliminate Plugins
Many types of web software have extensions, or plugins, available. WordPress is a CMS platform that makes extensive use of plugins, and many WordPress sites have a dozen or more loaded.
Plugins are sub-optimal. If you have to use one or two, and you understand them well, and know them to be fast and secure, then there’s not much harm in them. But you should find ways to implement the functionality in plugins in the native functionality of your site if at all possible.
Unsupervised Learning — Security, Tech, and AI in 10 minutes…
Get a weekly breakdown of what's happening in security and tech—and why it matters.
A great example for WordPress is, coincidentally, with speed plugins. There are a number of speed, and caching, and compression plugins available for WordPress, yet all the functionality that they provide can be accomplished without plugins.
This site uses WordPress for /blog/, and the blog is wicked fast, yet I’m not using a single performance plugin. I accomplish all the same functionality of caching and compression within Nginx itself rather than relying on a far more opaque and potentially insecure third-party to do it for me.
Look at your plugins. Figure out if you truly need the functionality they provide, and if you do—try to implement it in your native components rather than through extensions.
- Use a Top Tier Host
Now that you have everything sorted out, it’s time to make sure you’re using a top quality hosting provider. They make look and sound the same, but they’re not.
Since we’re talking about people who are configuring their own servers here, we’re talking about VPS providers, and my recommendation there is Linode. I’ve used nearly a dozen different providers, and Linode remains my favorite. Highly recommended.
Lower quality hosting will slow you down via inferior disk speeds, poor network performance, not to mention downtime.
- Use a Content Delivery Network (CDN)
We’ve now done a number of things to your site itself that will massively improve it’s performance. Now it’s time to do some external tweaks.
CDNs make your site faster by hosting your static resources, like images and JavaScript and CSS files on ridiculously fast, globally-distributed servers. These servers determine where your visitors are, and then serve your content from the location nearest to them.
They are also at a number of other optimizations, like further compression, ensuring your images have size attributes, etc., which can help with load time.
I use Google’s Page Speed service, which is excellent. Unfortunately it’s a somewhat closed service that you have to request access to, but there are other options available.
If you’re not able to get on Google Page Speed, I recommend taking a look at CloudFlare.
- Employ Anycast DNS
Now we’re really tweaking every last bit of speed out of the site.
Anycast DNS is like CDN for DNS. It makes it so that when people resolve your site, the answer can come from a point of presence that’s extremely near to them—no matter where they are in the country, or in the world. This means your content gets to them faster.
There are a number of Anycast DNS players out there, but I use DynECT (Dyn).
- Testing
Ok, so we’ve implemented all the changes and the site seems pretty fast. But how do we really know?
Test your site extensively and periodically—especially after you’ve made significant changes.
Enjoy
Brilliant. So if you’ve done everything above you should be seeing load times below 500ms (half a second) from anywhere in the world. And if you’re lucky, it’ll be more like ~200ms. Your users (and Google’s rankings) will thank you.
If you’re not seeing these kinds of speeds, check out what’s happening using the testing tools mentioned above, and feel free to contact me if you still have any questions.
Notes
- The core concept of this entire primer is that of simplicity. You want to simplify as much as possible, from code, to requests, to add-ons, to third-party functionality, etc.
- I’ve written many articles on this topic in the past, and they should all redirect here now.
- Here’s a link to the Nginx website.
- Nginx is one choice for a lightweight web server, and it’s my choice, but it’s not the only option. LightHTTPD is another good one, and I’m sure there are others. Don’t feel like you MUST use Nginx.
- An article on CSS Sprites.