Cache MISS on 1st visit every time. Sitewide purge on save

have you checked/tried the crawler ?

I keep the crawler going on a frequent schedule. It has about 1500 in the blue oval. Though Im not sure how to the crawler can resolve the issue if its auto purging when updating.

I also run some RSS and instagram feed plugin which are making updates, so I suspect the cache is getting cleared tens or hundreds of times per day. My cache hit ratio in quic.cloud dashboard is very low.

IS there a way to block the sitewide cache clearing?
Is updraft a likely culprit?
Fontawseome?

We seemed to think this may have been involved after auditing the litespeed logs before (evcal_arrows evo_arrow_next evcal_btn_next)

How do I troubleshoot this?

In an attempt to fix my current bounce rate and a bandaid solution.
Im trying to get the crawler as aggressive. I have rss feeds and instagram posts on SOME pages that update every 6-12 hours.

Your suggestion to use the cache crawler is confusing. You had advised me prior (months ago) that I would need to have a script written to keep the cache warm? Or perhaps I misunderstood

______
Ive now ramped up my crawler settings so it is going to be crawled rapidly. Seemingly every 15 minutes.

I had 4 crawlers running with guest mode activated. However Im using optimole for images. The top 2 crawlers are (Guest – WebP), thus I disabled.

Is this ok to disable the Webp crawlers if Im using the optimole plugin?
_______
Here are my settings on the crawler
ON
500
1200
61
500
3
20
1

It looks like CPU is hitting 45% at the peak with crawler at these levels. Memory < .33 utilization.

Prior it was usually showing my 1600 pages in blue bubble. Now they are green with 1600 in the green bubble.

I have occasionally seen the stopped_reset.

Im thinking that any page load on the admin is causing a purge action. And perhaps the crawler to stop


Can you advise me as to whether this will fix issues with cache not being available for first time visitors? Most my users are on mobile networks, it seems and across the world as I publish location and time content for art fairs

• This reply was modified 1 year, 7 months ago by RL.

Why use the LiteSpeed cache plugin if you think another optimization plugin would be better but this plugin is cache unfriendly?

If you disable individual crawlers, why are you surprised that the cache isn’t warmed up the first time you request it?

You are largely the cause of all your problems. With the LiteSpeed ache plugin you have everything you need for page optimization. In addition, these optimizations are adapted to the cache.

So disable this other optimization plugin and enable all crawlers.

@serpentdriver

I went back to using optimole after many litespeed images were not all optimized. On attempt, about 3% were deleted. Optimole allows me some conveniences with on the fly optimization. And for my workflow it works best.

Do you have data to suggest that optimole is the cause of the cache purging? If not than your aggressive feedback is not helpful.

Do you have data to suggest that optimole is the cause of the cache purging?

I never said a word that Optimole was the reason for the purge. But according to your description, you are running a mix of plugins that do not allow problem-free functionality and you should actually be aware of that yourself. If in your opinion the LiteSpeed cache plugin does not provide the expected functionality, then the logical consequence is not simply to use another plugin. Has it ever occurred to you that this could create conflicts?

However, if the cache is being purged too often then you might want to read this: https://docs.litespeedtech.com/lscache/lscwp/troubleshoot/#cache-purges-too-frequently

On attempt, about 3% were deleted.

The cache plugin does not delete images.

If not than your aggressive feedback is not helpful.

Do you have a problem with being bluntly told the truth?

@qtwrk
@serpentdriver

Ive attached an error log when tried to troubleshoot previously. Errors seemed to have this bit of code cited. I hit a wall and did not know the next step to resolve.

This seems to be connected to the event calendar plugin or perhaps fontawesome within the event calendar based on my best guess when using the inspect tool.

ad .evcal_arrows.evo_arrow_next:before{r):

02/21/23 09:27:55.646 [209.124.84.191:12346 1 1Kr] [UCSS]  ? empty ucss [content] /* [ERROR]  Unknown word ( ad .evcal_arrows.evo_arrow_next:before{r): Please fix this css error and then try again. The problem may be around this string, normally right after it. If nothing else, you can find out which css file contains this css string and exclude it from css combine. */
02/21/23 09:27:55.651 [209.124.84.191:12346 1 1Kr] ??  added _UCSS.2c41b1edadb1f749bdf26f8ae31f162d
02/21/23 09:27:55.651 [209.124.84.191:12346 1 1Kr] ??  X-LiteSpeed-Purge: public,fdc_UCSS.2c41b1edadb1f749bdf26f8ae31f162d
02/21/23 09:27:55.651 [209.124.84.191:12346 1 1Kr] [UCSS]  notify data handled, unset queue [q_k]  https://xzib.com/event-location/microscope-gallery
02/21/23 09:27:55.651 [209.124.84.191:12346 1 1Kr] [UCSS]  notified
02/21/23 09:27:55.652 [209.124.84.191:12346 1 1Kr] ?? [Tag] Add  --- HTTP.200
02/21/23 09:27:55.653 [209.124.84.191:12346 1 1Kr] [Ctrl] not cacheable before ctrl finalize
02/21/23 09:27:55.653 [209.124.84.191:12346 1 1Kr] [Core] Silence Comment due to REST/AJAX
02/21/23 09:27:55.653 [209.124.84.191:12346 1 1Kr] ?? X-LiteSpeed-Cache-Control: no-cache
02/21/23 09:27:55.653 [209.124.84.191:12346 1 1Kr] ?? X-LiteSpeed-Purge: public,fdc_UCSS.2c41b1edadb1f749bdf26f8ae31f162d
02/21/23 09:27:55.653 [209.124.84.191:12346 1 1Kr] [Optm] bypass: Not frontend HTML type
02/21/23 09:27:55.654 [209.124.84.191:12346 1 1Kr] Response headers --- array (
  0 => 'X-Powered-By: PHP/8.0.27',
  1 => 'X-DNS-Prefetch-Control: on',
  2 => 'Content-Type: application/json; charset=UTF-8',
  3 => 'X-Robots-Tag: noindex',
  4 => 'Link: <https://xzib.com/wp-json/>; rel="https://api.w.org/"',
  5 => 'X-Content-Type-Options: nosniff',
  6 => 'Access-Control-Expose-Headers: X-WP-Total, X-WP-TotalPages, Link',
  7 => 'Access-Control-Allow-Headers: Authorization, X-WP-Nonce, Content-Disposition, Content-MD5, Content-Type',
  8 => 'Allow: POST',
  9 => 'X-LiteSpeed-Tag: fdc_HTTP.200',
  10 => 'X-LiteSpeed-Cache-Control: no-cache',
  11 => 'X-LiteSpeed-Purge: public,fdc_UCSS.2c41b1edadb1f749bdf26f8ae31f162d',
)

The UCSS generator validator is unable to use this css, because it is not valid.

But that doesn’t necessarily mean that this CSS is actually wrong. The problem with this is that there is an officially certified standard for CSS formatting and the UCSS Generator uses this standard. However, this standard lags behind browser development and therefore does not correspond to browser development. This means that many browsers already offer technologies that are not yet certified. However, the UCSS Generator can only be based on this standard. The problem could only be solved by rewriting the affected CSS code so that it is valid according to the CSS standard.

The UCSS generator does not have a bug because of this.

Now that I know you’re using quic.cloud, I can tell you why the cache is not hit on the initial request. But it’s not because the cache is being purged uncontrollably by something. It’s up to quic.cloud or the crawler, which for technical reasons can only warmup the cache on the origin server, but not the cache on quic.cloud. But that is due to the nature of things or the technology of each CDN and cannot be solved.

@serpentdriver These are old logs. Im not using UCSS, viewport , or any of those now…. except guest mode(which Im not certain if it helps).

It seems litespeed and JS/CSS optimization do a great job.

The issue I have, most the organic visitors are on mobile and its ideal to use CDN bc the searches are all over the US, and sometimes europe and asia.

Are you saying the CDN nodes can never keep the data in cache?

it still seems to be a very wide variance on the speed when I test it on mobile networks. The same page sometimes is lightening fast. And other times is slow… So Im trying to ferret out if I have something wrong.

Honestly Im confounded by this stuff(origin versus node, static vs dynamic). Really wish I would have studied it formally…

These are old logs. Im not using UCSS, viewport , or any of those now…. except guest mode(which Im not certain if it helps).

Then why are you posting the logs?

Are you saying the CDN nodes can never keep the data in cache?

No I did not say that. I said the crawler can’t warm up the cache on quic.cloud. The crawler does not run externally, it runs on the origin server. In this case, the URL or the IP address is not resolved on a QC node, but directly on the origin server. This results in a request being answered on the origin server and not on a QC node and therefore only the cache on the origin server is warmed up. This isn’t a bug, it’s inherent in the system. In order to be able to warm the cache on each QC node, one would need in each region of a QC node a computer with an installed crawler that warms the cache of each node. The cache is not stored centrally, but individually on each node. As far as I know, LiteSpeed is working on a solution to synchronize the cache. It’s not currently working, but I hope you understand that this isn’t a bug or a malfunction?

Got you. So there is no APO type cloudflare product, yet Thank you for the clarification. Ive read some of your other posts where you suggest that a CDN is not always of benefit.

My mind is blown to realize the crawler is actually keeping the origin warm, and not the CDN nodes. So I presume I should keep the crawler going very consistently to keep the x-litespeed hit ratio as high as possible?

In my situation where Im using feeds from Instagram and RSS. Any additional steps I should take?

If you have many visitors from other countries, then a CDN makes sense, of course, whereby you benefit from a CDN in two ways, since it is not just about the cache, but about the resolution of the IP address, because a CDN is primarily about the principle goes: “Bring the content closer to the user.”, because the shorter the connection, the faster it can be loaded. A cache is not necessarily part of every CDN, but a cache function can only have an advantage if the cached content is present on the respective node. If this is not the case, the content must first be loaded from the origin server and then it will inevitably take longer for the page to load.

In your specific case, only traffic helps and if that is not enough, then you need even more traffic and “never” purge the cache.

Any additional steps I should take?

Yes, more traffic that keeps your cache warm. ??

more traffic?
Ok, Im looking for that button….

Well, the good news is that when I do start getting traffic, its usually concentrated in the 1 area, around 1 node from people attending a fair. And based on my understanding things stay in quic.cloud nodes for about 24 hours. So that is good for that situation.

And based on my understanding things stay in quic.cloud nodes for about 24 hours.

This depends on your setting for cache TTL. 24 hours isn’t really long?!