Caching
Faster with caching
Learn how Kirby can help you to keep even your more complex sites with lots of content performant.
Caching pages
You can enable Kirby's page cache in your config.php
file with the cache.pages
option:
The page cache files are stored in the /site/cache
folder.
Options
Option | Value |
---|---|
active |
true /false |
ignore |
Either an array of page IDs to ignore, or a callback function that returns a boolean |
Excluding pages using a page model
If you need even more detailed control over which pages are cached or ignored, you can use page models with an override of the $page->isCacheable()
method:
Automatic cacheability detection
Not all page responses can and will be cached. Kirby automatically determines whether a response is cacheable.
- Only the base response of a page is cached. If the request matches any of the following criteria, the response is not cached:
- If the request contains a query string, request data or a Kirby param
- If the request uses a HTTP method other than
GET
andHEAD
(e.g.POST
,PUT
orDELETE
)
- If the response relies on
$kirby->session()
, a cookie value (Cookie::get()
) or theAuthorization
header ($kirby->request()->auth()
), Kirby protects against sharing the cache between visitors who have these values set and those who don't. In particular, Kirby behaves like this:- If any of the queried request headers is set, the response is considered private and never cached.
- If the headers are not set in the current request, the response is cached but the cached response is only used for requests without these headers. This ensures that users with the cookie or authentication receive their own personalized response.
- If the page is excluded from caching via the
ignore
option or a page model, the page is never cached.
If your template code or a plugin you use rely on cookies or authentication but don't use Kirby's built-in methods, Kirby cannot automatically detect the usage. In this case, please call $kirby->response()->usesCookie($name)
or $kirby->response()->usesAuth(true)
respectively. You don't need to do this if you use Kirby's methods from the list above.
Cache drivers and options
Cache prefix
Each cache has its own cache prefix or namespace. The prefix ensures that different caches don't collide with each other, even if they use the same underlying cache driver.
By default, Kirby generates the cache prefix as the site's index URL and the cache's name. Here are some examples for the resulting prefixes:
Index URL | Cache name | Default prefix |
---|---|---|
example.com |
pages |
example.com/pages |
example.com:8080 |
pages |
example.com_8080/pages |
sub.example.com/subfolder |
pages |
sub.example.com_subfolder/pages |
example.com |
superwoman.superplugin |
example.com/superwoman/superplugin |
If you run your site on multiple domains and want to share the cache between all domains, you can override the cache prefix like so:
Using a different cache driver
The default cache driver is the file cache, which stores cached data in static files inside the site/cache
directory.
You can override the cache driver with the type
option. Depending on the driver, you may need to define additional options:
You can find the list of core cache drivers in the reference.
Custom caches
Defining the cache
If you want to create your own cache instance, you can just add it to the config like this:
That's it! Now you got a new cache up and running with the id api
.
This will again be a file cache instance and stores the cache files in /site/cache/api
.
You have the same extended options if needed and you can combine different cache types without hassle.
Using the cache
As soon as you configured your cache in the config, you can start using it like this (for example in a controller):
You can define how long a cache variable is valid by specifying the number of minutes until it expires in the set method:
The getter will now return null
after the 30 minutes expired.
Plugin caches
Plugins can have their own namespaced caches by defining them in their options:
This plugin cache instance will be available at:
But you can even have multiple cache instances per plugin:
Following the same concept, you can access it like this: