Presenting iThemes Builder 3.2. This release is available now in your member area.
This release is a bit special, so I’d like to take a few minutes of your time to talk about it.
As projects get older, they pick up more features, expand in scope, and like many of us humans, put on some extra pounds. With this release, I really wanted to make Builder a lean, mean, fighting machine again. So I dug in deep, benchmarked the code like mad, and trimmed away as much fat as I could. In total, 20% of Builder’s load time and 36% of its memory usage was trimmed off.
While this post will mainly talk about what the efficiency of Builder means to both you as the user and me as the developer, I don’t want to overshadow the other parts of this release.
This release removes both the Billboard and FeedBurner Widget features. Builder customers still get these features as they are now available as separate plugins that you can download in your member area. If you use either of these features, make sure you read my Preparing for Builder 3.2 Release post. But don’t worry, all of your settings will still be there once you install and activate the plugin version of the feature.
Users of the Pods plugin should enjoy this release as Pods now has special support in Builder. Prior to this release, to make Builder and Pods play nicely together, you had to create a pods.php template file in your child theme. No more! Now Builder will automatically use the default Layout on Pods pages. The pods.php template is still supported though, so you can continue to use that if you prefer. In addition, selecting Builder Layouts to use in the Pages setup of Pods is supported in the upcoming 1.12 version of Pods.
For details about the other changes in this version, please read the full release notes.
The short story of the efficiency improvements in this release is that the load time of Builder’s code is reduced by 20% while the memory consumed is reduced by 36%. Not bad if I do say so myself.
If you want more details on what efficiency means, why you should care, and how Builder compares to other themes, please read on.
Efficiency as far as themes are concerned relate to how long it takes for the code to run, how much memory is consumed by the code, and how many database queries are run.
When code takes more time to run, the server the code runs on can handle fewer requests at a time and the page will load more slowly for people visiting your site. Since most people want their sites to handle high-traffic loads (such as when a popular site starts linking to your’s), keeping the load time low is important.
Memory usage doesn’t impact the visitors to your sites directly, but it does affect your hosting. Let’s say that your hosting only allows you to consume 200MB of memory at a time, max, and that your WordPress site takes 35MB of memory to load a single page. In simple terms, that means that you site can handle, at most, 5 people requesting content at the same time before someone either has to wait a bit or your hosting just craps out and refuses to send content to the other visitors. If the total memory consumption on each page load could be lowered to 30MB, your same hosting could now support 6 simultaneous requests. This is an overly-simple way of looking at the importance of being conservative with memory use, but I hope that the point is clear: Having WordPress, your active theme, and active plugins take up as little memory as needed is good for your hosting and your site’s performance.
The number of database queries run on page load is important because for every query run on the database, additional load time and memory consumption is added. Some queries are expensive (high cost of memory, load time, or both) and some are cheap (low memory and load time impact), so finding out how many queries are run is just an indicator of how mindful the developer was of performance and is not a definitive measure of efficiency.
Keeping all of these in mind when developing is important as not all hosting servers are the same. Some have very powerful processors, a huge amount of memory, and very fast databases. On systems like these, improving efficiency typically has very little impact. However, some hosting is slow, dreadfully slow. Since we don’t know where the code will be run, ensuring that our code is as lean and fast as possible means that our code will hold up better on these slower systems and our customers on these slower systems will have faster sites to show for it. A win/win scenario.
So Builder 3.2 is more efficient than the previous release of Builder, how much more efficient is it?
Since comparing Builder against Builder does little to help me understand how Builder compares to other themes, I ran benchmarks with a set of popular themes. If you don’t see your favorite theme in my list, I apologize. I used what I had access to and biased my selections towards themes that are considered to be highly flexible while also including other more simple themes (coding wise) to round out the testing set.
My benchmarks follow. To make the numbers easier to read, I am only showing what each theme added to the total time, memory, and queries used by WordPress itself. So while rending a page with the sandbox theme took a total of .15 seconds, I’m only showing the .024 seconds that sandbox itself added. In addition, rather than showing .024 seconds, I show 24 milliseconds.
You can click on the different headings to sort by that heading. This makes it easy to do specific comparisons.
As you can see, I included four different versions of Builder to see how it fared over time. Builder 2.0 (the last time I focused very heavily on performance improvements) is still the speedy one of the Builder series, and I hope to get it back to its salad days with enough improvements. Given how much more Builder does now though, those days may be out of reach.
Falling consistently at the two-thirds mark for both time and memory, Builder isn’t the fastest of the lot. For me as the developer, knowing what Builder is doing with this time and memory, I’m actually quite pleased with the result.
I also included BuddyPress in the list. This is benchmarking the plugin while running on a completely blank theme, so only the plugin overhead itself is being tested. While BuddyPress is a heavy plugin and most plugins are much lighter on resources, it does add an interesting point of comparison to show how much plugins can add to the overhead of WordPress.
I do want to make sure that I don’t ignite an arms race of performance metrics with themes. I posted these details not because I want Builder to be in the number one slot (it simply wouldn’t be possible for Builder to do what it does and be as fast as TwentyEleven) nor to shame any other developers.
I also want to make sure that users of themes don’t go too crazy over performance of plugins and themes. One theme being faster than another theme doesn’t make it any better. If the slower theme has valuable features, those features typically come at the cost of speed and memory. This is the nature of code.
For users of Builder, I simply wanted to share how important performance is to me and that I’m very serious about making Builder as lean and fast as possible.
For fellow developers, I’ve developed some cool code while doing the performance improvements and benchmarks. I hope to have time this afternoon to start sharing the code I used. If you are interested in how I did anything, please ask in the comments.
For those that just like the chart, I used Google’s Charts API to create it.
I hope everyone enjoys Builder 3.2.