Comment on page
Building a frontend website which dynamically reads data from multiple external APIs can cause performance issues. Reading data from multiple data sources results in a new HTTP request for each API call, with an external web application generating content for each API call.
While some external data calls may cache repeatedly requested data, it's good practice to cache this on the frontend website side.
It is generally considered good performance to cache commonly requested content, to speed up future requests for users. However, caching adds a layer of complexity, so it's important to do this with care.
It's recommended to add caching in small steps, measuring the difference in page load speed as you add a cache layer.
Full-page caching is commonly used to cache the entire page content. This is really useful if your page content is the same for all users (which is very common for most websites). There are techniques that can be used to serve personalised content alongside shared, cached content.
Data caching can be used to cache individual data responses. This is useful if you have any data requests that are shared across multiple pages. If the data request is unique for the current page, then full-page caching is a more effective way to cache the current page content.
Full-page caching (also known as HTTP caching) caches all page content (and usually request headers) for the current page. Most page content is common to all users, so this approach tends to work very well.
It's important to remember the entire page content and headers are cached with this approach. This means any data sent over the response headers is also shared, so be careful about using things like PHP sessions or CSRF tokens.
To enable caching the right caching response headers need to be passed.
TODO - add example code
TODO - check the code examples
First pass a PSR-6 compatible cache adapter to the setCache() method to enable caching. It's recommended to use a cache that supports tagging.
You can do this either on a query manager object (
Strata/Data/Query/QueryManager) or directly via the data provider object (implements
This sets and enables the cache for all subsequent data requests.
To cache data simply set the cache and then make your data request:
$response = $api->get('my-data');
If the response is stored in the cache, then the cached version is returned. Cache items are stored based on the URI and query options (defined in
You can confirm if a response is from the cache via:
$cacheHit = $response->isHit();
You can also disable the cache for future data requests:
And re-enable it again when you want to use it:
By default, all GET or HEAD requests are cached for one hour. You can specify custom cache lifetimes when enabling the cache:
TODO use cache tags to help clear cache on URL or data request type
You can add tags to all data cache requests via:
TODO Craft CMS
Please note clearing the entire cache is not recommended to do often, but it can be useful in development.
The data cache is saved in the
var/cache/folder. To clear the application cache, run:
php bin/console cache:pool:clear cache.app_clearer
This does not clear the HTTP Cache. If you have this enabled locally, you can clear the entire HTTP Cache by running:
rm -Rf var/cache/prod/http_cache`
Please note the default
cache:clearcommand only clears the system cache which includes Twig templates, but not the application cache.