So how do we get this:
To do this?
First: Where there’s a will, there’s a way (yes, I pulled out all the tricks to get that score).
Second: While PageSpeed and YSlow are good indicators, they’re not a hard-and-fast rule. In fact, some of the things I did to reach that score actually made the site slightly slower (in terms of the total page-load time for real visitors) and I ended up turning a few things off.
Like I said though, a high PageSpeed/YSlow score isn’t everything. Your goal should be to focus on the page load time for users.
So that said, you’re already using one of the quickest WordPress themes out there, so let’s look at a few more things you should consider doing…
Try to get scripts out of the head and into the footer
Above, you see a “waterfall” for a typical post with 7 images on a WordPress site running Jishnu after a fresh install. A brief explanation as to what you’re seeing, just in case you aren’t familiar with these:
- The time moves left to right. The left side is T=0 (the moment we tried getting the webpage). The right-side is when everything has finished loading (roughly a second later). Each bar represents a file that Firefox is getting to load the page.
- The first bar (top one) is the HTML itself. If you’ve ever done “View Source” on a webpage, that’s essentially what this is.
- The remainder are images that were in the post, except the last 1 which is the image sprite the theme uses.
Notice the difference?
You might wonder why that last file is a bit of a straggler. Actually, it’s the image sprite that the theme uses, and by default it isn’t called until the CSS is loaded. If you look at where the CSS download ends (that’s the 2nd file), you’ll see it lines up with where the last file starts.
Let’s pretend we’re all hard-core and OCD about things lining up….
Ok, so how did we do this? Actually, in Jishnu Options, there’s an “Advanced Options” section (you know, the one with the big red warning).
All we did was check the following 2 boxes in the Tweaks to HEAD, Performance Tweaks, SEO, and Miscellaneous area:
- Preload image sprite (for that last one!)
- Move jQuery to footer (update: I recommend using a plugin for this now)
To move jQuery to the footer, I recommend using a plugin called Autoptimize rather than the setting built into Jishnu. Autoptimize will actually gather all your scripts (though you can exclude some if necessary) and load them in the footer in a “deferred” way which shouldn’t block the page load. It can also combine your CSS, and minify both of those (plus the HTML). I suggest setting the plugin to INLINE your CSS because the page will tend to “show up” much quicker for visitors the first time they visit your page. Separate CSS files always result in an extra request and usually all that overhead adds additional time. Autoptimize also works out-of-the-box with Jishnu.
If you’re using other performance-oriented plugins, I suggest enabling the Autoptimize settings one-at-a-time so that if something gets wonky you can narrow it down. As an example of something “wonky”, if you have W3TC installed and have the “minify” section enabled for the HTML, trying to optimize the HTML in Autoptimize too will give you the following message:
PHP message: PHP Fatal error: Cannot redeclare class Minify_HTML
So enable things gradually, checking to make sure everything works after each change. Remember, the plugin works great with Jishnu but that doesn’t mean all your other plugins will get along with it!
(now is probably a good time to mention that if you’re using Google Analytics, rather than using a plugin to insert the code, you can manually put the code in your HTML very easily with Jishnu by plugging it into the Custom HTML section).
Moving on to plugins…
“Use Google Libraries”
Wed Aug 7th 2013 Note: I hit an issue in WordPress 3.6 where replying to comments from within the backend no longer works with this plugin enabled. I’m assuming the plugin will be updated at some point to address the issue, but I’ve been seeing better improvements by simply using the Autoptimize plugin mentioned previously.
Use Google Libraries (author link here) is a plugin. Normally, your site serves up the jQuery that comes with WordPress to all your visitors. It’s only 33KB (compressed), but let’s face it – that’s bigger than everything else in the theme put together. It also has a “query” string added to it, which means it won’t be cached by some proxy servers.
The solution? Google has jQuery available for anyone to use. And the “Use Google Libraries” plugin will tell WordPress to use that one instead. 4 quick benefits…. First, there’s no query string. Second, Google’s servers are… probably a little bit faster and a bit more distributed-around-the-world than the one your website is running on, so it should load lightning-fast for somebody on the other side of the world. Third, because a large number of sites are doing this, there’s a good chance the Google version will ALREADY be cached by your visitor before they even arrive on your site!. So they won’t have to download it at all when your page loads! And fourth, it’s a little less data transfer (and one less file request) coming from your end.
That on it’s own is great, and even if you do *nothing else* (no W3TC, etc), it’s a smart thing to use.
The only downside… in order to be “safe”, it checks every so often to make sure that jQuery is still up on Google, so there’s the potential for a page load to take a little extra time every so often when it wants to check. Oh, and it creates an insane number of PHP ticks (over 300) which might give you a miniature heart attack if you watch that sort of thing.
WP-Smush.it and others
I’ll admit it, I’m bad when it comes to uploading images on a page. Those images at the top…? They’d probably be half the size if I’d converted them to JPG’s before uploading.
One thing you *can* do though is install WP-Smush.it (author link here). It will automatically “Smush” the images you upload to your site. For those who aren’t in-the-know, when you take a screenshot, save an image from your camera, or save a picture in paint or photoshop, it isn’t always saved as efficiently as possible. WP Smush it will run your images through a few algorithms to make them smaller.
An even better (but manual) option for Mac users is to use ImageOptim. It uses a number of tools to squeeze down the size of images – typically getting them smaller than any other program out there does. Unfortunately I’m not aware of any Windows-based all-in-one solutions that even come close to comparing (though saving in Adobe Fireworks can get it close enough for Smush-it to get close).
Typically, what you’d do with ImageOptim is zip your entire wp-uploads folder, download it, unzip, and drag it right into ImageOptim. Let it go to work on all your images and once complete, re-zip, upload it, and copy it over the originals (be careful to hang on to the original zip file and any backups just in case something goes wrong). From then on, every so often you could just zip up the last few months worth of images and repeat the process. Or better yet, use ImageOptim before you upload your images (though it won’t help the thumbnails that way).
Just to emphasize how beneficial these things can be, the images I have on the previous page… ImageOptim shrunk them by 40%.
Use a cache program (Lite Cache, Hyper Cache, W3TC, Super Cache, etc)
If you remember in the images from previous pages, we were looking at roughly 800-1000 ms (just under a second) for the page to load.
Actually, each of those purple bars were the browser waiting on the server (which includes WordPress) to piece together each page – the downloading part was so quick, you probably can’t see it in the images (look for a dark green sliver at the end of each bar).
Let’s see what Lite Cache does:
The bars look similar (it always stretches them to fill the screen), but look closer… Look at those times!
We went from 804 ms all the way down to 528 ms!
That’s because the page itself went from over 400 ms down to about 130 ms!
Here’s a comparison to help show it:
Yes, Lite Cache is impressive. And so are the others I’m about to mention!
Here’s a quick list of common cache plugins for WordPress:
- Lite Cache (author link) which we looked at above is very simple, clean, and efficient, but can be slightly complicated to set up unless you’re familiar with adding values to wp-config.php and .htaccess (it tells you what to add, mind you and it only takes 20 seconds or so).
- WP Super Cache (author link) is another popular one with it’s own set of features, and should also be easy to set up (I believe it also injects changes for you).
- Hyper Cache (author link) is created by the person who makes Lite Cache. Hyper Cache has been around longer, and could also be worth a look.
Note that the cache programs I’ve tended to use in the past have been Hyper Cache and W3TC. This was the first time I’d actually used Lite Cache (figured I’d check it out while testing). I always liked the simplicity of Hyper Cache, and W3TC tends to do the best job when it comes to combining/moving JS, particularly when you’re aiming for a JS file without a query string.
As a side-benefit, the caching programs can all reduce server load, since WordPress doesn’t have to regenerate the page for each and every visitor.
Oh, and if you’ve never used a caching plugin before…. only install ONE.
.htaccess stuff – caching and compressing
The vast majority of people have their sites hosted on a Linux host, running Apache. And most of the time, there is an .htaccess file in your web directory. Here, you can set up a few extra rules for Apache when serving up your content.
This isn’t specific to WordPress, but can keep things quick for frequent visitors. Somebody shared it quite some time ago, and I’ve used it on a few sites. Note that W3TC (mentioned last page) adds similar things if you make use of the “Browser Cache” setting there, so if you’re using it, no need to go plugging this stuff in.
Most of this “checks” to make sure your server allows you to use each rule, but just-in-case something goes wonky, make sure you quickly check your site after saving this to .htaccess to ensure your site still works! If it doesn’t, you’ll want to quickly remove it and save again.
It’s a little small, because…. well, it’s kinda long. Details afterwards (which you should read!).
Again, make sure you’re using an editor that won’t break down if for some reason pasting this into .htaccess breaks your site. If you’re on a host that uses cPanel, the editor that comes with the file manager will do fine.
For a quick (but important!) explanation, this is essentially what this stuff does:
- Adds a lot of “types” based on file extensions.
- Configures “ETags”. If that sounds boring, just skip to the next point. If you want to know what they are, keep reading…. Essentially, when the expiry date is reached, or if a visitor hits refresh on your site, their browser might still have a file in the cache but isn’t sure if it’s the latest one, so it sends a request with the “ETag” it has for files it would normally download – essentially a small checksum based on the file size and last-modified date. Your server can tell if the browser has the latest version based on that code, and if it does, it sends “304 – not modified” rather than sending the file. On the other hand, if the browser doesn’t have the latest version, it sends the new file. As for configuring it, what the code above does is set it to calculate the ETag based on file size + last modified date/time.
- Adds some Cache-Control headers.
These are handy things that can help speed up your site, while increasing PageSpeed and YSlow scores. Do use them with caution though – if you constantly change files that would normally be static for a long period of time, at the very least you may want to dig in and modify the expiry time.