Theme settings tabs are really slow to load

[2Fwebd]

Hi there,

We have some customers complaining about the slowness of the Theme Settings pages.
As we have a lot of options and there is some PHP conditions for some of them and though a lot of JS loaded for the options. It's true that it can take a while as all is loaded in one piece.

Is there any way to deactivate that and have a different page for each tab ? So we don't load all the options but one tab at the time.

Regards,

2F

---

• Tabs lazy load

  Don not render/init all tabs on page load. Render only visible tabs, then init tab on open.

  • on/off parameter for this feature in

    // file: {theme}/framework-customizations/theme/config.php
    
    $cfg['lazy_tabs'] = bool;

• Render all tabs within some DOM elements from javascript:

  fwEvents.trigger('fw:options:init:tabs', {
      $elements: jQuery('.fw-settings-form')
  });

[ghost]

Hello,

I will try to output tabs contents in <div data-tab-html="...."> then in javascript move the attribute value to actual html, doing that for each tab one by one on interval (to prevent load all at once), or if will be possible on tab focus/open. So:

1. Initially the tab will be

   <div data-html="...html..."></div>

2. On focus/open/activate it will become

   <div>...html...</div>

[2Fwebd]

Thank you @moldcraft, that'd be perfect !

[ghost]

Done (on a separated branch)

But there is a problem: Some tabs are "hidden" not rendered, so a lot of inputs are not present in html, and on form submit their values are not sent in POST.

I will try to listen form submit -> prevent it -> render and init all options -> trigger submit from code. That will "block" the page (because, again, all options will be loaded at the same time) then the form will be submitted

[danyj]

their values are not sent in POST

sorry I cant have this, I have predefined styles sent to a file and this will not send the rest of the tabs but only the visible one and the ones user has clicked on

[ghost]

Done -> #1174 (comment)

Please download the latest dev version
https://github.com/ThemeFuse/Unyson/archive/2.5.0.zip
and test if the save works fine

[danyj]

cant to this man , I made bunch of layout and menu visual generator options that depend on options being there , none of them work now, you cant go change this after one year of development. I made options types depending on admin and now many of them dont work right

[ghost]

So I should do an on/off parameter for this feature (enabled by default) ?

[2Fwebd]

Hi,

I'll give it a try now. I think the best way would be to have an option in framework-customizations/theme/config.php

Like : $cfg['settings_form_side_tabs'] = true;

[danyj]

my template generator options is not connected to save but it collects the admin options

var templatedata = $(collection + ' :input').serialize().replace(/fwf=[^\&]+\&/, '');

so if they are not rendered they cant be collected ,

I would love to see speed improvement also but I dont think that this is the right solution.

yes do on/off ( default off) but this leaves many of us that made custom options types depending on admin without an adequate speed solution.

[danyj]

1. what I think the biggest issue is the initialize , you render html in admin, hide it and reinitialize everything via js which kills the speed. It is not noticeable on 10-50 options ,
   but 2F has many as he said and I have 192 , that alone is a killer .
   192 seems much when said but those are a joke inputs fields that again depend on initialize. If admin were not so dependent on js it would fly.
2. the options html is HUGE , for a simple html input we have this
   http://prntscr.com/9m1h4l

where all that can be done with 3 divs and much smaller css class names. But we have a maze of unnecessary html. These are main speed killers.

[danyj]

here , I trimmed down all unnecessary fw-clear ( clear via css after or give those an actual css layout ) 4 per option

Unyson/framework/views/backend-option-design-default.php

Line 119 in bdc4f3a

<div class="fw-clear"></div>

desc and help dont need inner

Unyson/framework/views/backend-option-design-default.php

Line 124 in bdc4f3a

<div class="fw-inner"><?php echo ($option['desc'] ? $option['desc'] : '') ?></div>

Unyson/framework/views/backend-option-design-default.php

Line 114 in bdc4f3a

<div class="fw-inner-option">

look at this
http://prntscr.com/9m1zep
http://prntscr.com/9m1zn5

that cuts 30+KB from 470KB page on 192 options and I did not even touch the tabs and JS

and here is where the mess is

http://prntscr.com/9m20hb

my admin page actually loads in 1.08sec ( used to be 3sec before this #958 )

but the JS ( show options page + initialize ) slows it down another 0.7sec

now I stayed away from all speed killers or I made my own option types to increase the speed, like slider , spinner , typography , the default ones are still killing it especially the slider

[ghost]

Sorry, I designed the html structure bad at beginning.

I can do a html refactor and update all js/css selectors, if users will report/complain that their options or theme scripts used selectors dependent on .fw-backend-option-... > .fw-inner (or similar) classes, we will force them to update their selectors to match the new html structure. Sounds ok? Should I do that?

[danyj]

I dont want to break anyone's html or option that is dependent , but main hooks I used are not inner or the clears so that is why I tested the"fat trim" there.

Trimming the html , setting class names to normal size instead of this http://prntscr.com/9m4w0w and the most important one is letting HTML load without JS dependency since there is no need for it on input, text area , checkbox , radios and all normal form options types is where we should start.

Only options that need initialize are the options that their render depend on JS like slider, switch , multi-picker or typography.

think of this , from my 192 options I count 128 text inputs http://prntscr.com/9m4xpe

, which means there is no need to do js initialize 128 times on admin page. But by default we run initialize on any option type.

So yes I am for refactor but a smart and precise one , not just a new html tree but a carefully picked scan that we know it wont affect anyone.

P.S. Thank you for taking every consideration. It means that we deal with someone who cares.

[ghost]

bb5e98a#diff-9ffd5283b3cfbde20ef300716d226c60R162

[ghost]

@2Fwebd Please let us know if it fixes the slow page load problem

[2Fwebd]

Hi there,

I just tried, it loads pretty fast on my side and the saving is working well. I'll release it to my customer and get back if that doesn't fix it but I think that'll :)

Cheers,

[danyj]

sorry for bringing this back up , can we have a callback after the tabs are loaded so that I can do this

fwEvents.trigger('fw:options:init:tabs', {
    $elements: jQuery('.fw-settings-form')
},function(){
    self.saveTemplate();
});

and this one is for theme settings only right jQuery('.fw-settings-form') ?
what do we use for tabs inside popups ?

[danyj]

Basically I need to trigger the tabs init no matter if theme settings or popup,

so shold I use this instead ?

  $elements:  jQuery('.fw-settings-form, .media-frame-content form')

[ghost]

#1174 (comment)

Unyson/framework/static/js/backend-options.js

Lines 66 to 86 in 61725ae

	/**
	* Sometimes we want to perform some action just when
	* lazy tabs are rendered. It's important in those cases
	* to distinguish regular fw:options:init events from
	* the ones that will render tabs. Passing by this little
	* detail may break some widgets because fw:options:init
	* event may be fired even when tabs are not yet rendered.
	*
	* That's how you can be sure that you'll run a piece
	* of code just when tabs will be arround 100%.
	*
	* fwEvents.on('fw:options:init', function (data) {
	* if (! data.lazyTabsUpdated) {
	* return;
	* }
	*
	* // Do your business
	* });
	*
	*/
	lazyTabsUpdated: true

this one is for theme settings only right jQuery('.fw-settings-form')

Yes, .fw-settings-form is for Theme Settings only

[danyj]

@moldcraft , and one more sorry , is there way to add a hook that will not continue to trigger the init if they are already initiated. Add a class to form maybe fw-tabs-initiated after the init

[ghost]

Sure, nothing is initialized twice, options and containers always add an "initialized" class.

Unyson/framework/static/js/backend-options.js

Line 136 in 61725ae

$tabs.addClass('initialized');

[ghost]

Also to check if lazy tab was initialized or not, check if it has data-fw-tab-html attribute.

[danyj]

@moldcraft what I mean is this , when you click on a button I need all tabs to be initiated before render

        $(self.loadtrigger).on('click', function(e) {
            e.preventDefault();
            fwEvents.trigger('fw:options:init:tabs', {
                $elements: jQuery('.fw-settings-form,.media-frame-content form')
            });
            var templatename = $(this).attr('data-templatename');


            self.renderTemplate(templatename);

        });

now that is triggering every time and I see a lag , like it is initiating tabs every time I click on the button

[ghost]

every time and I see a lag

Maybe because the css selector is slow (it's not by id or by class, it needs to check every element atts)

Unyson/framework/static/js/backend-options.js

Line 91 in 61725ae

var selector = '.fw-options-tab[' + htmlAttrName + ']', $tabs;

Please add here console.log($tabs.length); to see how many elements are selected on button click

[danyj]

OK , this works and it eliminates additional lags, only first one lags a bit ,

            if(!$('.fw-settings-form,.media-frame-content form').hasClass('thz-tabs-init')){
                fwEvents.trigger('fw:options:init:tabs', {
                    $elements: jQuery('.fw-settings-form,.media-frame-content form')
                });
                $('.fw-settings-form,.media-frame-content form').addClass('thz-tabs-init')
            }

testing your suggestion

[danyj]

returns 4 , but without my check it returns it on every click , that is why I meant to add something to form or to tabs itself for check if they are already initiated

[ghost]

I can't reproduce this in my side

[danyj]

@moldcraft you made a button that triggers this

            fwEvents.trigger('fw:options:init:tabs', {
                $elements: jQuery('.fw-settings-form,.media-frame-content form')
            });

?

[ghost]

I execute the code in Console

[danyj]

ok , must be my template render since it is reloading options just like reset theme options does , so tabs are not initiated on reload. This is why a form container class hook works , I am reloading what is inside of the form.

[danyj]

either way , is MUCHHHH faster with lazy_tabs , thnx for the improvement .

[danyj]

@moldcraft , exactly like I said , http://prntscr.com/afxrmc that is after template reload ( the button click ) so re-initiation is a must on next click. No problem , it works either way.