Removing Avada theme bloat

Submitted by hc on Tue, 2015-01-20 09:27
hc's picture

I was a bit nervous when I stumped up my cash for the world’s best selling theme on behalf of a client. I had suggested that often, many options == bloat, and adjusted their expectations accordingly, with respect to performace. In the back of my mind, I was thinking how bad could this be? 100000+ happy customers can’t be wrong? <ahem>

Well the answer is, pretty bad. I’m not going to give you chapter and verse on what’s amiss here, and my experience is only brief, but here are a couple of things that you might be able to do to undo some of the dross.

 image thumbnails frenzy

The site is a WooCommerce shop, and I did an initial import of 100 low res files; admitedly there were a number of dupes imported on subsequent test imports, for a total of 350 source images on disk. At some point, I started a BackupBuddy backup and found the images directory to have a staggering 350MB of images in it. A quick look in there showed me that every image had between 12 and 15 thumbnails generated for it; file sizes for the thumbs exceeded the size of the originals 5-6 to 1.

Thumbnails I have absolutely no need for, for features I’m never going to use, are nonetheless being generated. Here’s some simple code to add to your child theme’s functions.php in order to stop some of this madness:

add_action('init', 'disable_thumbs');
function disable_thumbs(){
remove_image_size('portfolio-full');
remove_image_size('portfolio-one');
remove_image_size('portfolio-two');
remove_image_size('portfolio-three');
remove_image_size('portfolio-four');
remove_image_size('portfolio-five');
remove_image_size('portfolio-six');
remove_image_size('recent-posts');
remove_image_size('recent-works-thumbnail');
}

That’s scrubbed 9 of them - not a bad start. You may be able to remove more. The full list is in Avada’s functions.php (line 151 in v3.7.1). If you’re already sitting on a huge pile of unwanted thumbs, try this fork of the venerable Regenerate Thumbnails plugin that nukes all thumbs first, before recreating them. 

HTML <style> madness

OK, it’s a theme for end-users, not developers, or even designers for that matter. But surely there is a more efficient way to translate admin choices into runtime styles than to inject them as a <style> block in the header on every page load. I’ve measured 64KB, an eye-watering 1800 lines of <style> tag in each and every page, just to translate all those admin panel choices into css. That’s in addition to the 12 other external stylesheets the theme loads. At least my caching plugin of choice can do something with those 12, minify / concatenate them / serve them from elsewhere. But not this chunk. It’s baked into the page.

Strangley, tho, I have no idea what all this <style> content actually does…. I duplicated the header.php from Avada to my child theme, and dropped the hammer on the entire tag, and my home and shop pages seem to load fine. Go figure, the defaults must be being loaded from elsewhere, and look OK? I’ve got to investigate it further, but I’m pretty confident I can drip what styles I need back in over the top, via the child theme’s style.css. And save a chunk of page load on that basis. 

If you’re a dev or designer who’s found an other ways to try to bring this behemoth of a theme under control, please contribute via the comments below.

Drupal theme by Kiwi Themes.