If you manage a website, the load time of your site should be of your utmost concern. While many of us are living in the broadband fast lanes (that’s what the kids call them, right?) this isn’t the case for everyone, and this is especially not the case for anyone trying to browse your site using a mobile device.

Around here we use WordPress, and just as many problems can pop up with WordPress as any other system out there today. There is one building block to our sites that is somewhat unique: Plugins. Other content management systems have their own names for what WordPress Plugins do: some call them modules, others extensions. You get the idea. Plugins give us the ability to add further functionality to our sites. They also can add some nasty speed bumps and (dare I say the word) bloat to our pages that can slow down the load time.

Fortunately there are ways we can take care of this problem ourselves. There are a few methods I’ve found helpful for reducing some of the extra heft that some Plugins generate, and they might be helpful for you, especially if you are running a popular site and are concerned with things like this.

Note: I’m not trying to single out berate any bad development habits or any particular Plugin developers (though there is probably some of that to go around). Even the best Plugins out there can be improved upon, to some extent, with a little user know-how. Most of these tips can’t be taken care of by the Plugin developers themselves, they need to be done by the site owner.

Combine their CSS into yours

This one is probably the easiest. Not all Plugins will require any sort of user-side CSS, though every now and then one will. I’m thinking of contact form Plugins, for instance. When these Plugins load their own CSS styles into your page, odds are they will be causing an extra HTTP request in the header, calling for their own CSS file to be loaded in after yours. This will slow down your page’s load time.

A bit of an explanation may help.

An HTTP request is a way to refer to what happens each time the browser has to go get something from the server where your site is hosted. When your site needs the styles for your page, it gets them. When your site needs the Javascript for a certain piece of functionality on your site, it gets that too. Best practice dictates that these calls, these requests, all happen in the header. If you have a curious eye you can peruse any site’s source and pretty quickly find these references toward the top of the HTML.

While individual calls may not be much on their own, if you have a lot of separate requests going as the page loads, this will definitely put a strain on your user’s browser that (here’s the punch line) is avoidable. By consolidating your Plugins’ CSS into your own, you are limiting the number of requests for CSS files down to one. That’s a nice number, right?

So this is where we actually get to the point of this tip. Each Plugin is different, so it’s a bit tricky to try and offer up an explicit walkthrough that will work for each use case. In general, here’s what you’re going to want to do:

1. Determine what Plugins are calling their own CSS files. Open your rendered page’s source (important that it’s the live version, as Plugin calls won’t display in your templates before being rendered) and look for any calls in the head that you didn’t put there. Mark which Plugins these are from, which shouldn’t be hard to do since most Plugin authors will add comments to what they add to your theme. Good guys, them.
2. Locate the Plugin CSS files, either via the Plugin editor in the Dashboard or, preferably, using an FTP program. The Plugin editor should give you access to everything you need, but if you’re an FTP guy like me (or girl, though then not like me) you will want to use a program. (And honestly, if we’re interested in speeding things up, why wouldn’t we want to speed up WordPress development with an FTP program?)
3. Copy the CSS and add it to your theme’s style.css. I would also suggest you add a comment with a few bits of information: the Plugin belonging to the code you are adding, the date, and your name. Depending on what the site is being used for, your contact information may be pertinent as well.
4. Determine where the Plugin adds the CSS to your site and stop it. This is probably the most difficult of these tips, and will require you spend some time looking over what your Plugin’s PHP file is actually doing (gasp!) and finding where the call to the CSS file is made. You’ll want to kill this request, most likely by deleting a line or two. Wouldn’t hurt to back up the files before you fiddle around in this step.

This is the most effective, and really only, way I know of consolidating Plugin CSS into one place.

Add your Javascript the smart way

Everyone loves using Javascript, but not everyone uses it the right way. To avoid loading Javascript two times (kind of like in the above CSS tip) you can adjust how you link your own Javascript into themes.

When you add Javsacript to a website, odds are that you do it like this:

<script src="http://code.jquery.com/jquery-latest.js" type="text/javascript">

That’s fine with most sites, but in the case of WordPress you can add a call for the popular Javascript frameworks (jQuery, Mootools, and Scriptaculous) using a PHP tag:

<?php wp_enqueue_script('jquery'); ?>

I chose jQuery because it’s my personal favorite.

Why do it this way? Well, the most pertinent reason is because when Plugins are activated they will check with WordPress to see if the framework that it wants to use is already loaded on the page. If you are using this PHP instead of the standard <script> tag, then the Plugin will know and not load it again. Instant win.

Hat tip to WPThoughts for reminding me of just before posting this today.

Clean out your Plugin closet

While we’re on the topic, every now and then it’s good to do a run through of your current Plugin list. In fact, why don’t you do it right now? You have time, you’re reading a blog for goodness sake!

Check each of these points:

• Of the Plugins you have installed, how many are you actively using? This is most important, because if you aren’t using a Plugin but you have it installed, it may be unnecessarily loading up resources that aren’t helpful for your site anymore. It’s nothing against the Plugin, it was clearly useful at one point. But think of it like the coat you have kept around in your closet, even though you haven’t worn it in ages. Just donate it to Goodwill already, it’s wasting space. Except, just deactivate the Plugin. Yeah, don’t try to donate your Plugins.
• Of the Plugins you have installed, and are using, how many do you really need? Let’s jump back to the oh-so-awesome clothes analogy. How many pairs of shoes do you really need? Over on that shelf, all of those hats, do you really wear those? And honestly, the scarves? Okay, this is getting out of hand quickly, but I think you get the idea. What don’t you really need, or what could be handled better with something simple within your theme?
• Of the Plugins you don’t have installed, just delete them. These Plugins don’t really contribute to your site’s download time at all, but why keep them around? Since we’re on the topic of Plugin cleanup, just delete the Plugins from your site completely.

A word or two for Plugin developers

I know this issue is on the forefront of Plugin developers’ minds as well, but just as a reminder: make it easy for users to speed up their sites using these tips. Include information in your readme files about where your CSS files are located, and how to deactivate them. If it’s appropriate, consider having an option on your settings page for completely turning off your Plugin’s CSS. And, of course, check for the user’s Javascript before loading your own.

Did you enjoy this post? Then it might be worth your time to subscribe via RSS using your Feedreader or, if you prefer, via email.