Avada Forums Community Forum AVADA’s Huge Performance Problem

Viewing 15 posts - 46 through 60 (of 138 total)
  • Author
  • Jetxpert-Envato
    Post count: 339

    Note to Moderator: Please lift previous post restriction (reply to @benjaminblue). My recent post included 5 URL links (?). I believe your restriction is set to 3 URL links max. Thank you.

    Post count: 4

    I completely agree, JetExpert!

    My team (and many others) would be totally fine if the only update done in the next 3-6 months was a major overhaul on performance, and the ability to score 85+ on Google PageSpeed, Pingdom, etc right out of the box.

    In the meantime, here’s a solution to de-register scripts that are not being used in the theme. This requires a Child Theme and coding knowledge:


    Also, this recommendation is very handy:


    Post count: 3

    Thanks for the great information shared in this post.

    I agree that Avada is bloated and could do with a performance focused release. We don’t need new Avada features or new look demos – for now we need faster loading Avada websites.

    This thread is very relevant to an Australian based Avada / WooCommerce site that I have recently moved to SiteGround. We are currently using a combo of WP Rocket (long time user), SG Optimizer (SiteGround’s caching plugin, new user of this) and the Avada Performance settings to improve performace.

    Pingdom (Pacific – Australia – Sydney) returns 91 for our site but tests in GT Metrix (Vancouver, Canada) are not so good. The main issues reported in GT Metrix are shown below, none of which I think we can control??:

    • Avoid an excessive DOM size (1340 elements)
    • Avoid Long-Main thread tasks
    • Avoid document.write()

    Couple of questions…

    1. Is there a way to easily avoid an excessive DOM size when using Avada?

    2. Is there any point in also using the Avada Performance settings in conjunction with WP Rocket (and/or SG Optimizer) or do you recommend disabling the Avada Performance settings (as much as can be done anyway)?
    eg do the Avada Performance settings help when also using a caching plugin?

    3. Is there any caching / speed benefit in using “Progressive Web App” in the Avada Perfomance settings?

    Thanks and all the best.

    Post count: 3

    Avoid document.write() was my footer call in the settings – fixed this one 🙂

    Post count: 339


    In response:

    (1) Is there a way to easily avoid an excessive DOM size when using Avada?

    No. Not to our knowledge.

    (2) Is there any point in also using the Avada Performance settings in conjunction with WP Rocket (and/or SG Optimizer) or do you recommend disabling the Avada Performance settings (as much as can be done anyway)?
    eg do the Avada Performance settings help when also using a caching plugin?

    Yes, we recommend using the best features of Avada, SG Optimizer, and WP Rocket. Perfmatters (paid plugin, worth every penny) is great as well. Just make sure your selections (settings) do not overlap. We have determined that it’s best to use the performance-enhancing features of Avada and WP Rocket, not SG Optimizer (we use only its caching features). As you already know, each website is different, so experimenting with the features of each plugin, etc. is highly recommended.

    For example, in our case, we have learned that the Lazyloading feature of Perfmatters (plugin) is faster, better, and lighter than Avada’s, SG Optimizer’s, and WP Rocket’s. If you choose not to buy/use Perfmatters, our second choice would be WP Rocket.

    (3) Is there any caching / speed benefit in using “Progressive Web App” in the Avada Perfomance settings?

    We do not use PWA. We tried it, but it slowed down our website by introducing (loading) unwanted or unnecessary assets. Some folks have said they like it and has helped them. Not us.

    Hope the above helps.


    Post count: 3

    Thanks for the expert input and advice @Jetxpert-Envato. Much appreciated.

    Roger that on 2 and 3. I have tweaked a few things relevant to 2 and uninstalled the PWA plugin (which just added more plugin bloat anyway).

    In running Avada Performance settings and WP Rocket, with just caching features on in SG Optimizer, and Cloudflare enabled through SG Hosting Control Panel, the site performs worse for us in Pingdom. Have reverted back to more SG Optimizer than WP Rocket for now (perhaps this suits the hosting setup in this instance?) and will keep checking randomly over the next few days.

    (1) Is there a way to easily avoid when using Avada?
    “No. Not to our knowledge.”
    Bummer on the excessive DOM size – thought that might be the case given Avada’s size but was worth asking. We remain continually challenged in GT Metrix on this project then… doh 🙂

    Cheers again and all the best.

    Post count: 1

    Thanks guys for all the important info that has been shared.
    I am a long term Avada user and have built many sites with it, but now thinking of bailing and going over to Divi…

    I just ran Themefusion’s own site and then Divi site http://www.elegantthemes.com
    through GTMetrix…

    Avada – http://www.Themefusion.com = F rating, performance 33%!(this is like my own site and Avada 7.1 without any content)

    Divi – http://www.Elegantthemes.com = B rating, performance 87%

    If Themefusion can’t make their own site fast enough to get out of the gutter then how can I?

    Does anyone have an Avada site using WPRocket, Cloudflare, etc…that is anywhere close to a B rating or above?

    Thanks! Do NOT want to leave Avada, but feel like I have to unless something changes…

    Post count: 339


    You tested the wrong website. The correct website is theme-fusion.com (not themefusion.com).

    Avada is getting better over time. Their recent release V7.2 is working great for us. The key to making your website faster is to follow the guidelines provided above – which include several provided by Theme Fusion.

    Our website relies on Perfmatters, SG Optimizer, WP Rocket, and Cloudflare (Pro Plan). It’s performing great. We only use webpagetest.org and Google Lighthouse for testing our website. We do not like GTMetrix nor Pingdom.

    A website is only as good as its design (not Theme alone), host server (shared, private, or VPN), website demand, number of plugins and snippets used, CDN used, image/video size and types, and a few other items. So, not until you’ve trimmed the “fat” from all of these players, you may still end up with a slow website.

    If you take the time to read the previous posts, you’ll find useful information that will help speed up your site.


    Post count: 3


    “Does anyone have an Avada site using WPRocket, Cloudflare, etc…that is anywhere close to a B rating or above?”

    I have such a site, which is rated B at GT-Metrix. It was created with Avada, WP-Rocket in use. GT Metrix rates the homepage with a B (79% performance). A post page with a few photos is also rated B (81% performance). A post page with a lot of photos is rated C (75% performance).

    The load time (Pingdom) is between 800 and 900 ms (Server: Frankfurt, Germany).

    It is possible, but a lot of work. Test and try out a lot to get the result.

    Michael C
    Post count: 532


    You are obviously free to switch over to Divi if that is what you want. However, I do want to point out a few things to keep you on board with Avada:

    1. If you Google for performance complaints, you will find the same complaints regarding other themes. There is no doubt some themes and builders are more performant than others, but it is also a case of setting things up correctly and knowing how to serve a faster site. It is also about managing expectations, especially when you are comparing to an AMP version of another site on mobile.

    2. The URL used in the comparison is not ours. However even if you are comparing, using the main company site or main live demo homepage is not a great representation of an average Avada site. Right now our company site has over 230k users and many added features beyond the normal – which add up to a heavier page load. This also serves as a good example of the setup aspect mentioned in 1. If I take our financial advisor site as an example, I get the following in GTmetrix:

    That also includes some of the extra things we add for the live sites such as the demo selector. The reason for this one scoring better is due to the setup. I will provide some tips at the end.

    3. We are committed to improving Avada. We have a page here to get feedback on what should be our priority https://theme-fusion.com/feature-voting/. We are aware of that and will be improving performance. However, unlike other release types – updating for performance requires a lot of planning and needs a strong structure to be in place before we dive in. But rest assured, we are definitely going to be tackling this. In 7.2 we also did make various performance improvements and steps for the future.


    Michael C
    Post count: 532

    Following on from that message, here are some general tips. Split up depending on the stage of the process:

    Content – building the content

    • Less is more sometimes. The more elements/content the page contains, the higher the node count. The more that needs to be rendered. This is the excessive DOM count that is referenced in tests.
    • Avoid an above the fold slider unless important to the design. If you want a large hero image, better to use a static image as a background. If using a slider, the slide is JS driven and needs to wait for the rest of the document to be ready before fully rendering. This will decrease page load scores.
    • Avoid very large images. Large in dimensions and large in file size. Obviously images are important to a website but ensure the choices make sense and are optimized. Clever use of background colors, gradients and lightweight SVGs can often make a big impact for less.
    • Avoid animations above the fold. For the same reason as the slider. Using further down the page is fine, but you want the initially viewable area to be quick and stable (no movement) when loading.
    • If you have a choice between a column background image or an image element (to accomplish the same thing) – use an image element. Responsive capability is superior and loading will be quicker
    • Use layout sections for each area. This is not vital, nor hugely impactful right now, but it may be in the future. When layout sections are used for each aspect of the site (header, page title bar, footer, content) we have more knowledge about what needs to render and therefore assets can be made more efficient.
    • Avoid embeds unless necessary. For example, embedding a third party form or serving multiple YouTube videos on your homepage. Not only do you have to wait for them to load, they often bring with them extra assets which might not even be required. For forms for example, best to use the Avada Forms where possible. For videos you might want to have them on a separate page, or load it within a lightbox instead of on page load.
    • Be selective about your extra plugins. More plugins = more assets being loaded. Also not always optimized to take into account what is already being loaded
    • Create your own custom icon set and disable Font Awesome. If you only plan to use a select number of icons then try out the Avada icons feature and create your own lightweight icon set. Alternatively, if you do still want to use Font Awesome, disable the subsets you aren’t using in Global Options – Theme Features)
    • If you are adding custom CSS in a child theme., chances are you would actually be better to add to the global options custom CSS. This will vary but usually the child theme CSS is loaded separately as part of another request, whereas the global options custom CSS is compiled into the main file with the rest

    Performance Tab – find the ideal option combination (not the same for everybody)

    • Lazy Loading – Avada (or a plugin, but Avada’s will ensure carousel and other areas work properly)
    • Font Face Rendering – Swap Non-Icons (you can also use swap all, but it is a balance)
    • Preload Key Fonts (7.2) – Icon Fonts or All
    • Emojis Script – Disable, unless you need it (comment area)
    • Load Stylesheets In Footer – Off. The page shift is usually not worth it, but you might want to ty it first.
    • CSS Compiling Method – File. Only use database if you must, only use disabled if you are actively working on the site and debugging.
    • Load Media-Queries Files Asynchronously – Off. Try it out first, but usually the scores will be worse
    • Enable CSS Variables – Either, but On will be fine as default.
    • Enable JS Compiler – On. With an HTTP2 server it might be debatable but even then more often than not it works faster being on.
    • Enable Progressive Web App – Either. Its unlikely to improve first page load, therefore speed tests wont pick up on why its good. However, for page loads after the first the PWA should improve speed a lot. So it can be nice to enable

    Avada Optimization – turning off what you don’t need

    • Turn off Elastic Slider unless you need it (unlikely)
    • Turn off post types you aren’t using (slider, portfolio, FAQ, icons). New to 7.2.
    • Turn off the FontAwesome subsets you don’t need
    • Font Awesome v4 Compatibility – Off
    • Smooth Scrolling – Off
    • Load Frontend Block Styles – Off (unless needed)
    • API scripts (YouTube, Google) Off unless you are using.
    • Disable elements you don’t use in Avada – Builder Options. This will save a little bit of CSS, but overall will be minimal impact in 7.2 since we have improved the JS loading

    Extra Optimization – caching, minification, server

    • Ensure you are up to date with PHP. If your host isn’t providing recent versions of PHP you may way to consider switching elsewhere. Newer PHP versions are more performant and will improve server response.
    • Good quality hosting that is suited to WordPress. Will improve server response time.
    • Cache. There are so many options here and different setups. You can have a cache plugin like WP Rocket, super cache etc. Also there is cache offered by hosts. There is loads of information out there on the subject. Just remember, the more cache the more you need to clear and check at update time.
    • Minification. You can use a plugin to improve minification. However beware, you will not always get positive results and like caching you can end up causing problems.
    • Experimentation. Especially with performance plugins, its good to give them a test and find the winning formula for your setup.


    • Load the page yourself before testing. This is important if you are changing global options and then testing straight away to find the best score. Eg, say you enable a cache plugin and then set GTmetrix to test the URL straight away. The page will not be cached by the plugin yet and therefore you won’t actually be seeing the valid result. Best to visit the page yourself first (just a simple page load in your browse) then test.
    • Google Page Speed. Faster to do than using the website, you can use the lighthouse feature in Chrome developer tools. https://developers.google.com/web/tools/lighthouse

    This is by no means exhaustive, but gives you a general outline of various things to try and to take into account when building. Also as mentioned, Avada is every evolving, so in the coming updates some of these suggestions may change.


    Post count: 339


    My last post (replying to yours), contained a small error. This is the correct website to look at. Should load fast at your end considering it uses Avada’s sliders. We’ll probably replace them with a single, compressed image.


    Post count: 339


    Excellent info. Thank you.

    A couple of things …

    (1) Would be great if Theme-Fusion can capture what you shared and integrate it into a blog and/or Avada’s documentation.

    (2) When is Theme-Fusion going to start the Development Phase of Performance Refactor? It received at least 425 more votes than WooCommerce Builder.


    Michael C
    Post count: 532

    1. Is likely but my list was certainly not exhaustive and performance setups do vary. We do have documentation already regarding performance and they are ever evolving. It is likely we will write up a proper optimization guide, but good guides take time (a lot more so than went into my post).

    2. The WooCommerce builder had already started by the time that page went live. As such, it is not entirely reflective to simply say it has a higher number, why aren’t we doing that now. If Woo was not already listed as in development it may have received more upvotes. Additionally, we had obviously already started development before that page went live. Finally, like I have mentioned in a number of places, performance refactoring is a lot different in terms of process. Things need to be done in a specific order in order for them to make sense. No use doing something then later having to re-do it again. The scope for update issues is also a lot higher with anything which involves refactoring.

    In terms of timeline I can’t give anything specific there because it depends what comes up. I can say that the current plan is to move onto performance refactoring after Woo is complete. When that is decided, the status on that page will be updated accordingly.


    Post count: 8


    Regarding css performance, is there any benefit in defining custom css locally in each page, in the child theme via Appearance > Theme Editor or in Avada > Global Options > custom css?

    None of my custom css is shared across pages but currently I have it defined in Appearance > Theme Editor so it is easier to make multiple modifications in one go.

    Thanks for the advice.

Viewing 15 posts - 46 through 60 (of 138 total)
  • You must be logged in to reply to this topic.