Set 2 different TTL for Public Pages




Wordpress LScache Plugin: Set 2 different TTL for Public Pages

Last Updated on: Wed, 15 Apr 2026 00:00:02
Hi, my wordpress website (approx 5000 pages currently developing on localhost) behaves pretty much like a static website, every page is exactly the same for every user, theres no login feature and no personalized pages. I can cache everything in Public Cache with 604800 TTL and thats perfectly fine, BUT, I have a bunch of pages (approx 100 pages) that I absolutely have to set at a 1800 TTL (30 minutes). How do I do this? I was thinking about putting these 100 pages urls into the Private Cached URIs box to have them cached as private, and set the TTL for Private Cache to 1800, but Im not exactly sure about what might happen. Lets say in that 30 minutes timespan a thousand visitors visit a specific page in this 100 pages group (lets call it page number 3): Will I have this specific page being cached for every visitor, ending up with a thousand page number 3 being created (not what I want), or will I have this specific page being cached just one time and served to all the thousand visitors (exactly what I want)? Basically I want to have Public Cache behaviour for all the pages in my website (same cached page being served to all the visitors with 604800 TTL), but I need 1800 TTL for a special group of pages that are exactly like the other pages, but only differ due to the fact that need a 1800 TTL. Im waiting for a reply and thank you in advance for your help and support. Hi, @jmtb89 May I ask why you need a TTL of 1800? Setting a different TTL for a subset of pages is not a trivial task, but there may be some other way to achieve what you need, if we can understand the why. FYI, in case you didnt realize, LiteSpeed Cache is smart enough to purge a page from cache when the content on it changes. So if those 100 pages are changing frequently, and are doing so within the WP framework (i.e., you dont have some customized way of changing the content outside of WP), then they should be accurately purged as necessary, without requiring a shorter TTL. If you do have some customized code changing the content, You might be able to use our API to do what you need. But first, it would be helpful to know the scenario so we can make a relevant suggestion Hi Lisa and thank you so much for your reply, so basically I have a classifieds website (Im using the plugin WP Job Manager) with approximately 5000 single listings and 100 listing pages (where all the listings appear), the website has no login feature and no personalized pages, everything is managed by two wordpress administrators. Each one of these 100 pages randomly displays the listings belonging to a certain WP Job Manager category using this WP Job Manager shortcode in the page: [jobs categories=my-category show_filters=false orderby=rand], so without a cache the listings get reshuffled at each page refresh. Public Cache with 604800 TTL is perfect for the 5000 single listings, but if I have the same TTL for the 100 listing pages then users would see the same listings placement with no reshuffling for 604800 seconds which is too much, hence the need for using a much shorter TTL for these 100 pages, 1800 seconds would be perfect so users would see a new randomly reshuffled placement of listings every half an hour. I hope this clarifies a bit, waiting for a reply and thank you so much for your support. Hi, If it is using shortcode , then please check this wiki Basically , in your case, enable ESI in LSCWP , and change the shortcode from [jobs categories=my-category show_filters=false orderby=rand] to [esi jobs categories=my-category show_filters=false orderby=rand ttl= 1800 ] then the whole section created by this shortcode will have separated cache with different TTL. I hope this does what you want to do. Best regards, Hi, thank you for your reply, I didnt know about this feature, it looks like a great solution for my necessity, Im going to try this as soon as I transfer the website on the server. I was also thinking about another solution: since the pages that need a 1800 TTL represent 90% of the total WordPress Pages on the website, I was thinking about the possibility of using a cron job to trigger the Purge Pages ? This will Purge Pages only command in LiteSpeed Cache Management ?>> Purge Tab. Is there a way to trigger this command via a cron job every 30 minutes? Wouldnt this solution be lighter on server resources than using ESI? Basically it would be like pushing that button every 30 minutes via cron job, please let me know and thank you so much for your help, I really appreciate. Hi, Apologize for late response, How is that ESI solution for you ? About cron , if you can do CLI , this wiki might be helpful. Best regards, Hi, thank you for your reply, I havent tried the ESI solution yet, as Im still finishing building the website on localhost with wamp, but Im going to try this as soon as I transfer the website on the server. However, I may have found yet another solution: Ive just noticed the Force Cache URIs box in Settings->>Excludes Tab and it states like this: Paths containing these strings will be cached regardless of no-cacheable settings?.. To define a custom TTL for a URI, add a space followed by the TTL value to the end of the URI So I was thinking about entering all the 100 pages that need 1800 TTL this way: mywebsite.com/mypagea 1800 mywebsite.com/mypageb 1800 mywebsite.com/mypagec 1800 mywebsite.com/mypaged 1800 ?.. -Do you think this will work? -And if yes, will this solution be less resource intensive than using ESI? -And most importantly, will these pages be cached publicly or privately? I guess (and hope) they will be cached publicly, Im asking you because this is not specified in the text under the box. Waiting for a reply and thank you so much for your help and support. Hi, To answer your question , I just made a test. It will serve public cache to guest user and private cache to login user. but since you dont have login , I guess it doesnt matter to you anyway Best regards,



LiteCache Rush: Speed comes from using less, not from doing it faster



Reference