[Resolved] Is codemirror really needed in front-end?

[Author]

Posts

[Valeriia]

Hi,

I'm trying to speed up the site and the main scripts that are slowing it down are from toolset.

For example, as I read in the intro to codemirror.js, I see it is a code editor plugin. Why is it loaded in front end at all?

There are also other scripts, such as select2.js. I did not figure out what you use it for, but is it really needed on every front-end page even if there in no toolset form on it?

Why don't you load scripts only if a related shortcode is used?

Toolset plugins, while being very helpful, are not on friendly terms with Google speed requirements. I already got rid of the Views plugin on many of the websites (recoded every view by hand) and it really helped to get better scores in speed reports.

Can you do something about the the sripts that are loaded with Toolset Forms?

Thank you.

[Waqar Supporter Languages: English (English ) Timezone: Asia/Karachi (GMT+05:00)]

Hi,

Thank you for contacting us and I'd be happy to assist.

I can understand your concerns and we have some internal tickets already to introduce more efficient and targeted front-end loading of scripts and styles in future releases. Although I don't have a time estimate to share the moment, I've added your voice to this matter too.

For now, a workaround can be to use some custom code to dequeue and deregister the unnecessary scripts.

Example:

add_action( 'wp_enqueue_scripts', 'remove_default_scripts', 20 );
 
function remove_default_scripts() {   
    wp_dequeue_script( 'toolset_select2' );
    wp_deregister_script( 'toolset_select2' );
    wp_dequeue_script( 'toolset-codemirror-script' );
    wp_deregister_script( 'toolset-codemirror-script' );
}

The above function will remove the "select2" and "codemirror" scripts from all front-end pages. To make this code remove these scripts only from the specific page(s), you can introduce conditions through WordPress conditional tags:
https://codex.wordpress.org/Conditional_Tags

Tip: You can use the "toolset_add_registered_script" filter in a temporary function to view the handles of all the scripts that are loading:

add_filter( 'toolset_add_registered_script', 'custom_filter_to_view_scripts' );
function custom_filter_to_view_scripts( $scripts ) {
     
    print_r($scripts);
 
    return $scripts;
}

I hope this helps and please let me know if you need any further assistance around this.

regards,
Waqar

[Valeriia]

Hello Waqar,

Thank you, it did the job.

There are a few other Toolset scripts that are still loaded, how do I name them in the function to dequeue them?

These ones:

/cred-frontend-editor/vendor/toolset/toolset-common/utility/js/utils.js
/cred-frontend-editor/vendor/toolset/toolset-common/res/lib/toolset-event-manager/toolset-event-manager.min.js
/cred-frontend-editor/vendor/toolset/toolset-common/toolset-forms/js/main.js
/cred-frontend-editor/vendor/toolset/toolset-common/toolset-forms/js/date.js
/cred-frontend-editor/vendor/toolset/toolset-common/toolset-forms/lib/js/jquery-form-validation/jquery.validate.js
/cred-frontend-editor/vendor/toolset/toolset-common/toolset-forms/lib/js/jquery-form-validation/additional-methods.min.js
/cred-frontend-editor/vendor/toolset/toolset-common/res/lib/knockout/knockout-3.4.0.js

And CSS:

/cred-frontend-editor/vendor/toolset/toolset-common/res/lib/select2/select2.css

The number of them is mind boggling, to be honest... I hope you guys will do a good job on optimization and soon.

[Waqar Supporter Languages: English (English ) Timezone: Asia/Karachi (GMT+05:00)]

Hi,

Thanks for writing back and glad that the code works.

When you'll use the second code snippet from my last message, it will expose the script handles/names which can be used in the first code snippet for other specific script files. But, please be advised that removing these built-in script files can result in broken functionalities and unexpected results.

My recommendation would be to use a good cache and code optimization/minification plugin which can consolidate the script and styles from multiple files into a single file or inline code, instead of removing the built-in script and styles, as it is not future safe and would only become more and more challenging to maintain in a long run, with the plugin's new releases and website's growth.

If you'd still like to remove the "select2" CSS, you can update the code snippet from the last message to:

add_action( 'wp_enqueue_scripts', 'remove_default_scripts', 20 );
  
function remove_default_scripts() {   
    wp_dequeue_script( 'toolset_select2' );
    wp_deregister_script( 'toolset_select2' );
    wp_dequeue_script( 'toolset-codemirror-script' );
    wp_deregister_script( 'toolset-codemirror-script' );

    wp_dequeue_style( 'toolset-select2-css' );
    wp_deregister_style( 'toolset-select2-css' );
}

regards,
Waqar

[Valeriia]

Ah, I did not pay attention to the last part...

I'm using a good cache plugin, even the paid version of it. It does exactly that.

I understand the risk but still think that it's worth removing the scripts on the pages that have no toolset functionalities whatsoever. The less the better.

Thank you, it was very helpful.