Make Your Site Blazing Fast: Part 1

It’s no secret: today’s web users have the need for speed. With internet and cellular connections getting faster and faster, users expect sites to load quickly, and it’s a developer’s job to do what they can to serve those pages quickly. So how do you make your site blazing fast? Here’s what you should be doing specifically when building with WordPress.

First Thing’s First: Test Your Site’s Speed

Performance can be broken down into two main categories: front-end and back-end. I consider back-end to be anything related to the server and how data is populated on a page (your PHP code in your theme is the “back-end”). The front-end consists of all your assets (CSS, JavaScript, images, etc.) and markup. Everything a web browser reads and interprets is the “front-end”. The reason I’m making this distinction in terms of performance is because it’s good to know what you’re optimizing and, even more importantly, where you need to optimize the most.

To test the speed of your site, I recommend using a combination of WebPagetest and Google PageSpeed Insights. WebPagetest gives us a good idea of the actual time (in seconds) that a site takes to load, giving you some good metrics to know whether it’s the back-end or front-end causing a site to load slowly. PageSpeed Insights is best for looking at how your site is rendered by the browser and what you can improve on the front-end.

Keep in mind that this article is focused on totally customized WordPress sites. If you’re running speed tests on a site using a bulky theme and 19 third-party plugins (plugins can slow down both the front and back end), start by getting to a blank slate and slowly activating plugins one by one to find those that are slowing things down.


Front-End Performance

The golden rule of performance, according to Fastly’s chief performance officer Steve Souders, is that 80-90% of a page’s total load time consists of the front-end (the 80/20 rule). The back-end’s 10-20% is crucially important, but even if you’re using the fastest host money can buy, your site still won’t live up to its full potential without optimizing the front-end to make sure users perceive that it’s loading fast. Perception is important when it comes to front-end optimization. A user won’t care how long, in terms of seconds, a site takes to load. All they really care about is how quickly they can interact with it and see content or perform actions without a delay. Not to say you shouldn’t be worried about the actual load time (you should), but by following the techniques below, you can make sure your site is at a usable state as quickly as possible, followed quickly with a complete page load of all the assets.


The most important thing to do with your CSS before it’s delivered to the browser is simply to compress it and remove unused selectors. Getting a good development workflow down when developing themes makes this process trivial, especially if you’re using a pre-processor like Sass. I use Grunt, which is a JavaScript task runner that executes commands for you while developing. There’s a plugin for Grunt called grunt-contrib-sass that simply compiles all your Sass files down into one (if you’re using Sass partials, that is), minifies it and compresses it. Throw in the grunt-contrib-watch plugin on top of that and it will run the Sass task whenever you save a file. Easy! Don’t lose sleep if you’re not using the latest and greatest CSS methodology, but try to follow some sort of standard while authoring CSS as to avoid duplication and huge file sizes.

Once your stylesheet is ready to go, the easiest (and by far, the standard) way to load it is to just reference it in the <head>;. That way, the browser loads and parses it before the rest of the DOM is loaded. However, there’s a new technique where “critical” styles are inlined in the <head> and then the full stylesheet is loaded asynchronously using JavaScript. I only really use this technique when I’m absolutely trying to get a site to load (or perceive to load) under a second, but it’s a great thing to look at and see if it can fit into your workflow. The Filament Group has a great extensive article on using this technique.


The golden rule(s) of optimizing JavaScript is simple: serve as few JavaScript files as possible and minify and concatenate. Third-party WordPress plugins can be detrimental by bloating your document with unminified blocking JavaScript files, so it’s important to be mindful when choosing plugins. Ideally, you’d concatenate ALL JavaScript files into one and then minify the heck out of it. For times when it’s not possible to concatenate all your files into one, there are HTML attributes called “async” and “defer” that can be used to load JavaScript files asynchronously or once the rest of the page is loaded.

The most common place nowadays to reference JavaScript is at the bottom of your document, right before the closing tag. However, there are more advanced techniques to load JavaScript. Again, the Filament Group has done tons of research on this and has several open source projects that you can use if you’re aiming for a super fast page load time (I’m in no way affiliated with Filament Group, by the way; I just think their stuff is awesome). The best approach seems to be to load scripts dynamically by inlining a small function in the <head>; that then appends script tags without blocking the rest of the page. For more information, check out the loadJS script.



Images are often the biggest files on a page, responsible for the largest delay in page load time. The good thing about images though is that, unlike CSS and JavaScript, most browsers load them asynchronously. That at least helps with the perceived performance of a page, but you still want to make sure that A) you’re serving as few images as possible and B) those images are compressed as much as possible.

Compression tools are necessary for squeezing out as much excess as possible on images. ImageOptim is a great Mac app that does this well, along with OptiPNG and jpegtran for use with task runners like Grunt.


Web fonts are super common these days. I use Google Web Fonts on nearly every project, but until lately I didn’t realize the performance hit I was taking by just referencing them in the <head>. The performance hit is small, but this is an article about making sites blazing fast, so everything counts! For best performance using web fonts, I recommend using the Web Font Loader, co-developed by Google and Typekit. It’s an open source script that both manages the loading of your fonts from third parties like Google Web Fonts and allows them to load asynchronously (getting tired of that word yet?).

As expected, there’s some configuration needed to get Web Font Loader integrated into your project, so check out the project on GitHub for details on how to get it set up.

Get started.

Build faster, protect your brand, and grow your business with a WordPress platform built to power remarkable online experiences.