Performance overhead of using plugins and includes in WordPress

Modularity requires additional overhead.  That’s just the way it is.  If you want to semantically separate different components of your web app or theme, you have to include files, run safety checks (e.g., include_once), extend components that you only use 20% of, etc.

WordPress encourages this behaviour, if you have plugins that only effect your admin panel, the files still get included and the actions and filters still get included, the functions are still defined, for every frontend visitor page render — but they are only called into action when you’re on the backend of your site.

And lately when coding for WordPress, I’ve come to embrace and accept that it wants me to be modular and extend.  In fact, during a call with Automattic to discus WordPress VIP hosting, it was suggested to extend the twentyten theme with a child theme as a “best practices” starting point.  Pluggable functions and functions.php files are littered with function_exists() checks.

A colleague of mine sometimes gets persnickety about using one-off plugins to override or append settings (for example, a W3TC plugin that will change the CDN URL depending on what site it being accessed rather than maintaining 2 copies of w3-total-cache-config.php).  Yet the same person agrees with me that different components of a theme that logically fit together should be a plugin, rather than a set of functions within the theme’s functions.php.  If you take a step back, what’s the difference?  Each produces overhead in their own way.

The whole thing reeks of micro-optimization.  If you take a step back to the larger view, WordPress is not a sleek, optimized roadster.  It’s a cargo truck filled with functions that are never called, functions that are meant to be overridden but there for when you want it or need it.  If you fight that, you end up with 1% of your code that’s optimized for loading and 99% with the overhead of a freight train.  It’s just not worth it.

I write my code smart and clean (like everyone, right?), but I when I write it for WordPress — or any existing web app or framework — it’s just not worth it to buck the system.  Write good code that’s appropriate for the application and you will be much happier, and people who come in after you to maintain  your work will be much happier.

Once you’re done debating whether it’s too much overhead to use a function to override a setting vs. including a different file with a settings change, go check out query.php and wp-settings.php.  Case closed.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s