A few bad Plugins can seriously taint the perspectives of WordPress users in terms of “more always meaning slower”. You ask someone why their WordPress powered website is bogged down and they’ll be quick to say they have too many active Plugins. More accurately, however, is the fact that they probably just have one or two poorly written Plugins spoiling the bunch.

Here’s a quote from a blog post titled “Takeaways from 2012 WordCamp San Francisco“:

wordpress.com runs over 200 plugins on its site, so stop berating plugins. Well written plugins are seamless and shouldn’t be a burden on your site. wordpress.com aims to serve up each page in less than 500ms, so stop telling people they have too many plugins; tell them they might just have bad plugins.

That pretty much sums it up. A well written Plugin, no matter how many features it offers the end user, should add little “weight” to the website itself and play nice with WordPress as a whole (other Plugins, Themes, etc..). Now in a perfect world that would be reflected in every Plugin, but unfortunately that’s not always the case. And as a result you have this misconception that the bigger the Plugin is on features the heavier it is on your server.

Testing The Genesis Extender Plugin

When writing the code for Genesis Extender I kept a close eye on efficiency. Not only because I do that with every Theme and Plugin I write, but because I knew that it would be properly scrutinized by the Genesis Community. Filled with knowledgable developers, those Genesis devs out there are quick to point out issues with code as they’re keen to protect their Framework of choice from unnecessary bloat.

But having spent several years fine tuning the Catalyst Framework and then more recently creating the Dynamik Website Builder for Genesis users in need of the ultimate “Blank Canvas” Child Theme, it wasn’t hard to port over the techniques necessary to keep Genesis Extender lean, mean and squeaky clean. 🙂

Since the launch of Genesis Extender, I’ve seen a few related discussions where the topic of efficiency has come up, with the concern being based on the idea that more features might mean a slower website.

I know first hand that isn’t the case (not only because I developed the Plugin, but because I use it myself on several websites). However, since I prefer proof over opinion, I figured some tangible test results would be more effective in conveying my clarification of Genesis Extender’s synergy with WordPress, Genesis, and Genesis Child Themes.

The Triple Threat

There are many things that can slow down your website, but the three I focused on in this test were:

  1. Memory Usage (both front-end and in the Dashboard)
  2. Database Hits
  3. Front-end page execution time

My testing environment consisted of a simple shared host, fresh WordPress 3.4.2 installation, two simple Plugins that display the above mentioned stats along with Genesis, the Minimum Child Theme, and the Genesis Extender Plugin.

First and most important, the front-end…

I came up with the following results when loading a sample page using the Minimum Genesis Child Theme, and

the Genesis Extender Plugin deactivated:

  • Database Queries = 27
  • Memory Usage = 22020096 bytes (21mb)
  • Execution Time = .2 seconds (average)

and with the Genesis Extender Plugin active:

  • Database Queries = 27
  • Memory Usage = 22282240 bytes (21.25mb)
  • Execution Time = .2 seconds (average)

As you can see there is virtually zero added weight to your server and database, therefore overall page load times are pretty much untouched.

(Note, the Execution Time is only an average as this value is kind of all over the place in a shared host environment, but since I didn’t see any real differences between the two scenarios I used their rough averages, both being right around .2 seconds)

How Can Genesis Extender Add Such Big Features Without Weighing Down Genesis Powered Websites?

This is achieved with four key concepts and techniques:

  1. Cached Option Arrays: Pretty commonplace in a well coded WP Theme or Plugin, the option arrays in Genesis Extender are coded to cache their values so they don’t keep bothering your server’s database with unnecessary requests.
  2. is_admin WordPress Conditionals: Using the is_admin conditional that WordPress provides allows me to ensure that only the PHP files absolutely necessary for the front-end to function are called in. All other Genesis Extender PHP files are specifically called into the Dashboard page loads and nowhere else.
  3. Flexible Options: The majority of the “Big” options in the Genesis Extender Plugin start off with zero instances, yet offer limitless possibilities. The Custom Conditionals, Widget Areas, and Hook Boxes are all empty options by default, but allow an unlimited number to be added. What this does is ensure that the perfect amount of these features are being implemented at any time. If you don’t use them they’re virtually non-existent. If you use just one or two, then that’s the amount added. If you need 20 or 30, they are there when you need them.
  4. Hard Coded Content: One of the biggest reasons Genesis Extender can offer so much power and flexibility while maintaining a super light footprint, is that the majority of the options are actually hard coded, as if they were being manually written by a professional web developer. This includes the default and custom styles (which are combined and minified as well), the Custom Functions, and the Custom Conditionals, Widget Areas and Hook Boxes.

To provide a real world example of #4 (the Hard Coded Content) let’s look at an instance where a Custom Widget Area is created using the genesis_register_sidebar() function. Let’s say you need to place a Custom Widget Area before your main content area for a specific banner ad, but only on Single Post Pages.

If we were to manually hard code this ourselves we might add something like this to our Child Theme’s functions.php file:

genesis_register_sidebar( array (
	'name' => 'banner_above_content',
	'id' => 'banner_above_content'
) );

add_action( 'genesis_before_content', 'genesis_extender_banner_above_content_widget_area' );
function genesis_extender_banner_above_content_widget_area() {
	if ( is_single() ) {
		genesis_widget_area( 'banner_above_content', $args = array (
			'before' => '<div id="banner_above_content" class="widget-area genesis-extender-widget-area">',
			'after' => '</div>',
			'before_sidebar_hook' => 'genesis_before_banner_above_content_widget_area',
			'after_sidebar_hook' => 'genesis_after_banner_above_content_widget_area'
		) );
	} else {
		return false;
	}
}

And yet the above code was pulled from the hard coded Custom Widget Area files written by the Genesis Extender Plugin.

So the assertion that the only way to maintain efficiency through adding this kind of functionality is by manually hard coding things ourselves, is not accurate.

When a Plugin provides a clean, easy to use interface to add things like Custom Widget Areas and it also writes out the code as if a developer manually implemented the code themselves, then you have a killer combination of both ease of use as well as ultimate efficiency.

So What About The WP Dashboard?

The main concern here is that the Plugin does not take up a bunch of memory in the Dashboard and once again this is not an issue with Genesis Extender. In my test site I found the following results:

  • Without The Genesis Extender Plugin Active: Memory Usage = 26.95mb
  • With The Genesis Extender Plugin Active: Memory Usage = 28.35mb

That’s an added memory weight of 1.4mb. So is that a lot or not?

Well the simple answer is no, not at all, but here’s some additional context to back up that claim…

Years ago, 32mb was the common default or even max memory limit for your run-of-the-mill shared host. So a meg here and a meg there, when you start off pushing past the 20mb point from the start, was crucial. But in the last few years that default limit is 64mb at the very least. So the difference between 27 and 28 megs is negligible at best.

But something I believe will shed even more light on this point, is the test results of a few other popular WP Plugins.

  • Contact Form 7 = memory usage increase of 1.55mb
  • Gravity Forms = memory usage increase of 4.5mb
  • W3 Total Cache = memory usage increase of 3.3mb
  • All-In-One SEO = memory usage increase of .85mb

Now that’s just a few examples, but as you can see a WP Dashboard memory increase of 1.4mb by Genesis Extender is nothing to be concerned about, especially when compared to the added benefits of having it active.

Not Just For The Desperate Non-Coder

The main reason I took the time to test and then type out all this Genesis Extender info was to help ensure proper perspective from potential users of the Plugin. Though Genesis Extender is absolutely a must-have Genesis add-on for the non-coder in need of a kind of “developer in a box”, it’s so much more than that!

It’s an incredibly powerful, yet surprisingly light weight, time saving Plugin that will benefit any Genesis user, whether they know how to code or not, whether they have a big, important project or a small “play” website to knock out, and regardless of your overall skill level or knowledge of WordPress web design.

If you use the Genesis Framework then the Genesis Extender Plugin should be at the top of your list of must-have Plugins…period!