Website caching: fast pages that update the moment you publish
A badly tuned cache serves an old price or a page meant for a signed-in customer. So it gets switched off, and your server goes back to rebuilding every page for every visitor. Klacos keeps your pages and serves them without touching your server, with rules written for your site and a purge that clears exactly what changed. You no longer have to choose between fast and up to date.
Why so many caches end up switched off
A well-tuned cache takes load off your server and speeds up every page. A badly tuned one serves an old version of your home page, a price that has changed or a page meant for a signed-in customer. After an incident like that, people shorten the lifetimes until the cache barely does anything, or turn it off altogether.
Then you pay for it every day: a server doing the work for every visit, slower pages at busy times, and a hosting bill that grows with your traffic, bots included.
Two things are usually missing: rules that follow your site’s logic rather than a single lifetime, and a way to clear exactly what has just changed.
Decide what gets cached, and for how long
By default, Klacos follows what your server says about each response. You can go further: a rule looks at the request and the response (path, status, content type, headers, size) and decides to cache nothing, to cache for a set time, to keep serving a copy while it refreshes, or to strip a header before serving.
You also shape the cache key: which URL parameters count and which are ignored. A catalogue page requested with different tracking parameters no longer takes up one slot per variant. Pages that carry a session are still served by your server, unless you decide otherwise.
Before it goes live, you test the rule against a request: the console tells you whether the response would have been cached, and why. Caching rules live alongside your rules and redirects, with the same version history.
Clear exactly what changed
By URL or pattern
One page, a whole folder, a pattern or an expression: you clear what’s affected, nothing more.
By tag
Your pages declare their tags, in the format content management systems already use. Edit an article and every page that shows it is cleared in one go.
From your publishing tool
A purge can come from the console, the API, or a simple request from your CMS carrying the site’s token, the moment you publish.
The upshot: long lifetimes for content that doesn’t change, and a page that’s up to date the moment you publish. Unwanted bots are stopped by bot management before they reach the cache, so your server no longer renders pages for visitors who will never read them. If your server goes down, the cached copy keeps being served: the page on keeping your site online explains what happens then.
A cache you tune, page by page
In memory or on disk
Custom rules
Tested before going live
Precise purge
No wait on refresh
Tags
A cap per site
Share served from cache
Caching is part of your site’s performance and availability, alongside compression, rules and spreading traffic across your servers.
Questions about caching
Are pages for signed-in customers cached?
Not by default: a response that carries a session is served by your server. A graded setting lets you cache some of them if your site allows it.
Can I purge from my CMS?
Yes. A purge request carrying the site’s token clears a URL, a folder or a tag at publishing time. The console and the API do the same.
What happens while a copy is being renewed?
Your visitors get the previous copy while the new one is prepared. Nobody waits for the server.
My server already sends caching headers. Are they respected?
Yes, by default. A rule can add to them or override them for a path or a content type.
Try your caching rules in simulation before you apply them
Request early access, or tell us about your site, what slows it down and how you publish.