CSS & JS Compilers

Last Update: February 28, 2024

The CSS Compiler is a great way to optimize the CSS styles which are dynamically generated from the various option settings on your site. This is done by compiling the styles into one file for each page/post, providing a performance boost. The JS compiler is mainly for debugging purposes and should remain enabled on your site. Please continue reading below to learn more about the JS & CSS Compiler.

Dynamic CSS & JS Options

What Is The CSS Compiler?

When the CSS Compiler is disabled, each option which relates to the page / post being loaded is processed by your server and the styles are all compiled into a single stylesheet which is loaded in the page through the <head> tag. Since these styles can change based on your settings, they’re referred to as “Dynamic CSS” styles. The processing of each option into a compiled stylesheet happens on each page load which requires more work for the server. The CSS Compiler can be enabled, for increased efficiency.

Explanation of Each Compiler Method

The CSS Compiler will save the work the server did when compiling the options into a stylesheet so it doesn’t have to be repeated each page load. There are two methods of storing the Dynamic CSS which you can choose from or Disabled. Just select the method of your choice and save the Global Options.

  • File – When you enable the File compiling method, your styles will be saved as a .css file for the page/post it relates to. This file will be stored in wp-content/uploads/avada-styles and loaded when the page is loaded again. This saves the server the work of having to process your site’s settings on each page load. This will remove Avada styling from loading in thetag. Note: This file will automatically be regenerated when you update your settings. If you have a caching plugin or server cache on your site, you should clear your cache to ensure your changes are loaded.

  • Database – The Database method will save the compiled CSS in the database instead of as a file. The styles will be loaded in thetag as inline styles for this method as apposed to a .css file as with the File method. This method can increase your database size considerably if you have a large site. For  sites with 20-30 pages, this won’t be a problem. However, if you update your website regularly with new content and posts (for example 10K+ blog and portfolio posts), using the Database method is not recommended.
  • Disabled – When the Compiler is disabled, it will not save the styles in any way. Each setting will be compiled anew into Dynamic CSS and loaded through thetag as inline styling. This is the least efficient method.

Page Source Without CSS Compiler

Uncompiled CSS

Page Source With CSS Compiler

CSS Compile

The JS Compiler

The JS compiler (JavaScript Compiler) will be enabled by default. This will combine individual Avada related JS files into a single loadable file. This improves efficiency in page load times. Disabling the JS compiler will load the individual and unminified JS files.

Enable JS Compiler

Reset Avada Caches

This button will allow you to reset all the Avada related compiled styles, compiled JS files and cleans up the database of any saved styling related entries. This normally happens automatically on your site when updating the theme or other actions like saving a page, your global options, etc. However, you can use this button to manually clear your compiled styles, if you are uploading theme files via FTP or you notice your global options not applying changes or odd behavior along the lines of your changes not taking effect.

Note: This won’t delete your settings or change your site appearance. It only affects compiled files which are a “saved” version of your settings. This won’t change your actual settings or affect them in any way.

Reset Fusion Caches

Important Note About Server Cache

For unique cases where you are using cloud flare and a cache server, like varnish cache, enter your cache server IP to clear the Global Options Dynamic CSS cache. If you do not do this you may not see your changes instantly on refresh. Consult with your server admin to find out your server IP address.

Cache Server IP

Load Media-Queries Files Asynchronously

Another option that can improve performance on mobile and desktop is the Load Media-Queries Files Asynchronously which is available only in Avada version 5.6 or higher. This option can be found in Avada > Options > Advanced > Dynamic CSS & JS. Let’s have some examples below.

Example 1:

Copy to Clipboard

Example 2:

Copy to Clipboard

The browser gets the HTML, and then it starts loading all the assets. When it sees Example 1, it stops, gets the file, and when the file is loaded then it continues parsing the rest of the document. If it finds another stylesheet like Example 1, it stops again, gets that file, and once done then it continues with the rest of the document. That’s what is called a “render-blocking stylesheet” and is usually something that should be avoided for performance.

However when the browser sees Example 2, it doesn’t stop. It downloads the file in the background while it loads the rest of the page. If the user’s screen-size is a minimum of 700px, then it applies the styles contained in it.

In Avada 5.6, we split a lot of CSS and created separate stylesheets, 1 for each media-query. The main stylesheet is still render-blocking, but since its size got reduced it can load faster, while all styles that depend on the screen-size are now not render-blocking. They get downloaded all at the same time (so faster), and the browser then applies them.

When you set Load Media-Queries Files Asynchronously option to OFF, all media-queries are compiled inside the main CSS file – just like it works in previous versions. If set to ON, then they are separate files. The main compiled CSS file is smaller in size, and all media-queries are loaded asynchronously.

Load Media-Queries Files Asynchronously

In this article