Search results

@et_goldenm Run "Purge All - CSS/JS Cache" This kind of purge should solve the issue.

@mikegs1 You've obviously made a lot of effort, but you can save 2/3 of this work because it's unnecessary. Especially since every rewrite rule does not make your server faster and safer. Most of these rules are therefore meaningless. I cannot recommend other interested readers to adopt these...

It's primarily about Wordpress or the LScache Plugin (LSCWP) for Wordpress, but the problem affects every LiteSpeed Cache Plugin for which a Cache Warmup Crawler is available. In order to benefit from LScache, it is imperative that the cache is warmed up. If you don't do that or maybe don't...

If statistics are to be believed, there is currently only 1 web server that has shown significant growth rates for more than 10 years. All others seem to have been weakening for quite some time. Where does that come from?

Ever since Google Pagespeed, there has been a misconception that Google doesn't really want to create despite sufficient criticism. But before I demonize Google, I want to first praise Google. Praise for the fact that Google has been the only authority for almost 20 years now, which is committed...

The following explanations should help to answer the basic question of what advantages and disadvantages there are by using a CDN and whether there are alternatives. Basically, a CDN follows the principle: "Bring content closer to the user". Leaving everything else aside, everyone should be...

And again and again, if you get 304 status code in your case and only in your case this is not a result of special settings. This is a absolute normal behaviour of every browser if he requests a static source that is not css, js or image. In your case index.html is a static source!

A few days ago there was an intense discussion in LiteSpeed Slack about why you can only enter 1 sitemap for the crawler in the cache plugin for WordPress. If you have a plugin installed, such as YOAST or Rank Math, the question does not arise because these plugins automatically create an index...

*** New Features *** *** New Features *** *** New Features *** *** New Features *** *** New Features *** Since version 1.6 of the cache plugin for the LiteSpeed LScache plugin for Wordpress, there is a new function that dramatically reduces the crawl and warmup effort. While every Wordpress...

In case you are thinking of switching from OLS to LSWS at some point, I want to point out one of the many differences between the OpenLiteSpeed and LiteSpeed Enterprise web servers. The LSWS offers the possibility to cache POST requests. The OLS cannot do that. While POST is typically only used...

LSCWP manages nothing. LSCWP is just a control panel to set cache headers. There is nothing special with this plugin.

Of course, there must be an reduction, but it is only caused by browser cache behavior and has nothing to do with LiteSpeed and LScache. As already said, index.html at your page is identified as a static source and is not cached by LScache.

For all interested readers of this topic, please do not use the comments of the user @kvv213 as a guide if you plan to use OpenLiteSpeed. 99% of the topics discussed here are based on insufficient knowledge of how to properly configure a server. However, using OLS does not mean additional work...

For your information. The index.html is identified by the browser as a static file and not dynamic. That's why you can throw your supposed achievement completely overboard.

What application are you talking about? These pictures do not show Wordpress sources?!

Expire directive defines how long a requested source can be cached by browser, but expire is expire and not cache-control. Basically both do the same, but whenever you check response headers there must be a expire header. I can't imagine why OLS should make a Cache-Control header out of an...

There is nothing wrong and is a typical browser behaviour, so don't care about any longer.

The statsus code 304 for static sources depends on used browser. Chrome always displays cached CSS sources and creates a 304 status code for cached static sources regardless of which expire or cache-control settings you have made.. Firefox behavior is different. FF uses status code 200 if static...

You should disable the setting in cache plugin for removing GET parameters. This is the cause of it.

You seem to have not or not yet understood a few basic things. So here is an update for you. Cache-Control and Expire Directive are basically the same thing or have the same effect. The difference comes from the history of the HTTP protocol. The Expire directive originated from HTTP/1.0...