MegaCache + Woo
-
How MegaCache is dealing with Woocommerce? Especially with dynamic data, like stock levels and cart?
-
Hi MegaCache does not cache Woocommerce pages. As you say, this is dynamic content and would require to run database queries to deliver current content, which makes the whole point of caching obsolete.
Other page caching plugins have options that you can select to exclude Woocommerce page/cart and so on, which basically results in not caching Woocommerce at all. All page caching plugins face the same issue with Woocommerce.
So my recommendation is, optimize your site with best practice settings for Opcache and WP-memory, enable object-caching (like atec-cache-apcu), use MegaCache to cache all other pages/posts and leave Woo untouched. That will give you the best performance.Any Woo page caching will slow things down or just make no difference compared to not caching.
The product page can be cached when:
- Stock is not managed on the Woo side
- Ajax is used to load dynamic data (e.g., for stock level). In this case, the cache should be cleared automatically when:
- The product is edited
- The product becomes out of stock
- The product comes back in stock
It’s not complicated to make Ajax requests for dynamic data from the product page or product list, but cache plugin developers don’t let users decide this for themselves and manage this part on their own. It looks like MegaCache is not an exception. 🙁
Cart and checkout pages shouldn’t be cacheable.
- How do you tell if Stock is managed or not?
- What do you mean? When do you want to make Ajax request? Ajax request is an extra request, so that would not make sense together with a page request. The only solution would be to use hooks for different events and clear the product cache in case they are fired.
- Woocommerce -> Settings -> Products -> Inventory -> Enable stock management. Then every product and it’s variation can have enabled/disabled stock management and stock level.
- When product page is loaded from cache, I’d like to load stock level using ajax. This way whole product page will be loaded from cache very fast and only one number (stock level) will be loaded with an extra request. Visitor will not notice that extra request.
Products are not so much “dynamic” as it might look like. Whole logic:
– If product has stock level management not enabled, load full product page from cache.
– If product has stock level management enabled and is out of stock, load full product page from cache.
– If product has stock level management enabled and is in stock, load product page from cache + small custom extra request to get current stock level.
– If product was edited, then clear the product cache.
– If product was in stock and became out of stock, then clear the product cache to regenerate the badges etc.
– If product was out of stock and became in stock, then clear the product cache to regenerate the badges etc.
– as additional feature, product cache can be cleared, when product stock reaches low stock threshold (it is set in Woo settings).
High running products will have big stocks and because of that page cache will not be cleared often.
Low running products will be purchased rarely and because of that page cache will not be cleared often too.
- That’s not what I mean, to develop Woo caching support we need an option for example that represents the status. And as you describe it it is relative to a product, so it must be accessible on the product level – do you know what I mean?
- This is a high level desciption and it looks complete. However, on the plugin level each of these points requires a hook or database query so that you can fire a cache flush.
Like here https://woocommerce.github.io/code-reference/hooks/hooks.html
But what we need are hooks not functions.
The functions are too time consuming and require database access.
Example: Product pages is requested. If cached, return it, if not, generate the page, and cache it.
Now with Woo, you would have to call the function to retrieve the current stock level with every request, which is too expensive.
Ok, you might want to cache a product page and request the stock level by ajax, which is only a small chunk, but the load on the server is still almost double (theme and product page not loaded). Plus you would have to define an area in the page where you want to inject the stock info.
If you are done with that, you would have to do the same with the price – that might have changed.
Get my point?
So this approach “after” page generation is not very efficient.
Only other option is to use hooks – given that there is a hook for every such dynamic data.
The hooks will run in the background, but on every request, even on non woo page request. If a hook returns changed data, the page cache for the respective product must be flushed.
Depending on the hooks involved, all of this will eat up processing time on the server – even if non Woo pages are requested.
Given all that would work out, you are facing the next issue with recommended and upsalling products.
If a product page includes recommended and upsalling products the above said counts for all of those products too! In other words, if stock of product “one” changes, you will have to flush every product page where “one” is part of the recommended and upsalling products list, because product might be out of stock.
That’s how deep the rabit hole goes.
I can not give any stats, but from my knowledge I think that the overhead for managing all of these things is higher than just generating the product page from scratch.
Remeber if you use a hook or more (can not exactely say how many hooks would be required to handle all this) is executed on every request, where the woo specific functions to generate a product page are only called, if a product page is generated.
You always need to compare the process costs.
MegaCache can reduce processing time below 1 millisecond!
Not much you can do in a millisecond.
I appreciate your input.
- When stock management is switched on in woo settings, then stock is managed on a product level in products inventory tab.
- I would check woocommerce_product_set_stock and woocommerce_variation_set_stock. I guess these are the right hooks which will be called only when stock is changing. If not, then these should be inspected too: woocommerce_product_set_stock_status, woocommerce_updated_product_stock, woocommerce_product_is_in_stock and the same for variations.
In e-commerce sales are more important than server resources. Actually, if it will increase the sales, server resources can be increased as much as needed. In e-commerce page speed for customer is much more important than server resources. And if we put customer in front of everything, then every customer has limited screen size. Initial screen is the part of the page which should be served the fastest. Everything else can be loaded in next 1-3 seconds after loading initial screen. Milliseconds are important only for the initial screen, then human reaction is too slow to react fast on everything else what is out of the screen.
I think you shouldn’t take care about dynamic product page parts and should leave them to be solved by site owners themselves. There are so much different themes and plugins, that you will not be able to make your cache compatible with all of them anyway. Let the site owners decide how to load these dynamic parts. I think it will be just a matter of time when someone will make public e.g. Bricks Builder elements for products dynamic data loading using custom ajax.
When product is saved or product stock status becomes out of stock/in stock, then cache for relations (archives or related products) also should be cleared. In any way it will be much less resources intensive than generating the full product page on every request.
Product page is the most important, because in e-commerce visitors land there from search engines or the ads. Home page is the second. In home page lands the visitors, who type shop url in browser.
How can I get a list of related/upselling products listed on a product page?
These?
https://woocommerce.github.io/code-reference/classes/WC-Product.html#method_get_cross_sell_ids
https://woocommerce.github.io/code-reference/classes/WC-Product.html#method_get_upsell_ids
https://woocommerce.github.io/code-reference/files/woocommerce-includes-wc-product-functions.html#function_wc_get_product_category_listWhat is your (woo) background ?
A year+ by trying to migrate from PrestaShop to Woocommerce for specific ecommerce. Goal is to have fully customizable solution (including cart and checkout) by not coding anything. After a few iterations and few sites made, this goal is almost reached, but I’d like to have more speed in some pages.
Are you willing to test MegaCache+Woo and have a site to test on?
I have it running with clean up hooks on
– price change
– stock change
– product change
what i am missing is
– product delete
and
on which other products is a product listed as cross/up-selling?Yes, sure, I’d like to test.
Product can be in bundles too. Also I think method_get_cross_sell_ids etc. is not good, because it will return the products which should be on cleared product page. But it should be the opposite. In this case we need to clear the products, where current product is cross-selled and up-selled. It’s not necessary is both way relation.
Lets test first and then I’ll check on how to get correct relations for the cleared product.No i think I have covered it with up+cross, but woo removes products from the list if they are on both lists.
The topic ‘MegaCache + Woo’ is closed to new replies.
