Why is the Place Order action slow?

Hey, I installed magento 2.3, the other pages load fast enough but the checkout payment page loads extremely slow.

I have enabled cache, changed mode to production, disable and enabled payment methods, redeployed static files, changed the themes but the checkout page is still very slow

Has someone come across this, Is there a solution?

There’s currently quite a few complaints that the Magento 2 Checkout experience is quite slow. I think it’s something they’re working on. Frontend Optimisation isn’t great and I think this is why Magento/Adobe are working so hard on their PWA Development Kit which will eventually replace the technology used for the Frontend.

But obviously the term “slow” is relative, so are you talking 3-5 seconds, 20-40 seconds or 60+ seconds?

Thanks @digitalstartup . it is extremely slow, it take 60 + seconds

Yeah, that’s definitely longer than I would expect. If your site is public, I can take a very quick look and see if there is anything obvious on the checkout that’s causing the delay.

Or you can run your own investigation using a combination of metric tools such as Google/Firefox Developer Tools and GTMetrix. These are pretty useful for narrowing down frontend performance. It won’t give you answers in black/white but it will give you an idea where to focus your attention.

yes my site https://kingspaperworks.com/ the other pages are ok but the checkout is extremely slow

Looking forward for your help

Hi @Stephen_Oduor.

Please disable all shipping methods (UPS, USPS, Fedex, …) and payment methods except free shipping and check money order (to test) and try again.

Make sure to check them on store view level also.

Seems like some configurations are missing e.g credentials.

Kind regards,

Thomas

Thanks @thomas for reply, have tested but still slow, I have confirmed all shipping methods (UPS, USPS, Fedex) are disable, I have also disable other payments except money order

So, I had a quick look and the page seems to load well within tolerance for sure.

With my Browser Cache enabled (normal everyday use) I went onto your site, added an item and went to the checkout. The checkout took < 2 secs to load:

checkout-cached

I did the same thing again with Browse Cache disabled (what I do when debugging) and the page took < 5 secs to load:

checkout-not-cached

Unless you’ve changed something, these load times look great.

Did you get to the https://kingspaperworks.com/checkout/#payment that where the problem is, other parts is ok

Yes, I went through to Payment Methods. This is my experience on a browser that hasn’t been on your site before: https://vimeo.com/372855879/b7ab1f3483

You sure you don’t have some sort of Browser Plugin that’s interfering with something on the page?

I have watched , see the attachment,

Where it start getting slow :

  1. Select one of the payment methods then
  2. Click on place order

I can confirm I also experience this delay after pressing the Place order at the Checkout.

It’s my guess that MySQL is probably under some sort of load when the action occurs.

  1. Are there any other examples of when you go to submit something and you end up waiting a long time?
  2. What are your web server specifications?
  3. At any point have you configured any of the MySQL variables?

The web sever is 8GB RAM, I only experience the delay on the checkout place order.

About the mysql Varibales? do you mean username, password or

By MySQL Variables, I’m referring to things like innodb. However, if you don’t know what that is then don’t worry because it means you’ve never messed with them.

I read something last night slightly relating to this issue, where it turned out that disabling all of the RSS Options made a positive impact. Try Disabling all of the options under Stores > Configuration > Catalog > RSS Feeds

You might also want to disable anything like M2E Pro in case that is the route course. The issue you’re experiencing isn’t well documented online, leading me to believe it’s not a common issue - Therefore, must be impacted by some 3rd party module.

You might have to play a process of elimination with other 3rd party modules to try and narrow this down further.

Thanks @digitalstartup for your concern.

I have tried removing/disabling even m2E and Rss but no success. This problem has taken me 2 weeks, a now looking for alternative solution

I am thing of backing up database and do away with the UI files ie reinstall fresh magento 2.3 and restore the database.

What do you think?

There’s definitely no harm on trying a clean install. But without knowing the issue, who’s to say the problem could crop back up again in the future?

If you drop @thomas a PM, he should be available for hire if you want someone to dig deeper on the server. I think it’s wiser to address the issue than start over - But obviously go with whatever choice you think is best.

Thanks will see into it

Good luck. Would love to know how you get on afterwards :+1:

Hey. i decided to test the site on a different server(GCP). I backed up and restored db files and everything works. I suspect it mysql or the server resources that caused the issue

Though the server has 8GB RAM but there is other application running on the server ie an ERP
right now this what I can see from cpanel

Real memory 4.19 GB used / 2.81 GB cached / 7.75 GB total

I also checked on the url_rewrite table which has 5541 rows the same with catalog_url_rewrite_product_category which has 3184 rows. Could any of the above be the reason

Any suggestion?

Thank you for sharing your findings. If the problem was the data within the database, then the issue would be present in both servers. Therefore, I don’t think url_rewrite is related.

Editing MySQL Variables via PhpMyAdmin
If you log in phpMyAdmin as root, you will see a tab in the upper-right of the screen:

phpmyadmin%20variables

This shows you all of the MySQL Variables that you can set, which can also be edited from here.

1. Compare MySQL Variables
I would compare the variables of the 2 servers to see if you can identify a “dodgy” variable on your main server that is having an adverse effect.

2. Tweak MySQL Variables
Personally, I find the default MySQL Variables a little low. And this has caused me issues with larger sites in the past because I forgot to tweak them. Try amending the following MySQL Variables for improved performance:

  • innodb-log-file-size = 100M
  • innodb-buffer-pool-size = 2G
  • innodb-log-file-size = 250M

Making MySQL Variable changes permanent
For the most part, any changes you make will likely be overwritten next time the mysql service is restarted. So, in order to make sure any MySQL Variable changes are permanent you will have to edit the MySQL Configuration file. This requires root or superuser privileges. The location of the file will vary depending on both your Web Host, SQL Version and OS - So, you’ll have to find this yourself.

If you setup your Web Server using my tutorial then there is a good chance that you’ll find the file in one of these 2 locations:

  • /etc/mysql/mysql.conf.d/mysqld.cnf
  • or /etc/mysql/my.cnf

Simply replace the Variable that you want to change. If it doesn’t exist, then it will assign a default value - In this scenario just create a new line in the file. Once you’ve edited and saved the file, restart mysql to apply the changes.

There is no “undo” button. Always backup or take a note of any variables you Add/Edit/Remove.