Low performance when trying to load many theme_settings via add_setting

  • Hi,

    I’ve got a performance problem in my theme. I like to add MANY functions to change colors, fonts and so on. In this way I need for every option a setting in the $wp_customize array. But adding one setting will take 0.004 – 0.005 seconds (recorded local and not on a webserver). Multiplied by 50-100+ add_settings will cost performance and time of page-loading. In this way I got a warning for “not answering scripts”. Yes, I could extend the time allowed for scripts to take, but this won’t solve my primary performance problem

    Is there any posibility to store this settings in a file or database, so while reloading the page, not every setting have to be recreated? I didn’t find a way to get all settings or to set them all at once. So I couldn’t save it like the defaults for my theme_mods.

    I just found the possibility to add on setting at time via add_setting( $id, $args). Are there any possibilities for caching or something like this?

    Do you have any other suggestions getting a better performance by using many settings in my theme options?

    Thank you

Viewing 2 replies - 1 through 2 (of 2 total)
  • Moderator bcworkz

    (@bcworkz)

    You really need to re-think your user experience. I understand the desire to offer the ability to alter every aspect of a theme, that desire is why I learned to hack WP. Honestly, most users don’t care that much, they just want a nice looking site. In fact, letting most users alter every aspect of your theme will destroy the cohesiveness of your theme’s design. Offering more options is actually a disservice to most users. They are not graphic designers, letting them design their own site through many settings will not end well, even though they got exactly what they want. As non-designers, what users want is not good enough.

    You don’t need to totally get rid of most of your settings, just move them out of the customizer to a traditional settings page. Consider the settings on the traditional page as rarely used “overrides”. If you are familiar with the Firefox browser, you know the most common settings are accessed through the Preferences dialogs, but users can also change hundreds of settings through the quasi hidden about:config dialog. Your theme could do something similar.

    For example, a customizer setting could manage the color of all headings through out the site, except specific headers that have overrides. Most users will be happy to leave the header overrides as “default”, meaning the customizer setting is used. Those so interested can still override a specific header color, all other headers continue to use the customizer settings.

    With a traditional settings page, you can store all the settings in a single array, stored in the DB as a single option value. Instead of making dozens of queries to get the settings, you only do one. Granted, a lot more data needs to be transmitted, but no more than the individual settings added together. One query instead of dozens will save a huge amount of time! To be fair, the Customizer stores settings the same way, but these settings also involve a lot of overhead. By off loading the bulk of settings outside the Customizer, this overhead is reduced.

    Another inefficiency is the customizer CSS is output in the head section to override any defaults from style.css. By moving little used settings outside the customizer, you can manage the CSS with a dynamic CSS page where the CSS file content is generated on the fly with PHP. The browser gets the proper CSS the first time without a bunch of overriding CSS in the head section.

    This approach will not help refresh speeds in the customizer, in fact, it may be worse. You will also spend more time writing code to work the external settings into the customizer preview, not to mention writing code to manage the external settings themselves. However, the load speed of regular page requests will be much faster.

    Thread Starter eluin

    (@eluin)

    I think you’re right. The idea with overrides for example to colorize links for specific sections in other ways, will be better and more neatly arranged.
    At the moment I’m generating a dynamic css-file – works fine and I think I can redeclare it to usw it with such an options page.

    Thank you for your help. I hoped there would be an other solution, but I didn’t found any, so I thought about discarding the whole projekt. But your idea is great. Thanks.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Low performance when trying to load many theme_settings via add_setting’ is closed to new replies.