-
Notifications
You must be signed in to change notification settings - Fork 1
Description
In config/statamic/assets.php there is a cache setting.
When disabled, rendering an Entry will be fast, but each image src will require a PHP process to get the image - and will do one of these two things:
- if the image has been rendered, will return it from Statamic's internal Glide cache within
storage, or - if the image has not been rendered, will render it, place it in the
storageGlide cache, and then return it
If a page has 10 images that need to be loaded, that's 10 requests, 10 PHP processes. After the initial render (which is the time-consuming step), it is better, but on high traffic sites can create bottlenecks with using many PHP processes for a single page load.
When cache is set to true, every Glide URL gets rendered during template render, and placed in the cache_path output folder. A single page with 10 images, each having 5 x jpg and 5 x webp versions, plus the fallback image, gives you 11 images needing to be rendered per image - that's 110 images for this example. These images are rendered during the render, meaning the page is blocked from even rendering to the user - and if there are memory or time restrictions, could even fail to load.
There are presets that can be rendered (and done behind the scenes)... but presets can limit flexibility for some site design use cases, and also eat up huge amounts of space for unnecessary transformations that may never be used for a specific Asset.
A hybrid approach to image caching has potential to get the best of both worlds - but would require server configuration like Full Measure Static Caching.
The basic gist in my head would be for a server rule looks if an actual asset exists (such as (my lovely fake filename) public/img/the-cached-asset.jpg), which would have one of two outcomes:
- if the image exists, the server serves it immediately with no PHP process needed
- if the image does not exist, it passes it back to a PHP process
This is the same sort of logic as full-measure Static Caching: if the rendered html file exists, it gets served process-free, if not, passes back to Statamic.
Given that is the gold standard in performance for Statamic sites, a hybrid approach would be phenomenal at improving performance of assets.
I have done something similar with hybrid OG images based on entry content (and rendered using Browsershot). But this doesn't even use a server rule for NGINX, it just outputs a public OG image URL - and if it doesn't exist, a Laravel route renders it and saves it to the public OG folder.
I appreciate that server config can vary between NGINX, Apache, IIS, and now Laravel Cloud too. And for some this may not be a valid pathway... but also full measure static caching could be argued at not being valid for some of these too. But the key point here is that full measure caching makes complex Statamic sites be lightning fast. Adding that same level of performance to Assets would be next level.