Woocommerce product pages slow to load

Thanks for reaching out here. We’re sorry to hear that you’re having trouble using Yoast SEO on the WooCommerce product page.

Can you please confirm whether you’re running the latest version of WordPress and Yoast SEO? If yes, can you please confirm whether the issue persists when a product page has around or more than 1000 words in it?

Last but not least, can you please confirm whether you have performed the SEO data optimization from the SEO → Tools page? If not, can you please complete the data optimization first to see whether this improves anything for you?

We look forward to hearing from you.

Hi there,

Yes we’ve got everything running up to date (WP core, plugins etc). We’ve also ran the data optimization but it made no difference.

Our products are slightly more custom than a standard WooCommerce store, so we don’t use the post_content and instead pull data from custom fields etc so the post_content editor is always empty for all products.

That said, we do have a custom WooCommerce product type which loads quite a few ACF fields in the back-end where data is stored. Two scenarios explained below:

? “Simple” WooCommerce product type – This is basically just the standard WooCommerce product with no additional fields. Yoast seems to load pretty efficiently in this instance.
? Our custom WooCommerce product type – In this product type, we have quite a view ACF fields that are loaded specifically for these types of products and these are the ones that seem to take an age to load.

Initially we thought it may just be the number of fields being loaded from ACF that was taking the time, but again when we de-activate Yoast or disable it for the product post type, the page loads pretty much instantly which shows that’s not the issue.

We also tried taking all the ACF fields out for the product pages that were slow, but the issue still persists. The post meta would still all exist for that product though so I don’t know if that would make any difference.

Thanks

Hi @yellowpeach

We understand this isn’t a standard setup for your WooCommerce products, and that you are utilizing several ACF fields.

Often, we see problems occur in combination with another plugin or theme. The fastest way to rule out any conflict, is to deactivate all non-Yoast plugins and switch to a standard theme like Twenty Twenty.

Please test this on your development or staging site, if you have one. If not, we recommend using the Health Check & Troubleshooting plugin. This plugin has a troubleshooting mode, which does not affect normal visitors to your site.

If you’re unfamiliar with checking for conflicts, we’d like to point you to a step-by-step guide that will walk you through the process: How to check for plugin conflicts

Would it be possible for you to test this with a default WP theme such as TwentyTwenty, and only Yoast SEO v16.7, WooCommerce, and ACF as the plugins enabled and see if you are still able to reproduce the issue?

The Query Monitor plugin should be of help as well, to give you an estimate of how long the pages would load.

Hi there,

As I mentioned in my original comment, we’ve already tested using a core WP theme (TwentyTwenty), and also just having the required plugins (ACF, WooCommerce and Yoast), but the issue is still there.

If I look at the network waterfall, it’s very clear that the waterfall stops when hitting the SVGs being loaded in the Yoast meta box CSS file – exactly as mentioned in the other forum thread that I included in my original message. Here is a screenshot to show this: https://ibb.co/7CJx2XW. The waterfall is at around 3 seconds up to this point, and then does nothing until 20 seconds at which point this SVG loads, the page becomes interactive again and the remainder of the page loads.

Thanks

Hi @yellowpeach

Could you check if installing and activating the ACF Content Analysis for Yoast SEO plugin helps?

If the issue still occurs, since you’ve already performed a conflict check with a default set-up and the minimum setup of plugins, please do file a bug report by following the steps here, so our developers can take a closer look and provide feedback – https://yoast.com/help/how-to-write-a-good-bug-report/

Yes we already had the content analysis plugin installed so that didn’t help.

I’ve just gone to submit a bug report, but your website is done… “There has been a critical error on this website.”

Hi,

Do you mean the Yoast.com website? It was temporarily down last July 30, but it was worked on and is now up and running.

Please do check for feedback from the GitHub issue and bug report that you’ve reported.

Hi there,

Having tested a bit more, I can see that it’s something related to post_meta & Yoast.

We use the standard WooCommerce ‘simple’ product type and also a custom product type which has a couple of fairly large ACF repeater tables in.

The ‘simple’ WooCommerce products have no additional fields in so are in essence a bog standard WooCommerce product setup which has no performance issues, however the custom product type (‘Room’) has all the additional fields in due to the customisation required.

Checking the database and comparing the 2 product types, the ‘simple’ product has around 50 post meta rows, whereas our custom product type ‘room’ has over 2,000. I manually deleted half of those rows to cut it down to 1,000 and the performance issue was gone, so it definitely seems to be the number of data being loading and that causing issues with Yoast.

To confirm, that amount of data is required in these products due to the complexity of them. We’ve also tested removing the ACF fields from the product page so that when you edit a product, the fields aren’t actually there – just in case it’s an issue with how ACF initialise the fields, but the issue still persists. Again even with these products with large amount of data in, as soon as we disable Yoast they load instantly again so it’s almost as if the Yoast metabox initialisation speed is dependant on the amount of post meta assigned to the post.

Hope that gives you a bit more detail, but the best thing I can suggest is to insert a large number of post meta for a product (2,200 in our case) and then try loading the product edit screen and you should get the same issue.

Many thanks,

Hi,

Thank you for providing this information. Please do kindly add it to the GitHub issue that you’ve reported.

Given that this issue doesn’t occur for the simple product type and that it only occurs with your specific setup and custom product type and the amount of post meta rows generated with the Yoast SEO plugin, it’s something that needs to be checked on further by our developers.

Hi there,

Ok, if you can please keep us posted. To confirm, it’s not anything to do with the custom product type – if I add the high number of post_meta to a ‘simple’ product type (which comes as part of WooCommerce core) the issue is still there.

It’s purely down to Yoast + a large number of post meta. I haven’t tried it, but my guess would be that this issue is the same whether it’s a WooCommerce product or any post type.

Many thanks,

Hi,

Did you already create the GitHub report? If so, please do add all of the relevant information there and subscribe to the issue, so you will be informed of any replies or updates from our developers.

You can refer to the template here on how to create a good bug report – https://yoast.com/help/how-to-write-a-good-bug-report/

Hi,

I am facing the exact same issue with a similar setup. I have disable the yoast plugin and the product editor loads superfast. The moment I enable the Yoast plugin it all slows down and it is purely a Yoast issue. My host company have had a look into this and has pinpointed the issue to Yoast. Can you please advise what the Github ticket is and when this is likely to be resolved?

@umarglobal According to the forum guidelines, you’ll need to open a new topic instead of replying to an existing post. That way, it’s easier to track issues and provide assistance without alerting someone else for your problems and debugging, when they don’t need it.

I’m happy to be alerted on updates of this one until it’s reserved, so makes sense to keep it tracked under the same ticket.

Thanks for your confirmation, @yellowpeach. However, we are still waiting for you in regards to the last GitHub issue that @mikes41720 requested you to create. were you able to file a proper bug report yet? If not, no worries. You can take your time and submit it in your spare moment.