Blog Sections Open

Reducing Homepage Overhead When Multiple Ditto Calls Compete on One Page

A performance-minded article about homepage layouts that overuse parallel Ditto listings.

One common old-Evo performance problem was the homepage that grew by accumulation: one Ditto for a slider, one for service blocks, one for news, one for something else, and suddenly the first-screen rendering felt visibly heavy.

This case is valuable because it captures that exact moment. The homepage was clearly doing too much work, and the right response was not only “optimize one snippet call,” but “rethink how many independent content queries the page really needs.”

Why this belongs in Best Practices

  • it documents a real homepage performance smell
  • it reinforces the idea that snippet composition has architectural cost
  • it fits the historical shift from “it works” toward “it scales cleanly” in Evo projects

Why this matters historically

Homepage performance problems in Evolution CMS often came from composition, not from one obviously broken snippet. Posts like this are valuable because they document the moment when teams started treating multiple Ditto calls, teaser blocks, and homepage widgets as a shared render budget rather than as isolated template fragments.

Related posts

Caching Dynamic Snippets in Evolution CMS Without Losing Dynamic Output
Diagnosing Slow Page Loads on Large Evolution CMS Sites with Ditto and YAMS

Newer post

Do You Really Need PHx in an Evolution CMS Project?

A reflective legacy note on when PHx was useful, when it added overhead, and why many of its everyday jobs could be replaced by simpler snippets.

Older post

Choosing the Right Date Field for Sorting Resources in Evolution CMS

A clear best-practices article about why `createdon`, `publishedon`, and `pub_date` are not interchangeable.