logo

Optimizing Your WordPress Site Pt. 2

Posted by Brett Widmann on Jan 14, 2010 in Planet Label, WordPress | 0 comments
logo

This is the second part of my optimization series for WordPress sites which focuses on what administrators can do in order to speed up load times for the sites they manage. Part 2 focuses exclusively on some of the coding changes I’ve made to a few sites I manage in order to speed up WordPress. Part 1 of the series can be found here.

Code Modifications

One of the great things with nearly any web content management system is its use of themes and templates. In order to make themes and templates simple and easy to use without having to change much of the code, PHP functions are used excessively so that the admin doesn’t have to do much coding (in most cases, no coding at all) in order for the template to work with the system it was designed for. With WordPress for example, simple things such as the site’s title and css file locations are dynamically called using PHP. If you plan on keeping your theme for awhile, or have designed a theme exclusive to your site, much of the dynamic PHP calls that can slow down load times can be eliminated entirely, especially with information from a theme’s header.php file.

For all of the code snippets, Planet Label has allowed me to used code snippets from their blog to use for my examples. Below are snippets of the original code and the changes I made so that less dynamic calls are made to the server.

Site Title

Original Code:

  1. <title><?php if (is_home () )
  2. {
  3. bloginfo(‘name’);
  4. }
  5.  
  6. elseif ( is_category() )
  7. {
  8. single_cat_title(); echo ‘ – ‘ ;
  9. bloginfo(‘name’);
  10. }
  11.  
  12. elseif (is_single() )
  13. {
  14. single_post_title();
  15. }
  16.  
  17. elseif (is_page() )
  18. {
  19. bloginfo(‘name’);
  20. echo ‘: ‘;
  21. single_post_title();
  22. }
  23.  
  24. else
  25. {
  26. wp_title(”,true);
  27. } ?></title>

That seems like a massive amount of code for just the title of a page. Not that I also added additional formatting to make the code appear clearer and easier to read. While code like this may be necessary for dynamically rendering a site name on the fly for any site that installs it, does your site really need it now that it’s installed and that the theme will likely be used for an extended period of time or rotated seasonally? Let’s give the title a little more of a static flair instead.

Static Code

  1. <title>Planet Label Blog</title>

Short, simple, to the point, and one less dynamic request made to the server.

Pingback URL

Original Code

  1. <link rel="pingback" href="<?php bloginfo(‘pingback_url’); ?>" />

As you can see, the link for the pingback URL is also called dynamically in themes. Not sure what a pingback is? Check out the the WordPress Codex.

Static Code

  1. <link rel="pingback" href="/xmlrpc.php"/>

RSS and Atom Feeds

Original Code

  1. <link rel="alternate" type="application/rss+xml" title="<?php printf(__(‘%s RSS Feed’, ‘kubrick’), get_bloginfo(‘name’)); ?>
  2. "href="<?php bloginfo(‘rss2_url’); ?>" />
  3. <link rel="alternate" type="application/atom+xml" title="<?php printf(__(‘%s Atom Feed’, ‘kubrick’), get_bloginfo(‘name’)); ?>
  4. "href="<?php bloginfo(‘atom_url’); ?>" />

So much work for the server when it can be handled like this…

Static Code

  1. <link rel="alternate" type="application/rss+xml" title="Planet Label Blog RSS Feed"
  2. href="http://www.planetlabelblog.com/feed/" />
  3. <link rel="alternate" type="application/atom+xml" title="Planet Label Blog Atom Feed"
  4. href="http://www.planetlabelblog.com/feed/atom/" />

Language Attributes

Original Code

  1. <html xmlns="http://www.w3.org/1999/xhtml" <?php language_attributes(); ?>>

Static Code

  1. <html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="en-US">

Content-Type Attributes

Original Code

  1. <meta http-equiv="Content-Type" content="<?php bloginfo(‘html_type’); ?>; charset=<?php bloginfo(‘charset’); ?>" />

Static Code

  1. <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

JavaScript

Original Code

  1. <script type="text/javascript" src="<?php bloginfo(‘template_url’); ?>/script.js"></script>

Static Code

  1. <script type="text/javascript" src="/wp-content/themes/PlanetLabel2/script.js"></script>

Stylesheets

Original Code

  1. <link rel="stylesheet" href="<?php bloginfo(‘stylesheet_url’); ?>" type="text/css" media="screen" />

Static Code

  1. <link rel="stylesheet" href="/wp-content/themes/PlanetLabel2/style.css" type="text/css" media="screen" />

You’ll notice in some of the examples that making the code static causes more code than the original code snippets. Length of code is essentially something we’re not looking into for the results, but rather the fact that less calls to the server are being made. The less the server has to work, the faster your WordPress site can deliver content to your audience. Furthermore, these changes should be made if you intend on keeping your theme for a long time or rotating it with other themes throughout the year. Finally, if you are designing a theme to release for download, it is imperative that you keep the PHP server requests in the header.php file otherwise chances are good that the theme won’t work for the other person trying to use it. Let them do the tweaking and optimizing. ;)

Are there any other code tweaks that you recommend for speeding up a WordPress site? Feel free to drop a comment with your thoughts, opinions and suggestions. The more the better! Happy coding. :D

Optimizing Your WordPress Site Pt. 1

Posted by Brett Widmann on Jan 12, 2010 in WordPress | 2 comments
logo

WordPress, like many other web content management systems, rely heavily on the use of plugins, libraries, and dynamic server requests using PHP to serve content to its viewers, but with all of the calls to the server, and a massive amount of plugins running on the site, overhead for a simple page load can often times become tremendous. This post is the first part of a two (or maybe more) part series on procedures a person can take to decrease load times for their WordPress install. This post will focus specifically on the plugins I use to keep load times at a minimum for my site.

The Plugins

Plugins serve a wide range of purposes for any developer or designer, whether it is dispatching a tweet whenever content is published, or shifting/restructuring content on a page. While plugins are wonderful and can solve many problems and provide additional functionality, it’s ideal to stick with only plugins that are needed. For example, if you are testing multiple media player plugins for audio files, keep the one media player plugin that you intend on using and delete the rest. If there is a plugin that you intend on using, but haven’t applied it to your site yet, keep the plugin disabled until you use it, otherwise extraneous requests may be made to the server where unnecessary.

On the other side of the spectrum, there are some really neat plugins that can really assist in speeding up load times for WordPress.  Some plugins re-arrange code or optimize the database.  Here are some of the plugins I use for my site:

  • Clean Options – This plugin is great for cleaning up orphaned or unused options and settings that may have been left in the MySQL database.  Use this plugin ONLY if you are proficient with WordPress and MySQL.  I ended up wiping out some options from plugins that I have not used and uninstalled.  PodPress, though, left two empty tables in my database, so I had to go into PHPMyAdmin through my host to delete them manually. I knew they were PodPress related because they contained podpress in the name.  I noticed that this plugin did produce a large amount of false positives for possible orphans, but before deletion, the plugin takes you to a page highlighting the values that are slated for removal.
  • WP-Optimize – For a more robust alternative for Clean Options, this plugin also manages deletion for page/post revisions and comment spam/unapprove clean up.  Thanks for JortK for letting me know about this one! Check out JortK’s post about WP-Optimize here.
  • JavaScript to Footer – A neat and simple little plugin that moves Javascript to the footer.  Here’s a wonderful article from Yahoo about development practices that goes more in depth about why JavaScript should be moved to the bottom or footer of the page.
  • Revision Delete! – I love this plugin because of it’s ease of use and effectiveness.  When people are constantly editing or revising content, that can build up a lot of excess gunk in the database that manages WordPress content.  Pretty soon the database is fill with hundreds of page/post revisions which may cause poor site performance.  This plugin will automatically drop revisions older than the x amount of days an admin sets it to. I have mine set to 2 days, for example.  Less junk and more performance!
  • WP Super Cache – This plugin is ideal for anyone wanting to add a little speed boost to their page because it renders a cached backup of a page as static HTML that is served to viewers of the site.  The plugin is relatively easy to set up and the required .htaccess mods can be written automatically from within the plugin’s settings. There are a multitude of options in regards to what an admin wants to be cached and how often garbage collection and cache deletion is run on the site. This plugin is by far one of my favorites!

Are there any plugins that you use that deserve to be on this list or an upcoming list for speeding up WordPress? Any alternatives that you recommend for the above mentioned plugins? Your input and insights are important to me, so please feel free to leave some comments expressing your experiences with optimizing WordPress using plugins.

Tomorrow’s post will focus on optimizing the header.php file that’s typically included in WordPress themes to increase performance.

logo
Powered by Wordpress. Copyright 2009 Brett Widmann.