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 in configuration. Most related to Apache. However, you can also complicate things if you only make assumptions and do not acquire enough basic and OLS-independent knowledge.
I did some more research including reading the manuals from google.
First of all. Let's set the terminology used:
1. LSC - LiteSpeed Cache plugin.
2. LSCP or LSCWP - front face of LSC, that let to configure the LSC from WordPress admin page.
In LiteSpeed httpd server LSC can be controlled over interface or via .htaccess. In OpenLiteSpeed LSC can be controlled via not-documented config section.
BTW here is the config I have in my installation:
Apache config:
module cache {
internal 1
checkPrivateCache 1
checkPublicCache 1
maxCacheObjSize 1000000
maxStaleAge 200
qsCache 1
reqCookieCache 1
respCookieCache 1
ignoreReqCacheCtrl 1
ignoreRespCacheCtrl 0
enableCache 0
expireInSeconds 3600
enablePrivateCache 0
privateExpireInSeconds 3600
ls_enabled 1
}
All the settings are default. But I doubt about enableCache and enablePrivateCache.
Then let's move forward. There are two types of cache:
1. The Server side. It is controlled by the settings of LSC or via settings provided by LSCWP. When it is stale it is re-generated by the server. That is simple.
2. The client's browser settings. There is only one possibility for control via header. But here we can have a number of options and not of them are supported by all the browsers especially the old browsers like IE6 that we can forget for a long time and browsers at Mac-devices (this is true only about Safari).
So, I have to rewrite my previous statements to make them more detailed and it belongs to the client's cache at the browser:
1. Expires
(that is partially obsolete) defines how long the resource can be considered fresh
at the client's side. In OLS this value is transformed into cache-control: max-age.
Max-age tells the browser how long it can use its local stored copy of the resource. The other header that do the same job is Last-modified and expires.
2. If I'd like to be sure that a resource (like css or js or html) is updated at the client and not taken from its cache. Then I need to reduce max-age to very small value or even zero
or use no-cache or no-store (for proxies) (or no-scache for CDN)). Additional headers like must-revalidate can be used. In all other cases the client's browser will take the resource from its own cache. If I use large max-age then there is no way to urge the client's browser to reload the resource. If this is set to text/html that may arouse additional troubles. For resources it is possible to use versions in their file names like jquery.0.4.5.1.js or add some get request to the URL like main.css?a=b.
3. When max-age is not expired any browser
request to resources ends with 200 code.
I was not completely true here: if max-age or last-modified or expires tells the browser that the resource is not staled then the browser takes it from its cache. And here the browser shows in its logs Code 200 the same way as it downloaded the resource from the web-server.
4. When max-age
/last-modified/expires is expired then browser requests the resource
once more from the web-server and if it is not changed
(etag helps with that) then it receives 304. The same with soft reload via F5 (hard reload with shift-f5 requests all the resources).
With F5 reload the browser tries to reload only vital resources. How the web-server and browser can understand that the resources that is in the browser cache is stil valid? ETag and Last-Modified are help in that. There are not other ways how they can determine that.
5. For dynamic pages LSCWP takes Default expired
(or text/html) setting from OLS and the page is not re-requested until this
Default is expire
s. If it is empty then no cache-control is added for public cache. This setting potentially can be changed via adding a personal expire for text/html. When a user is logged into WP then cache-control appears from LSCWP with no-cache directive (it wold be better to see also private here, but with SSL it is not required).
As an example we can take a loot at the web-site that LiteCache promotes:
The page was reloaded by F5 (and previously it was opened via going to the same URL but the result is the same). As we can see:
1. text/html page is given with very strict Cache-control that urges the client's browser to check the page every time it has an urge to show it. As we can see there is 304 Code at this page.
That (recheck by the browser and resulting 304 code) can be made or via etag hash comparision or via last-modified option. In the request headers we can see both variant responces:
Which one was fired - I don't know
Also we can notices that this page also has pragma: no-cache html-control for very old browsers.
2. Going lower through the list of the resources. And we can see that all the rest resources doesn't have etag and have maximum max-age. All of them (except two resources with 204 code but they are empty) are returned back with 200 code and they were taken from the browser cache.
3. Imagine that LiteCache teammate would like to change one of the picture at the page. For example, convert the superman into a supergirl. And he just changed the picture and placed it with the same name to the same place. I will not see the updated picture until do the full reload of all the resources for one year since my last visit. And there is only one exception - he will modify the filename or add a request trail to the file.
Let's move forward and take a look at openlitespeed.org site:
The page was reloaded (F5) and we can see that the most resources are taken from the browser's cache. The main file text/html doesn't have any cache control. Also it doesn't have etag (and it was downloaded from the server).
The rest of resources have atag and cache-control. So they are downloaded from the browser cache and have code 200 (not 304).
I'll try to configure my OLS in order to get code 304 using the recipe by LiteCache but not at my prod server at firts. And I'll repeat again - there is very little way how to configure LSC in OLS.
>
Without exception, etag is only important for dynamic sources, but not for static sources, which is crucial.
I don't agree. Etag is useful for static and dynamic pages. This is one of the way how browser and web-server define the stale browser cache. Easy example
https://en.wikipedia.org/wiki/HTTP_ETag and more strict technical explaning
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag
Take into account that static files at web-server can also be changed. Especially if no CMS is used (yes, a web-site can work with just plain HTML files).
>Change the Expire settings as shown above. With the Expires Default setting, you inevitably activate the browser cache for dynamic pages,
so that requesting dynamic pages always shows stale content.
Yes, it some cases this can be useful. In other cases it would be better to avoid of storing dynamic pages with exirpes or max-age.