Viewing 19 posts - 1 through 19 (of 19 total)
  • Author
  • #961501


    We’re having into some issues with the server on our site running Enfold.

    The issue is our wp_options table with autoload = yes rows is over 3MB.

    Hundreds of thousands of these autoload yes rows are from Avia Builder. These are the results of the query with number of rows per key:

    355000 aviaAsset_css_filecontent
    92754 aviaAsset_js_filecontent
    34933 av_alb_usage_av_textblock
    32707 av_alb_usage_av_heading
    32547 av_alb_usage_av_one_third
    32493 av_alb_usage_av_two_third
    32492 av_alb_usage_av_video
    11611 avia_options_enfold_child

    Could you offer some guidance as to which rows are needed and which are old, deprecated or can be removed?

    Thank you


    Hey SCMHR_HomeOffice,

    Here is an article for you

    If you need further assistance please let us know.
    Best regards,


    Hi Victoria,

    That is a great article, one that I’m familiar with. I am not asking how to delete rows in the db.
    I’m asking specifically about the thousands of autoload yes options added by Enfold to the db.
    My question to you guys as developers of Enfold is if we can delete these or if doing so will cause issues, visible or otherwise, in our site?


    Hi again,

    My apologies, I was misunderstanding our problem. My question is now limited to just a yes or no answer to the question:

    Can I expect functionality issues from setting the following wp_options registries to autoload = no?:


    Thank you


    Hi SCMHR_HomeOffice,

    I asked my colleagues for their input.

    Best regards,



    Thank you for using Enfold.

    av_alb_usage_ is needed when using Performance -> Disabling of template builder elements -> Load only used elements.

    Not sure, why you have so many entries – actually there should be only one for each ALB element.

    You can set it to “no” and check, if it has a negative effect on page loading speed. From functionality it should not make any problems if the options are loaded seperatly when needed.

    Best regards,


    Thank you Günter.


    Hi SCMHR_HomeOffice,

    Glad you got it working for you! :)

    If you need further assistance please let us know.

    Best regards,


    You may close this thread, thank you!


    Is it OK to delet aviaAsset_css_filecontent and aviaAsset_js_filecontent?



    Yes it is OK, do it and let us know!

    Best regards,


    I deleted them but they are coming back. Is it because I enable the compression of css and js?


    Hi debra15,

    Yes, they are regenerated when you enable compression.

    Best regards,


    While optimizing site speed I ran into the same issue. Enfold by far is the biggest wp_options polluter, resulting in a size of 4.6MB !

    The css and js data should NOT be stored in wp_options, it’s not designed for that and slows everything down. A quote from a database specialist:

    When a WordPress page loads, it runs this query every single time:

    SELECT * FROM wp_options WHERE autoload = ‘yes’
    If the wp_options table is larger than 1MB in size this query results in rather heavy database use, which means you should try to clean up the wp_options table.

    To find the rows with the largest amount of data in the option_value field, use the query:

    SELECT option_name, length(option_value) FROM wp_options WHERE autoload=’yes’ ORDER BY length(option_value) DESC LIMIT 30
    If you find plugins that are polluting the options table with unnecessarily large rows, we recommend you to file a bug report with the plugin’s author.

    Tip #4



    Thanks for the info.

    The database entries where the theme stores the compressed css and js code are not required every time a page is loaded. They are only fetched if the merge scripts or stylsheets do not exist or have to be regenerated. You can install the Query Monitor plugin to confirm that.

    Best regards,


    Thanks but I would still prefer a smaller wp_options table. Seems more appropriate to have its own table.



    Thanks for the update. We’ll forward it to our developers.

    Best regards,


    @Ismael, what is the progress with this. If your wordpress developers haven’t replied by now, and there isn’t a fix in place, then they do not know what they are doing. ezFl0w is completely correct.

    This is a serious issue, the wp_options table should not be used for this sort of purpose.

    • This reply was modified 3 years, 7 months ago by Michael.

    Hi smartstartinc,

    Enfold 4.7.4 has an option to disable the unique timestamp generation for the css and JavaScript merged files and so there will not be as many entries it the wp_options table.

    Here is where it can be found:
    Image 2020-05-04 at 19.48.07.png

    Best regards,

Viewing 19 posts - 1 through 19 (of 19 total)
  • You must be logged in to reply to this topic.