Skip Navigation

[Resolved] CRED intensely slows down the backend!

This support ticket is created 6 years, 7 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Our next available supporter will start replying to tickets in about 1.10 hours from now. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 12:00 9:00 – 12:00 9:00 – 12:00 9:00 – 12:00 9:00 – 12:00 -
- 13:00 – 18:00 13:00 – 18:00 13:00 – 18:00 14:00 – 18:00 13:00 – 18:00 -

Supporter timezone: America/Jamaica (GMT-05:00)

Tagged: 

This topic contains 22 replies, has 2 voices.

Last updated by Shane 6 years, 6 months ago.

Assisted by: Shane.

Author
Posts
#576967

Shane
Supporter

Languages: English (English )

Timezone: America/Jamaica (GMT-05:00)

Hi Herre,

I want to change the server environment of the site. Would it be possible to install the duplicator plugin for me so that I can get a clone of the site.

Thanks,
Shane

#576979

Hi Shane,
Done... by the way... your account is a super admin account... so feel free to add or remove items. Its a test site pure for this issue.. so it's no issue at all if things change or get lost.

Best regards,
Herre

#577417

Shane
Supporter

Languages: English (English )

Timezone: America/Jamaica (GMT-05:00)

Hi Herre,

I've provided our 2nd tier supporters with the duplicator package to test this and debug further.

Thanks,
Shane

#580264

Shane
Supporter

Languages: English (English )

Timezone: America/Jamaica (GMT-05:00)

Hi Herre,

I've got some good news and bad news.

The good news is that the issue is not related to CRED at all. The bad news is that it is with our Types WYSIWYG field.

It seems that when you have quite a number of these fields on the same page it dramatically slows down the page loading so we are suggesting that our developers find some way to improve this.

Nothing else we can do here except to reduce the amount of WYSIWYG editors on the page .

Thanks,
Shane

#580556

Hi Shane,
thank you for your update so far...

I am aware that the more WYSIWYG editors, it slows down the backend....

BUT....

could you please inform at the developers and give an explanation why the page gets slowed down even more when CRED is active?

I don't have a satisfied feeling that they say it isn't CRED at all... I for sure know that the WYSIWYG editors slow down the page on the backend. Has been the fact for all four years i've been using Toolset now.
BUT what I don't get is... the slowdown increases at least 2 times when CRED is active! There somehow needs to be a connection... or try to explain to me why there shouldn't be a connection.

I already communicated the conclusion it had to do with the custom fields on the 27th of September:
==== quote ====
Next I disabled the post fields group linked to pates, therefore pages didn't have a toolset post type taxonomy or anything linked to it.
--> loading time with CRED enabled: +/-9sec
--> loading time without CRED: +/-9sec

So no noticeable difference with CRED enabled or disabled and a tripled increase in loading speed!!!

So somehow the custom post fields to have a huge impact on loading speed of the backend of the page. And when CRED has been enabled this increases with approx 30 seconds.

==== end quote ====

Best regards,
Herre

#580707

Shane
Supporter

Languages: English (English )

Timezone: America/Jamaica (GMT-05:00)

Hi Herre,

Based on the analysis done, it could be that the button from CRED loading onto the editors. Removing CRED removes the CRED form button from all the WYSIWYG editors and this could be why you are seeing some improvements in page load times.

However the root issue is the WYSIWYG fields and not CRED itself.

Thanks,
Shane

#581410

QUOUTE: this could be why you are seeing some improvements in page load times.

Well it's not SOME improvements... its around 50% ... looks like thw hook for adding the button and the WYSIWYG editors are real resource killers...

For this website I don't have time to switch the whole design, for new ones I will see if it also happens when using a Parent Child Post type configuration...

Will the new Types make it possible to set a max amount of child posts for a post? This is why we used this setup... we don;t want the end user adding more and more... so we choose a max of 10 CTA boxes... I can design it in such a way the CTAs are saved as Custom Post, but not sure if I can set a max childs per post and if that would solve the loading on the backend. As the Child posts do also contain those fields.

Any ideas?

#582845

Shane
Supporter

Languages: English (English )

Timezone: America/Jamaica (GMT-05:00)

Hi Herre,

I do as well suspect that the buttons are causing the problem since each button will be added to each WYSIWYG. I suggested this as an improvement to our development team.

Currently there isn't a way to limit the number of child posts per post.

Thanks,
Shane

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.