Skip Navigation

[Gelöst] CRED-submission really slow

Dieser Thread wurde gelöst. Hier ist eine Beschreibung des Problems und der Lösung.

Problem: CRED form submission is very slow

Solution: Effectively utilize a caching plugin, upgrade server to a more current PHP and/or MySQL version

Relevant Documentation: N/A

This support ticket is created vor 7 Jahre, 1 Monat. 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.

No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

This topic contains 13 Antworten, has 2 Stimmen.

Last updated by dianaM-4 vor 7 Jahre, 1 Monat.

Assisted by: Christian Cox.

Author
Artikel
#483706

Hi there again!

In one of my projects I'm using a CRED-post-form for guest-requests regarding free rooms of a guesthouse. The form is open for the public, lays in a bootstrap-modal-window and works like expected: After sending the form, a new post is created and two notifications are sent (one to the guest, one to the guesthouse-owner). But sending the form takes way to long:

After clicking the sending-button there is a noticeable delay – guests claimed, that they didn't know, that the form was already sent and clicked it more than once.
After clicking and waiting the page reloads and a blank white page is shown for a few seconds – even though the page should be in the cache by then.
When the page is finally reloaded, the success-message (which isn't on a new page, but is displayed instead of the form) appears in the modal-window (I'm opening the modal by Javascript when the string "success" is in the url-parameter).

I'm working with a few hooks for the CRED-form. For testing, I tried to delete them all. Without any speeding up. So the hooks aren't the problem ... Further more I tried the ajax-option for CRED. Didn't really change anything – it only displays a message, that the form will be send (or something similar) but all the other steps are slowly as before.

I assume, there is a (wanted) delay in the "redirect"? Can I get rid of that?
Or any other hints to solve the time-issues here?

I can provide you a link to a live-site for testing, but would appreciate to send this in a private window.

Please for help! Diana

#483840

Hi Diana, I would like to see the issue on the testing site you mentioned. Can you provide me with a URL to the form, and login information for your WP admin area?

With your permission, I would like to install the Query Monitor plugin so I can see if any excessive queries might be occurring. Would that be okay with you?

#483853

Yes, that would be okay. But please give me a private window for my credentials.

#483856

Private reply enabled here.

#483917
without-params.png
with-params.png
direct-load.png

Thank you Diana, I was able to log in and test a few form submissions. One thing I noticed is that after your form is submitted, a user is redirected to a URL like this:

hidden link

You'll notice that there are several URL parameters here. These parameters bypass your cache plugin, requiring a full server page load. As a test, you can load this URL in your browser directly without using the CRED form. The initial http request takes over 10 seconds for me, and I'm attaching a screenshot of this here (direct-load.png). The white flash you mentioned happens because the page content isn't loaded from the cache, it's coming from the server.

You can also replicate the difference between your cached pages and non-cached pages by adding any other URL parameter. For instance, log out and test the load time of these two pages (screenshots attached):

hidden link (without-params.png)
hidden link (with-params.png)

I'm concerned that this is going to be difficult to optimize because it's not just related to CRED performance, it's related to the performance of your entire site. You may be able to use AJAX form submission to cut down on quite a bit of this load time and the white flash, but triggering your modal success message will be tricky because CRED does not currently provide AJAX callbacks that you could use after a successful post. That would require custom JavaScript that uses a library that can access AJAX events, like jQuery's .ajaxComplete, and isn't fully supported or tested by our team.

What are your thoughts, knowing that URL parameters are going to considerably slow things down?

#484539

Thanks Christian, for your research!

And for your hint, that the site isn't in the cache. I found some settings in CosmetCache to get rid of this problem. There you can set GET-parameters, which should be cached and other ones, which should be ignored. So now the site with the success-message is also in the cache and loading the page doesn't cause a white blank site anymore. Thanks again!

But there is still the first problem: When clicking the sending-button on the form, it takes really long until the form is finally sent. Is that a known and wanted behavior? Or is there any kind of redirect-issue? Or if not, is there at least a way, to disable the button after positive validating the form?

Because you are already into it: Are such heavy loads normal for WordPress-Websites? Or for Websites built with Layouts? I'm not really experienced with that by now.
Or do you have a hint, what is causing the loading problems on my site, when no caching-plugin is enabled?

#484645

Hi, great news that you were able to modify your cache plugin settings to optimize the load time a bit! That should help some. You asked if there is a redirect issue, or if the long delay before the form is sent is a known issue or expected behavior. I don't think so, because if I watch the network traffic there is only one request underway after I click submit. Once that request is finished, the redirect to the page with your success message begins immediately. The delay is just waiting for that submission request to process.

Is it possible to disable the submit button? This is a good idea, but it would require custom JavaScript. One of our certified partners could provide professional help with that if you want. Here is the list of our contractors:
https://toolset.com/consultant/

Are such heavy loads normal for WordPress websites? I think 10 seconds to serve up a page without cache is excessive, and 6 seconds to submit a basic text post is excessive as well. I don't think that Layouts alone should cause that kind of delay, but it's probably a combination of all the plugins you have active and the processing power of your server. You could talk to your host about upgrading your PHP and MySQL versions, which may help.

As a test, you could try temporarily disabling all your other plugins to see if the results improve. Then you could try re-enabling them one at a time to see if there is one specific plugin that causes a noticeable difference. If you can narrow it down to one plugin, you can then examine that plugin for efficiency and conflicts with Layouts or CRED.

#486455

Thanks Christian,
but please give me a few more days to check your suggestions. I'll be back 😉

#486474

Thanks, I'll look forward to your results.

#487462

Hi Christian, I tried a few things in the meanwhile:

You are right, there is one plugin (wp-Typography) that slows down my site pretty much. But when only activating the Toolsets plugins, the slowest page (www.pensionherzog.at/en/our-special-offers/) also takes more than 6 sec to load without cache-plugin – on both of my servers (the live-site and my localhost). Isn't that really slow?

And the big delay after submitting the form also isn't changing, when all other plugins are deactivated. So this delay is caused by CRED? If so, isn't there anything I can do, to speed up this process?

For disabling the sending-button: Is there a CRED-hook or a function, which is called, when a form is evaluated positively? On another form with integrated Bootstrap Validator I did it like that:

$('#myform').validator().on('submit', function (e) {
    // when positively validated:
    if ( !e.isDefaultPrevented() ) { ... };
 });

Is there something like that for the CRED-validator?

#487596

Hi, I just tested that /en/our-special-offers page several times in multiple browsers. It does load quite slowly for me - when I'm logged in. However, if I'm visiting the site as a guest, without logging in, it's quite fast. Are you basing your speed measurements on a logged-in user's experience? This is always going to be slower than a guest, since a lot of admin functionality has to be considered.

Unfortunately there is not a public API available for the CRED form JavaScript validation. Another user had some luck with this approach, but it's not fully tested or supported by our team and I cannot guarantee it will work as expected:

https://toolset.com/forums/topic/validator-add-custom-function-after-validation-but-before-form-submit/

Furthermore, it does not address re-enabling the button if front-end validation passes but back-end validation fails. So it's not a complete solution.

The 6 second delay you mention when submitting the CRED form does seem slow. I can confirm that it is slow even for a user who is not logged in. I would need to install a clone of your site on my local environment to fully evaluate why this process is slow, and if it can be improved substantially. With your permission, I will install the Duplicator plugin and create a clone of your site that I can install locally.

https://wordpress.org/plugins/duplicator/

#487894

Yes, Christian,
please install the duplicator-plugin if you need so (there is a current Backup in Updraft Plus if that helps you also).

The speed of all pages is good when not logged in, because the cache-plugin does a really good job. (And it doesn't work for logged-in users).

But please take a test of the page /en/our-special-offers on your clone, when all plugins – except the Toolset ones – are deactivated. Then the page needs 6 seconds to load. Again, that's the loading time, when only the Toolsets plugins are activated. And this seems really slow to me. Isn't it?

And the delay when submitting the CRED-form doesn't really change, when all other plugins are deactivated.

So I'm looking forward to your tests. Thanks!

#488063
Screen Shot 2017-02-10 at 5.02.15 PM.png
Screen Shot 2017-02-10 at 5.01.50 PM.png

Strange, I'm not able to replicate 6 seconds for page loads or form submissons on my local environment. Loading the /en/our-special-offers page with just Toolset and WPML plugins, my time to first byte (ttfb) is a little over 3 seconds. Submitting the form results in a little over 4 secs ttfb. 3 seconds is a normal ttfb you will see with a CRED form, even in the most optimal conditions.

I am running PHP 7, but even with PHP 5.6 I had similar results. It looks like you're on PHP 5.4, so an upgrade may help a bit. Is it possible to increase your PHP memory limit, or your WordPress memory limit? What about increasing MaxInputVars?

#488731

Thank you very much, Christian!

That really helps me. So if your installation is running that much faster, I assume it's really all about the PHP and mySQL-version. The clients webspace-provider isn't able to upgrade in the next days, but will do so in the next months. I will have a try then. In the meanwhile my cache-plugin does a good job now (after including the site with GET-parameters to the cache).

And your link for "hooking into" the validation of CRED-Forms worked out for me as well. I didn't disable the button after form-submit, instead I'm hiding the button and let a "please be patient"-text appear ...

For everyone who's interested in that, here's the JS:

$('#cred_form_999_1').submit(function(event) {
    if ( $('#cred_form_999_1').valid() ) {
      $("#cred_form_999_1 input[name='form_submit_1']").hide();
      $("#cred_form_793_1 .submitinfo").fadeTo(200,1);
    }
});

Thanks again, Christian. My issue is resolved for now! 🙂

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