Return of website optimization

UPDATE (10/27/2011): As of today, I’m scoring a 99/100 on PageSpeed (missing point is an erroneous error about images being unoptimized), and a 99/100 on YSlow (missing point is about Cloudflare setting cookies on static content, which isn’t a huge issue). So at this point, I can finally say “USE CLOUDFLARE”. It’s more than worth it (which, since it’s free….).


So in a fit of boredom last night, I decided to take a look at page speed increases again.

This time is a bit different as I’m not using Cloudflare and I’ve changed themes. Since moving to the new theme, and an update to W3TC, I’d been getting in the mid-80′s for both Page Speed, and YSlow. Which shouldn’t be the case with Cloudflare. Everything says it should have greatly improved my speeds, and score… so something was clearly up.

So, some testing later, and I’ve figured out what was up. First, was disabling the automatic settings in W3TC. I’m guessing this (automatic minify) would work if you weren’t using a WP_CONTENT_URL (which I guess I probably don’t need anymore with Cloudflare… but changing to not use it would take a bit of work at this point.). The point of the WP_CONTENT_URL, however, is to “parallelize” the browser download process… so Cloudflare probably doesn’t solve this issue.

Anyway, disabling it, then going into W3TC’s minify section and adding all the URLs for your CSS and JS files that are loaded on your home page. Also, I went into my thematic child theme’s style.css, and removed all the @import’s, and added those CSS files to the minify settings. Reordering the CSS and JS was then a trial and error, but got it working.

Now, page loads are damn fast. And YSlow gives me 99/100, and Page Speed gives me a 97. Cloudflare gives me the CDN points, so the only thing hurting my YSlow score is Google Analytics not having long distance expiration.

Optimization takes time, but it works. I’m not positive why Page Speed is knocking off the 6 points, but I think it’s some CSS inefficiencies. *shrugs*

Good luck, and feel free to ask if you run into any issues. Might just redirect you to somewhere else, but it’s working.

Ugly…

I know my site just got kind of ugly, but I’ve had a hell of a time working with a development version of the site, and I figured so few people actually read my site anyway that I should just bite the bullet and do the development on the live site anyway.

Anywho, it’s ugly now, but it’ll get better looking over the coming days/weeks. Please be patient.

Thanks.

WordPress _transient buildup

WordPress uses DB entries called _transients to cache certain data. Cached entries are by default, things like RSS info, when cron last run, etc. If you use a plugin like Google Analytics Dashboard (GAD hereafter) though, you also get cached data relating to that. Unfortunately, either due to a bug in WordPress, or something left out of GAD, this cached info doesn’t seem to be deleted after it’s designated expiration time/date (_transients have a set expiration time, but they don’t seem to matter for GAD set transients).

Looking around online, I found someone who was dealing with a similar problem here.

The trick was to add the following to my the functions.php file in my theme.

functions .php addition


add_action( 'wp_scheduled_delete', 'delete_expired_db_transients' );

function delete_expired_db_transients() {

    global $wpdb, $_wp_using_ext_object_cache;

    if( $_wp_using_ext_object_cache )
        return;

    $time = isset ( $_SERVER['REQUEST_TIME'] ) ? (int)$_SERVER['REQUEST_TIME'] : time() ;
    $expired = $wpdb->get_col( "SELECT option_name FROM {$wpdb->options} WHERE option_name LIKE '_transient_timeout%' AND option_value < {$time};" );

    foreach( $expired as $transient ) {

        $key = str_replace('_transient_timeout_', '', $transient);
        delete_transient($key);
    }
}

Later in the day, when that cron task ran, it removed all the expired transients from my wp-options table, and at midnight, when my system cron task ran to optimize my DB tables, the table shrunk down to the size it should be. If you so wanted, you could add the optimize operation to the above, but I figure it’s not that big of a deal once things are under control. As always, back up your DB and any files you modify before implementing changes. If you have access to a mysql console, you can also try the query out by doing something like:

SELECT option_name FROM wp_options WHERE option_name LIKE '_transient_timeout%' AND option_value < now();

You’ll want to change “wp_options” if you have a different prefix set for wordpress. Theoretically, that query should show you all your expired transients.

Have fun!