How to Optimize Grav for Large, Cloud-Hosted Content Libraries

1

Hello

I am working on a Grav-based site that hosts a large content library thousands of pages with images, videos & downloadable resources.:slightly_smiling_face: While Grav handles smaller sites well, I am seeing slower load times and heavier server usage as the site scales. :innocent:

I would like to explore strategies for optimizing Grav for cloud hosting environments so it can handle high traffic & large datasets efficiently.:slightly_smiling_face:

Possible approaches include using a CDN for static assets; implementing smart caching strategies / splitting content into modular sections that can be loaded on demand. :innocent: While researching cloud infrastructure options, I came across the role of a cloud architect and wondered what is cloud architect in the context of designing a CMS deployment that balances speed, cost & scalability? :thinking:

This could be an interesting angle for Grav developers working on enterprise-level projects.

Has anyone here built a large-scale Grav deployment in the cloud and found effective optimization techniques?:thinking: A good starting point might be the Grav Performance & Caching Guide, but I would love to hear real-world experiences and configurations that worked well for demanding sites.

Thank you !!:slightly_smiling_face:

2

Hello, i have a little experience but since noone gave a reply i think what i write may help a little more than zero:)

if it has thousands of pages, why not split it to smaller parts?
Do you know multi-site?
multi-site and symlink help nicely.
if we knew more info about your website maybe we could suggest more things.
lets say you have example.com
example.com/group1 has 600 pages under it
example.com/group2 has 800 pages under it
example.com/group3 has 1600 pages under it
you can create separate installations for group1, group2, group3.
i wonder if that would reduce pressure on some files that runs for each page load.
similar things can be used for cache too.
to cache grav needs to run all twig in templates, but if group1, group2, group3 has different templates they dont need to be cached together so by separating them we also separate their caching i guess. but if they have same templates that would not work and be time consuming.
etc. etc.
in short my suggestion is multi-site strategy :slight_smile: