non-cached woocommerce pages = TTFB 8 to 13 seconds

please provide the report number

you can get it in toolbox -> report -> click “send to LiteSpeed”

Hi, report sent…
Report number: ACATXJGF
Report date: 03/11/2024 10:33:02

As I say, when it works, it’s blisteringly fast, and when the cache is purged, it’s awful. And despite not having Product Categories selected to purge, they are being purged.

Screeenshot: TTFB 9.4s https://ibb.co/x7DT3kb

It is a busy’ish site + regular 5 min API updates to stock.

Any help is greatly appreciated!

try disable ESI

This did nothing. Other than the stock quantity on the product page no longer updates after a sale. I have turned ESI back on, flushed the cache, re-crawled, and the stock no longer updates on front end (tested across multiple private browsers).

In addition, switching ESI off, also did not fix the issue of product category pages cache purging and a TTFB of 10 + seconds

now that is weird , have you tried the default configuration? how does it go on default ?

I have tried all of the preset configured options.
When pages are cached, its amazingly fast.. I understand that when a product page has it’s stock levels changed, the cache is purged.. no problem, the none-cached product pages are generally 2 seconds TTFB, so acceptable..

The problem is with the product category pages, this is my selected option “Purge product only when the stock status changes. Do not purge categories on changes to the quantity or stock status.” Yet, each time the stock quantity changes, the product category cache is purged. Not only the category the product sits in, but also the parent categories.

none-cached product category pages have an appalling TTFB, rendering the site almost unusable. https://ibb.co/b1V8gy2

While none-cached pages, posts and products have a TTFB from 700ms to 2000ms…

It seems the cache, for the whole site is being purged, upon one single change to one product’s stock levels/stock status.

I just can’t understand why or how to fix it?

• This reply was modified 1 year ago by rockso.

While none-cached pages, posts and products have a TTFB from 700ms to 2000ms…

please check on default setting , what is the sum of TTFB + content download time , and with plugin disable , the sum of them

Hi..

Product category page – Cache – miss
TTFB 8.83s, content download 16ms, total time 8.85s
https://postimg.cc/YLjr7zdD

Same product category page – Cache – hit
TTFB 27ms, content download 2ms, total time 29ms

Same product category page, Litespeed Cache plugin disabled
TTFB 257ms, content download 8.25s, total time 8.51
https://postimg.cc/DmzLmVDH

#while the cache miss and cache disabled have similar overall total times, with the plugin disabled, you see content appear on the screen with a second… and build up, rather than cache miss, where nothing appears to be happening for 8 seconds.
—
Product page
Product category page – Cache – miss
TTFB 1.7s, content download 7ms, total time 1.8s

Same product category page – Cache – hit
TTFB 19ms, content download 2ms, total time 22ms

Same product page, Litespeed Cache plugin disabled
TTFB 279ms, content download 1.1s, total time 1.4s

while the cache miss and cache disabled have similar overall total times, with the plugin disabled, you see content appear on the screen with a second… and build up, rather than cache miss, where nothing appears to be happening for 8 seconds.

well , that’s the thing

the PHP takes 8 seconds to generate the page.

but the plugin needs to buffer the output , so it can perform its tasks, and after modification (like JS/CSS minify , combine ….etc all the thing that modifies the html source code), then send it to browser

this is core function for cache plugin , because logically, you can NOT modify the source code after you sent it to browser already

so it has to buffer the output , modify it , send it to

while on the other hand , without plugin , as you described is like PHP didn’t buffer the output , and sending the response to browser “line by line” as it generates

in such case, if PHP itself takes so long to generate , we can’t really help on that part ??

on the other hand , for your stock purge , you may need to grab the purge log , see what log says

Hi, I’ve just received and email from my hosting company, who’ve been helping me also. this is their email to me….

Hi

Thank you for providing the steps.

I have done some extensive testing this morning, and found the following which needs to be addressed with Litespeed support:

Purge product on changes to the quantity or stock status. Purge categories only when stock status changes.
X-LiteSpeed-Purge: public,9df_
Category, Subcategory and Product pages all purged after purchase even when product remains in stock
NOT EXPECTED
Notes: Expected Behaviour: With this selected the expectation would be that only the product page would be purged rather than the product page, category and subcategory pages after a single purchase which does not result in the item becoming out of stock.
Unfortunately due to the fact you are displaying the number of units in stock on your product pages this realistically is the preferred setting because otherwise the number of units in stock on each product page wouldn’t update after purchases. You do have the option of hiding the number of products in stock however.

Purge product and categories only when the stock status changes.
X-LiteSpeed-Purge: public,9df_FD
Category, Subcategory and Product pages remain cached when stock status remains in stock after purchase
EXPECTED BEHAVIOUR

Purge product only when the stock status changes. Do not purge categories on changes to the quantity or stock status.
X-LiteSpeed-Purge: public,9df_FD
Category, Subcategory and Product pages remain cached when stock status remains in stock after purchase
EXPECTED BEHAVIOUR
Notes: If you were to hide the number of units in stock on your product pages, this setting seems to work properly with the purge changing to X-LiteSpeed-Purge: public,9df_ = which results in product page and category/subcategory pages all being purged to then be updated to Out of Stock on the product which status has changed.

Always purge both product and categories on changes to the quantity or stock status.
X-LiteSpeed-Purge: public,9df_
Category, Subcategory and Product pages all purged after purchase
EXPECTED BEHAVIOUR

In conclusion to address the unreliable caching and performance:

• LSCache doesn’t seem to be purging correctly in the instance that only the product should be purged on each purchase provdiing the status does not change. This needs to be addressed with Litespeed Support.

please check my previous , last line there is a guide to grab the plugin log