Blog Sections Open
Reducing Page Generation Time in Large Evolution CMS Projects
A performance checklist for Evolution CMS pages that feel heavy long before the HTML is even delivered to the browser.
When an Evolution CMS page becomes slow, the real problem is usually not one dramatic bug. It is the accumulation of small expensive operations: repeated API calls, large TV lookups, deep menu builders, and snippet chains that rerun almost the same queries over and over.
The source discussion came from a project with thousands of resources, many API-driven lookups, and heavy frontend logic. That combination is exactly where Evo performance work needs to be structured instead of reactive.
Where the time usually goes
- Multiple calls to
getDocuments,getDocument, or similar API helpers inside loops. - Repeated TV access when the data could be fetched once and reused.
- Menu builders such as Wayfinder traversing large trees repeatedly.
- MultiTV or gallery output that forces extra parsing work on every request.
- Uncached snippets on pages that mostly show stable content.
Start with measurement, not guesswork
Before replacing components, list what the page calls and how often. If one template runs several large snippets, comment them out one by one and measure the impact. On older Evo builds that is still the fastest way to see whether the bottleneck is the tree, TVs, or presentation logic.
Reduce repeated document API calls
If the same resource set is fetched several times in different chunks or snippets, consolidate that work. A single preloaded result passed into template placeholders is almost always cheaper than many small API calls scattered across the page.
Prefer narrower queries
Ask for only the fields and TVs you really need. Pulling whole document records for large result sets wastes time and memory, especially on catalog pages.
Cache where the data is stable
Not every page can be fully cached, but many blocks can. Menus, static related links, category sidebars, and image-heavy sections are strong candidates for partial caching. The goal is to avoid regenerating identical structures on every request.
Think in layers
In real Evo projects page speed is often improved by cleaning up the rendering pipeline rather than swapping out one snippet. Fewer deep tree traversals, fewer repeated TV reads, and fewer document API calls usually give a bigger win than a cosmetic template rewrite.
Working with 10,000+ Documents in the Evolution CMS Tree
How to keep large Evolution CMS projects manageable when the resource tree grows past ten thousand documents and tree generation starts hurting performance.
Fixing “No multiTV Definitions Set” After Installing MultiTV on an Evolution Build
What to check when MultiTV is installed but the manager reports that no definitions are available for the configured input.