I’ve spent a lot of time fighting against plugins and WordPress in general in attempt to get my Google PageSpeed over 90. I had basically given up on getting into the high 90s due to my reliance on some external resources that don’t set long expire times or, in at least 2 cases, sheer laziness in not wanting to combine and minify external CSS or JS resources myself.
Over the last week, however, I decided to give site optimizations one last go and finally got my PageSpeed over 90 — to 93 on my front page to be exact. I also managed to get YSlow up to a B — it’s an A if I use the “small blog or site” ruleset.
How’d I do it? Read below the fold for the step-by-step.
First things first … let me outline my server configuration.
The Server Config
The server is an off-the-shelf, but older, Dell with only 1GB of RAM and 3Ghz Intel Pentium 4 processor, with a 80GB SATA hard drive. It runs Fedora Core 13 (Goddard) as it’s base, but I’ve added a lot of packages to that base install and removed others (most of the desktop packages have been removed, for example).
Software Config
In short, the software stack used is squid-proxy, Apache, WordPress, and MySQL. memcached is installed, but not used — at the moment — by this blog.
Web requests are initially handled by squid-proxy, which routes the request on for further processing depending mostly on which domain the request comes in on. A lot of caching happens at this stage, to spare my overloaded back end systems. For example, most of my site’s CSS gets served directly from the squid-proxy cache, as does most of the Javascript and image files.
After the squid layer, requests are handled by an Apache with more virtual hosts and configuration that is really needed for what I actually do on the server. A lot of the configuration are relics from earlier sites or projects that I haven’t cleaned out. It’s at this Apache level that WordPress’s PHP files get executed.
I used to rely heavily on the W3 Total Cache plugin for WordPress. With it, I easily had my static resources (image files mostly) on a CDN which allowed them to load faster and in parallel to the dynamic content. I also used it’s memcached features to have my database results cached between calls.
However, recent versions of it just plain don’t work on my WordPress installation any more. This caused me to have to sit down and actually solve some of the underlying nagging optimization issues that I was facing.
What I Did
To that end, I grabbed Google’s mod_pagespeed and installed it. This was very straightforward, as my server is a Linux (Fedora) machine running, among many other things, Apache. I just followed the installation steps and, bam, everything just plain worked.
That got my PageSpeed up from the low 82 to 88. Better, but not quite where I’d like it to be.
Next, I installed the WP Minify and configured it. Just with the default settings plus setting it to combine and minify external scripts brought my PageSpeed up to 93 and the YSlow grade to B (from C), mostly by reducing the number of HTTP requests needed by 33%.
The only lingering issue is one that I fear I won’t be able to fix — external resources such as the Google Analytics JS file or some images served by Amazon and Facebook set their Expires header to 1 day or less (although, mostly they’re set to 1 day). Short of me downloading the files and question and changing the WordPress PHP to use the local versions I can’t control that header.
And so, for the moment, I can accept the PageSpeed rating of 93.
Up next: optimizing the actual code and database to render the pages server-side as quickly as possible.
Leave a Reply