Hi Edward,
Thanks for getting back to us. How many approximate variations do you have with each product?
Hope to hear from you soon.
Thank You
Hi Edward,
Thanks for getting back to us. How many approximate variations do you have with each product?
Hope to hear from you soon.
Thank You
Probably 4-5 variations per product on average. Some have as many as 10. See this page for example: https://swansislandcompany.com/product-category/blankets-plus/blankets/
Hi Edward,
Please change the value like this: https://paste.pics/PQ0BN
Then flush all the caches like- browser cache, caching plugin cache, and server-side cache.
If you have no idea regarding server-side cache flushing, please contact your hosting support.
They can flush it for you.
Thank You
Thanks–it wouldn’t let me enter “12” only multiples of 5 it looks like. So I entered 15 and flushed caches.
Can you please explain the difference between loading by API vs. html? I understand what an API is but why would you need to make an API call to load a swatch?
Also, should I check the “Enable archive page swatches preloader” checkbox on the “Archive/Shop” tab of the plugin settings?
Hi Edward,
Initially, our plugin loads data using HTML in the 1.1 series.
But we have some customers who have 1400 variations with each product.
So, it takes a long time to load if there are several products on the archive page.
To minimize this critical situation, we had to release version 2.0.
In this version, all the swatches will load by firing the API call.
But, if someone has only 4-15 variations it is kind of over-engineering to call them using API.
So I have suggested you change the value there. So now, the API call will not run where it will get 15 variations.
But if one product has 16 variations, then the API call will be fired.
Also, should I check the “Enable archive page swatches preloader” checkbox on the “Archive/Shop” tab of the plugin settings?
It is not mandatory to enable the preloader. But you can enable it to let your user know something is happening, please, wait till it loads.
I hope the above explanation will help you to understand the scenario.
Thank You
Thanks for the explanation. Definitely don’t need to be making those API calls on my site.
I’ll check the site performance now and see if it’s improved.
Hi Edward,
Thanks for understanding. Sure, please let me know how it goes.
By the way, we really get excited & honored when you use our plugin on your site.
If you found my support helpful, could you please leave your valuable review here: https://wordpress.org/support/plugin/woo-variation-swatches/reviews/?filter=5
Your rating keeps us inspired.
Thank You
Hello Hakik,
Circling back here because I’m still struggling with your plugin consuming large amounts of CPU resources on my web server.
Definitely being caused by having “Show swatches on archive / shop page.” selected. It’s spiking the CPU and it’s also more than doubling the page load time.
What can be done to fix this? Does it matter if I have the “enable swatches preloader” enabled? I can’t really see a difference.
We’re at the point here where we might have to find a different solution for archive page swatches. A little impact is tolerable but this is causing problems and probably costing us conversions.
Would welcome any ideas you have on improving this situation. Even if I could defer some of the scripts initiated by the plugin until after the “above the fold” page content is in place and, ideally, the page is interactive. Not good having customers (especially on mobile) waiting many seconds before they can interact with the page. Many will just leave.
Thanks,
Ed
Hi Justin,
What is your current setup of the Archive Variation Threshold?
Hope to hear from you soon.
Thank You
See above in this thread–it’s set to 15. That helped reduce a huge amount of Ajax calls that were being made before, but the archive page swatches still seem to be using a lot of PHP processing. Any ideas how to reduce that?
I see there’s a new feature labelled ” Use variation swatches block to display swatches on archive for Block Themes”
Wondering if going that route would help.
Hi Justin,
Unfortunately, that option will not work for you. Please contact your hosting and ask them if they have Redis Cache facilities or not. If they have it, please ask them to enable it for your site. If still, that doesn’t help, unfortunately, there is no workaround to reduce it further.
If you are not still happy enough after applying 15 at Archive Variation Threshold and Redis Object Cache, then you can claim a refund.
Please let me know your thoughts.
Thank You
OK, thanks, let me see if I can improve things with caching.
Variation swatches plugin is using up web server’s PHP resources
Justin Mazur
Hi,
Noticed my web server’s response time slowed way down after I installed the Variation Swatches for WooCommerce plugin. I inspected my logs and found a bunch of slow PHP operations that can be traced back to the plugin. Would you please have a look and see if you can tell me what’s happening and whether there’s any way I can fix this?
Let’s look at one example, there are many more like it. After noticing that my performance metrics declined, I investigated and found that PHP-FPM was being very heavily used and running out of resources. I logged any PHP operations that took longer than 7 seconds and found a whole bunch associated with the swatches plugin.
This is from the PHP log:
[22-Oct-2023 08:29:15] WARNING: [pool www] child 34518, script ‘/var/www/html/sico/index.php’ (request: “GET /index.php?_locale=user”) executing too slow (12.463129 sec), loggingThis is the same event from the NGINX access log:
172.31.21.42 - - [22/Oct/2023:08:29:15 -0400] "GET /wp-json/woo-variation-swatches/v1/archive-product/13013?_locale=user HTTP/1.1" 200 1630 "https://swansislandcompany.com/product-category/sale/" "Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/284.0.569260749 Mobile/15E148 Safari/604.1"
And this is the strack trace from the slow PHP query log: