Make WordPress Faster With Some Simple Coding Tweaks

WordPress is a great blogging platform in part due to the active developer community creating plugins to extend the functionality of the basic application. If you’re like me you’ve added quite a few. Over time all those plugins can seriously slow down your blog, but there’s some relatively simple coding you can do to help shave precious seconds off the download times of your pages.

As some of you know I’m working on a redesign for this site as part of a move to a new domain. The new site will run entirely on WordPress and I’ve added a number of plugins in the hopes of making the site more useful to visitors and one or two that I simply like. One of the latter is the Lightbox 2 plugin, which I’ll be using to showcase my design portfolio. The plugin made adding lightbox very easy, but it requires three large JavaScript files weighing in at over 65 KB. Since many people visiting the site won’t be visiting my portfolio, there’s no reason to make them wait the 15 or so seconds for those files to download.

Another example is Brian’s Threaded Comments, which is also a great plugin to allow commenters to reply directly to each other. Again I’m very glad I installed it, but if you think about it, the plugin only needs to load it’s JavaScript and CSS on pages where the comment form will be located. The code doesn’t need to be included on your blog’s home page or archive pages for instance.

Solving the Plugin Creep Problem

The fix for Brian’s Threaded Comments plugin was a two part step, which will often be the case with other plugins.

  1. Move javascript and css to external files: Many plugins will have scripts and css styles hard coded into them, which means that code will also be hard coded into the html the browser reads causing the code to be downloaded on every page. Moving scripts and styles to external files will allow your browser to download the code once and then use the cached version.

    Copy the code and place it in it’s own file. Then replace the code in the original file with a link to the new external file.

    1
    
    <script language="javascript" src="path-to-your-plugin-folder/brians-threaded-comments/btc.js" type="text/javascript"></script>

    Note to plugin developers: If you’re adding JavaScript and css to your plugins please take the extra step to externalize the code. It’s not hard or time consuming and it makes your plugin much easier to work with.

  2. Use conditional tags so the external files only load where needed: Moving the code to external files will speed up pages once the files are cached, but they don’t help the first time the file is encountered. That’s perfectly acceptable, but why load all those files before you need them?

    The second step in the process is to control when those external files are first downloaded. In the case of the threaded comments plugin the script and css aren’t needed until you land on a page that accepts comments. In my case that’s only the single post pages. So how to only load the file if the page in question is a single post page?

    Fortunately WordPress makes it easy through conditional tags, specifically the is_single() tag for this case.

    What you’ll do is wrap some simple php that uses the conditional tag around the link to the external file

    1
    2
    3
    
    <?php if(is_single()){ ?>
    <script language="javascript" src="path-to-your-plugin-folder/brians-threaded-comments/btc.js" type="text/javascript"></script>
    <?php } ?>

The above code will test to see if the page in question is a single post and if it is it will call the script. If the page is something other than a post the script won’t be called ensuring the script is not loaded until it’s first needed. It’s similar to conditional comments except here you’re testing for a specific page type within your blog instead of testing for a specific browser or browser version.

There are many other conditional tags such as is_page() and is_category(). You can even test for a specific post or page by adding the id like is_single(97), which would check to see if the page in question is the single post with an id of 97.

With the Lightbox 2 plugin I had to take a similar, but slightly different approach as the page in question isn’t a post or WordPress page. The solution called for a few extra lines of php to test for the current page, though again it was fairly simple.

Time Saved

By moving code to external files and controlling when those files were first downloaded I’ve been able to save about 2/3 of the download time across many pages of the site. The work took less than an hour. Pages that were taking 35+ seconds to download are now down to about 12 seconds. Still slow and I have more work to do in other areas, but a very noticeable reduction in load times as is.

Think about the plugins you’ve installed and ask yourself when the client-side code those plugins use is really necessary. Move the code to external files and keep those files from loading until they’re first needed and you could save significant load times across your site.

While you’re at it give Joost’s post on speeding up WordPress a read for some additional tips on making your blog faster.

Download a free sample from my book, Design Fundamentals.

7 comments

  1. Thanks Joost. I was checking speed reports on the new site last night and saw how many calls to external files were being made and realized most weren’t necessary across the site. The single posts still end up needing to call most of the files, but overall the site will be quicker.

    I always find myself tweaking plugins a little here or there to optimize them. I’m still glad people like you are developing them. Makes my life so much easier.

  2. This sort of post right here is why I’m glad I can yell for you when the mechanics of my blogs go screwy. You understand this stuff. For someone like me, who is still learning, and not real inclined toward the mechanics of how it all works, your help has been invaluable.

  3. Thank you for great article. I just want to add how easily you can measure quickness of your WEB site. If you are familiar with Linux, you can try simple command line utility “ab” – Apache HTTP server benchmarking tool. With -n and -c switch, you can simulate concurrent access to you site and get nice statistics …

    • Thanks Darko. I’m glad you liked the post. Thanks too for the tip. I’m somewhat familiar with Linux, but not too much. I would like to learn Linux better though since I think there are many more things you can do command line.

Leave a Reply

Your email address will not be published.

css.php