How To Blog: Site Speed-Up, Part 3 – Optimizing Images and the WordPress Database
So, picking up from Part 2 of this series of posts on what results you can expect by applying site optimization best practices to an unoptimized WordPress site, I moved to the next phase of the tutorial (Again, that can be found here.):
Dealing with the Database and Images
Thus far, all of the tweaks we had applied were via W3 Total Cache and were related to primarily the site’s CSS and scripts.
Now it was time to address inefficiencies in the backend database of the site and also the images.
The tutorial had me move from the W3 panel to the control panel of the other plugin we installed in Part 1 – WP-DBManage, which adds a “Database” menu to your WordPress Administrative navbar.
I ran through those steps, as they were pretty straight forward: backup the database, run a repair on the database and then optimize. Good enough.
I reviewed the Sprite portion of the tutorial and decided that for the somewhat limited return vs. relative complexity, I would pass on implementing Sprites.
Moving on to the larger images on the home page, there was the banner, two side bar images – one or both of which were being resized via HTML tags – always a no-no (but easy!), and then a fairly large image toward the bottom of the page, which was also being resized via HTML tags.
To make matters worse, other than saving them jpeg format in Photoshop, I had never made any effort to reduce their size. In other words, I was pretty sure that all of the images were jpeg and saved at 100% quality – the fattest they could be!
I went after the banner first because this was the largest image on the page and also one that is on every page of the site, so optimizing the banner would not only help the home page, but pretty much every page on the site.
As it stood, YSlow was reporting that the size of the home page was 527k! Half of a megabyte, that was pretty chunky. I dug up the header image in my archives, and it was 87kb, so a big share of the overall page weight. Firing up Photoshop CS, I loaded the original Photoshop file for the banner and then the Save for Web tool.
If you have never used the Save for Web tool in Photoshop (note that it is also part of the much less expensive “little brother” to CS – Photoshop Elements), it is pretty simple. It gives you a comparison view of your original and the result of the settings that you are about to apply to the image. It allows you to save to jpg, gif, png, etc. and adjust the relevant quality settings for the selected target file type. Jpegs are great when there are lots of colors, while gifs are good when your image has few colors being that gifs hold a maximum of just 256 colors.
Our banner has a relatively small color count, so ideally it lends itself to being a gif, which I had not bothered to consider when I originally created the site. Changing the target file type from jpeg @ 100% quality to gif with 256 immediately dropped the file size from 87k to 31k – less than half! Perfect example of the impact a simple change can make… Knowing that I could probably get away with even fewer colors in the gif in this case, I adjusted the number of colors in the color table while watching the results for unacceptable quality loss.
I settled on 128 with about 50% dither. My resulting file size? Just shy of 22k. Just about a 75% reduction for like 60 seconds of effort. I uploaded the image to the site and set it as the banner image.
I then ran YSlow again to see what the affect would be…
There was no grading improvement, but the page size did drop from 527k to 462k, so we were heading in the right direction.
I noticed that one of the things that seemed to be hanging while the YSlow test was running, was related to the Amazon affiliate bar I had in the side bar. I pulled that out of the bar and test again. Page size was down to 430k and the overall performance had jumped 4 points to 88 (still a B).
I was on a roll, so I also removed the GoDaddy hosting affiliate widget. That didn’t really have much impact other than to raise the individual HTTP requests grade from C to B. Speed rating was static.
So at this point, I was pretty much done. The tutorial next suggested turning on use of GZIP, but YSlow showed that it already was, and as far as using a CDN, I wasn’t ready to take that step.
Overall, I felt really good about the results. The page load was significantly faster. I will be watching the speed rating on Alexa over the next days to see how it is reflected in the rating.
Be sure to optimize your images – especially those that are used throughout the site.
Use W3 Total Cache, or some kind of caching program that you understand.
Install YSlow and monitor your site. Especially after installing and/or activating a plugin. After enabling caching in the correct fashion, the single largest impact my site’s performance was removing that sloppy social media toolbar plugin.