CACHE
- Thread starter JOHN GALT
- Start date
Not much left to do, but I'm currently drowning in work because I have other plugins in the pipeline that have a higher priority, such as the Kitt AWR plugin for LiteSpeed LScache plugin. AWR = avif & webp Replacement with Image Optimization. It is also a "hacker" plugin that unlocks or exposes locked and unavailable functionality, making quic.cloud obsolete. There are other plugins that have been specially programmed for the LScache plugin for Wordpress.
An ESI example: https://www.dev.cachecrawler.com/esi/
The crawler is not a sustainable solution. I need to have a solution that allows for a combination of cache and uncached data on the same page. Yeah I already watched the video. BTW everything on that site you sent me does not work. I logged in as a demo and the shopping cart constantly errors. What is the point of the link that you sent me ?
If by "W3" you mean the W3 Total Cache Plugin, then you are comparing an airplane to a submarine. That might sound exaggerated, but the differences couldn't be greater. That's why your comparison is wrong. As for the crawler, you need to know what the differences are with the cache. Above all, this means that the LiteSpeed cache uses so-called cache vary. This allows an almost infinite number of different cache copies to be created. In the cache plugin, these cache vary are used in guest mode, mobile devices and webp replacement. The W3TC and all other cache plugins lack such a function, which severely limits the area of application.
In terms of amount of URLs and time to crawl, you are comparing something that cannot be compared. W3TC only needs to crawl 1 of each URL in the absence of cache vary. With the LiteSpeed Cache Plugin, the Cache Vary turns 15,000 URLs into 120,000 URLs, depending on the configuration, because each additional Cache Vary doubles the number of URLs to be crawled. Therefore the crawler of the W3TC plugin is not fast and the crawler of the LScache plugin is not slow. However, the crawler of the LScache plugin for WP has some bugs that prevent it from crawling faster. It also causes an excessive server load.
But what about the solution you are looking for? What are we actually talking about here?
In terms of amount of URLs and time to crawl, you are comparing something that cannot be compared. W3TC only needs to crawl 1 of each URL in the absence of cache vary. With the LiteSpeed Cache Plugin, the Cache Vary turns 15,000 URLs into 120,000 URLs, depending on the configuration, because each additional Cache Vary doubles the number of URLs to be crawled. Therefore the crawler of the W3TC plugin is not fast and the crawler of the LScache plugin is not slow. However, the crawler of the LScache plugin for WP has some bugs that prevent it from crawling faster. It also causes an excessive server load.
But what about the solution you are looking for? What are we actually talking about here?
Can you tell me where in the hell these files are stored. I am not able to find it on a WPX install or a digital ocean image of lightspeed.
Where are the cached files stored?¶
The actual cached pages are stored and managed by LiteSpeed Servers.
Nothing is stored within the WordPress file structure.
Where are the cached files stored?¶
The actual cached pages are stored and managed by LiteSpeed Servers.
Nothing is stored within the WordPress file structure.
say more, in my example hoster clean /lscache folder stored in default server system path every 3 days and I must recache and recache again and again, not understanding WHY my lscache disappear 
ask hoster to store /lscache in you account
https://docs.litespeedtech.com/lsws...vel-cache-root-for-all-virtual-hosts-manually
https://docs.litespeedtech.com/lsws...-level-cache-root-for-a-single-vhost-manually
ask hoster to store /lscache in you account
https://docs.litespeedtech.com/lsws...vel-cache-root-for-all-virtual-hosts-manually
https://docs.litespeedtech.com/lsws...-level-cache-root-for-a-single-vhost-manually
Tell me why he thinks this is necessary? Is he running out of disk space?
If @JOHN GALT uses shared hosting, which I assume it does, this doesn't allow individual server configuration. It is possible to define individual storage locations for each domain and account, but not with shared hosting.
If @JOHN GALT uses shared hosting, which I assume it does, this doesn't allow individual server configuration. It is possible to define individual storage locations for each domain and account, but not with shared hosting.
yes. it was before implemented curl_setopt($ch, CURLOPT_ENCODING, ""); for crawler
and size of lscache was more than 64GB (for 6000 pages and 8 UA's )
now 23GB for 10000 pages and 12 UA's
my hoster at begining also says "this doesn't allow individual server configuration" and "possible security problems"
but even OpenLiteSpeed allow invividual lscache store folder
/home/<account_name>/.system/lscache/<domain_name>
lscache store folder can be configured for each virtual host.
and size of lscache was more than 64GB (for 6000 pages and 8 UA's )
now 23GB for 10000 pages and 12 UA's
my hoster at begining also says "this doesn't allow individual server configuration" and "possible security problems"
but even OpenLiteSpeed allow invividual lscache store folder
/home/<account_name>/.system/lscache/<domain_name>
lscache store folder can be configured for each virtual host.
Last edited:
Despite your hosting provider seeing a reason for emptying the /lscache directory, you should seriously consider rethinking your crawling philosophy. We had a discussion a long time ago about what you might remember. It's not about warming the cache of all URLs, just the cache of the URLs that are actually requested. This dramatically reduces the crawling effort by more than 70%.
Your argument that you would have disadvantages in search engine rankings cannot be verified. Especially because the loading time is not measured by Google, but by users who send the relevant data to Google via the Chrome browser. Googlebot's crawling and how long it takes for your page to load does not affect your ranking in any way, precisely because Googlebot does not take any measurements that affect the ranking. You don't seem to take this insight into account, so you don't have to wonder why your hosting provider is taking the consequences.
Your argument that you would have disadvantages in search engine rankings cannot be verified. Especially because the loading time is not measured by Google, but by users who send the relevant data to Google via the Chrome browser. Googlebot's crawling and how long it takes for your page to load does not affect your ranking in any way, precisely because Googlebot does not take any measurements that affect the ranking. You don't seem to take this insight into account, so you don't have to wonder why your hosting provider is taking the consequences.