This is really a wide question so I’m open for all kind of suggestions.
I’m converting a site from WP to Kirby, making use of my bought licenses.
The slow part of my site looks like this:
It’s quite static. It will not change much in time but the rest of the site will. Therefor I came up with the idea that I could cache just this part of the page.
Why it’s slow
I’m parsing a large blueprint and it takes time. Then the data is used to display in the table above.
To know what I’m after here are some sub questions:
Is it a good idea to cache just a part of a page?
Would it be best to cache as html or some kind of query cache?
You can use the cache class to cache the data you parsed from the blueprint (this code belongs in a controller):
$data = cache::get('cachekey');
if(!$data) {
// get data somehow
$data = somefunction();
// cache it
cache::set('cachekey', $data);
}
return compact('data');
Please note that you need to enable the cache so that Kirby can store the data in the site/cache directory. You could however use c::set('cache.ignore', ['*']); to disable the page cache.
if its slow and almost static. yes cache it. but beware the root of evil.
i am identifying timesinks in code myself on localhost using xdebug timstamps. so stuff pops up like its not a good idea to create $site->index()->filterBy() if one has a content folder with 10k+ pages every page load. just iterating with a for loop and storing the resulting uris (which is static result for 1-2h) in a cache was way faster.
@lukasbestle I made a quick test now in a snippet just to see how it works and it does. First I was wondering how to clear the cache with the cache key but then I realized that I only needed to set it again to overwrite it. I might reset the cache once a week or if something else trigger it.
I also like the built in approach.
@bnomei Thanks! If I have trouble with the built in solution yours are probably a neat alternative.
root of evil
Yes, I always have in mind to optimize the things I code. In this case I could make it 5 times faster but even if I do, it’s still too slow and I know that all the parsing is the bottleneck and I still need the parsing.
Cache expiration is always difficult. Your current solution won’t update the cache once the original data is changed. So you either need to clear the cache manually to rebuild the information or use the expiration time param for cache::set(). Best would be to check if the blueprint changed (filemtime()), but if it doesn’t change often, one of the other ways would have a better performance.