A Website Performance Boost — at the Expense of WordPress Plugin Compatiblity

I happened upon the site WebSiteOptimization.com and started testing the performance of my site. I was astounded by how long it would take to load the front page of my site over a 14.4 kbps modem connection. True, not many people use a modem connection anymore, but still, 130 seconds is a long time to wait! Now this the time required to load every last image, not the the time required before the page starts to render and become readable, but still there is room for improvement. So I started playing around with performance settings and quickly made some substantial gains.

First of all, I enabled the WordPress CSS-Compress plug-in, which compressed the CSS file and all of the images referenced within it, which reduced the number of HTTP requests. Secondly, I enabled GZIP compression (through the Options -> Reading -> “WordPress should compress articles (gzip) if browsers ask for them” option.) I noticed that the new Contact Form plugin, which I hadn’t even implemented on any page, was also causing a bunch of HTTP requests, so I deactivated it. I made some substantial improvements; I noticed pages loading substantially faster on my cable connection and was very pleased. A test showed 14.4 kbps download times were reduced from 130 seconds to 40 seconds!

But then I realized why I hadn’t enabled Gzip compression previously: some of my WordPress plug-ins won’t work with Gzip compression enabled. According to Denis de Bernardy:

The gzip is enabled before the output buffers are actually processed, so using it prevents plugins that use output buffers (external links, admin menu, ad spaces, etc.) to work properly. The gzip option in itself should never be active anyway. Apache can do this by default, and in the cases where it does you can end up with double-gzip’ed content.

So I worked to enable compression within Apache by modifying my .htaccess file, but that just brought my site down. Mod_gzip and mod_deflate aren’t supported and I’m on a shared server, so I don’t have full control. So I made the call, and axed the plug-ins that weren’t working, namely the plug-in that identifies external links and another that places an administrative menu bar across the top of my site (for me only.) I really like those plugins, but they are not worth the performance hit. Until I find a way to enable Apache (server-controlled) compression, I’m going to go without them.

Total HTTP Requests: 30 | after: 11

Download Times*
Connection Rate Download Times (before | after)
14.4K 130.70 seconds | after: 40.22 seconds
28.8K 68.35 seconds | after: 21.51 seconds
33.6K 59.44 seconds | after: 18.84 seconds
56K 38.07 seconds | after: 12.42 seconds
ISDN 128K 15.82 seconds | after: 5.75 seconds
T1 1.44Mbps 6.85 seconds | after: 3.06 seconds
*Note that these download times are based on the full connection rate for ISDN and T1 connections. Modem connections (56Kbps or less) are corrected by a packet loss factor of 0.7. All download times include delays due to round-trip latency with an average of 0.2 seconds per object. With 30 total objects for this page, that computes to a total lag time due to latency of 6 seconds. Note also that this download time calculation does not take into account delays due to XHTML parsing and rendering.

Written by in: Wordpress | Tags: , , , , | Last updated on: 2014-May-27 |


RSS feed for comments on this post.

Leave a Reply

If you have a comment or question, please post it here!

CarltonBale.com is powered by WordPress | View Mobile Site | © 1996-2017 Carlton Bale