LSCache expired early than cache PublicTLL settings!?!?!?! help explain and understand [SOLVED]


Well-Known Member
And this issue only happens with internal cache crawler?
I use only internal cache crawler because external crawlers (like Netpeak Spider) not generate cache :( or lifetime of generated cache is very small (not sure)
but if I previously generate cache by internal crawler then external crawler says "quick response".


Well-Known Member
Really? If so, something must be wrong with defined cache parameters or/and cache varies. Anyway, I am out from here and can't help anymore. To solve your issue someone must have access to your installation.


Well-Known Member
To solve your issue someone must have access to your installation.
Shared Hosting Server - I only ask hoster check or set if need. but what?

I think may be problem in:
a) x-litespeed-cache-control: public,max-age=86400 is an LSCache control header, which will be seen when the cache plugin being used.

b) When using a rewrite rule like [E=cache-control:max-age=120]to enable cache as instructed in this wiki, you won’t see the x-litespeed-cache-control header.

for separate Mobile and Safari views used .htaccess rewrite rules.
may be some incompatibility between LSCache plugin and .htaccess rewrite rules?


Well-Known Member
may be some incompatibility between LSCache plugin and .htaccess rewrite rules?
No, I don't think so. In my mind the most important and the very first way would be to isolate the reason and to find out, if the issue only happens with crawler or independently from it. For this it would be very very very important to use same UA for crawler and for manual request with browser. Otherwise you will always fail.

Independently from this I remember to many of your posts in the last 2 years. You did a lot of custom modifications almost everywhere. Maybe the reason for the issue is sitting in front of the monitor....?!


Well-Known Member
What do you expect? Each of your modifications can have the potential for interactions with other functions. Sorry to say that, but you have maneuvered yourself in a street with dead end.


Well-Known Member
First of all you have to know is, that Pagespeed doesn't measure the loading time. It measures the "display time" after all data has been loaded from the server. LiteSpeed cache is speeding up the loading time, but not the display time, because only the php based main document is affected from caching but not static sources like .css or .js. These static sources and the way how the are loaded affect the display time Pagespeed is interested in. For Pagespeed it doesn't matter if a HTTP cache is used or not, because and again Pagespeed can't and doesn't measures the loading time.

If you allegedly have disabled caching for bots and if you get bad results now some other things must be wrong with your cache varies. Litespeed cache has almost no effect to Pagespeed.

Believe it or leave it....


Well-Known Member
Litespeed cache has almost no effect to Pagespeed.
you really believe in this?
first time attempt(no lscache, X-LiteSpeed-Cache: miss )
Reduce initial server response time

second time attempt and next attempts (lscached, X-LiteSpeed-Cache: hit )

and next: on Page Experience score GSC use Google Bot UA instead PageSpeed(Lighthouse) UA.
you can see this in your php response log!
Last edited:
Sorry, I can't answer your last post. I don't know what cache varies you have defined, but if you think something is wrong and it doesn't work as you believe it should, check your cache varies. There is definitely something wrong with it!!


Well-Known Member
and probably I find where problem with "LSCache expired early than cache PublicTLL settings"

after two week discussion hoster finally admitted that:
- stored lscache in system root
- delete(clean) lscache from system root to prevent overload (in unexpected for me time)

when I ask to store lscache in my account hoster says: OLS has not technical possibility
I send link to
Set up Virtual Host-Level Cache Settings

hoster says: exist possibility of security breach because cache stored by web-server owner (not user account owner)

now hard discussion with hoster continues