Search results

@anna_ch The difference between with and without the UMW plugin results from the way the UMW plugin works. Example: If you have 1000 URLs in the sitemap, then 1000 URLs will be crawled. (without UMW Plugin) If only half of the 1000 URLs are accessed by visitors, then only 500 URLs need to be...

Please read this: https://www.litespeedtech.com/support/forum/threads/please-use-the-official-wordpress-forum.16028/

Gladly! But you would have to give us a little more information.

How to warm up the cache of URLs that are not in the sitemap. If you use one of the LiteSpeed Cache Plugins for WordPress, OpenCart, PrestaShop or another LiteSpeed Cache Plugin, then you are certainly familiar with the problem that the included cache crawlers can only warm up the cache of the...

As already said, the LiteSpeed web server does what has been standard in every web server for 1000 years. This means that the type of compression used depends on what type of compression the browser supports. If the browser sends the value gzip with the Accept-Encoding header, then the output is...

https://www.litespeedtech.com/support/forum/threads/please-use-the-official-wordpress-forum.16028/

@Niteesh Pandey Please login at LiteSpeed Slack. There you will get better support. https://www.litespeedtech.com/slack

You already got clear answers. The problem is not caused by LSWS, so you must ask Pingdom why Pingdom doesn't recognize gzip compression although LSWS uses gzip compression if the browser or Pingdom only supports gzip. Pingdom is not a reliable reference to check if a web server works properly.

Please excuse me if I correct your comment as it could be misunderstood. There is no default compression because the compression type depends on what compression is supported by the browser. If the browser does not send Brotli but the gzip Accept-Encoding header, the compression type is gzip...

If you have a server control panel like cPanel installed there is nothing to do. Most settings in WebAdmin are for native usage of LSWS if there is no server control panel. btw. Use LiteSpeed documentation instead of LS wiki. https://docs.litespeedtech.com/...

@av_admin You will not get a satisfactory answer in the WordPress forum for the LiteSpeed Cache Plugin for WordPress, even though I have already given you the answer to your question. The support in the WordPress forum is excellent, but not all-encompassing. Not every LiteSpeed developer knows...

https://www.litespeedtech.com/support/forum/threads/please-use-the-official-wordpress-forum.16028/

@av_admin FYI: A green icon doesn't mean that the crawler skipped a URL. If a x-litespeed-cache header exists and this header is hit then it is green.

I know, but there is no logical reason why it sometimes work, but mostly it doesn't. Certain server configurations could prevent the actually faster method. But then the function that the cache is updated no longer applies. Just wait for a reply in Slack. btw. You used the wrong Slack channel...

I am not shure if LiteSpeed knows it. You are the second user who reported it since cache plugin for WP exists. Login to LiteSpeed Slack and post this "issue" there. At LiteSpeed Slack to can talk with LS developers directly. This forum doesn't support cache plugin for WP any longer...

@av_admin For the case you missunderstood my description. The quoted method is the current method and is already in use, but causes the issue that already cached URLs are not displayed in the green icon.

The method I described is fix and can't be changed and you can't check it.

https://www.litespeedtech.com/support/forum/threads/please-use-the-official-wordpress-forum.16028/

The cache can be warmed up in two ways, but only one of the two variants is used in the built-in crawler of the cache plugin for Wordpress. This variant in question updates the cache of a URL by the set TTL if the cache has not yet expired. This variant is slightly faster than the other variant...

The legend at the end of the page gives information about the colors or what don't you understand?