Why a Catalog Slows Down After 500 Products in Evolution CMS

A catalog can feel fine at fifty products and suddenly become heavy at five hundred. That does not always mean Evo has hit a hard limit. More often it means the current query and TV strategy was acceptable at small scale and is now being asked to do too much on every request.

The source project used DocLister for catalog output, which is a solid choice, but even good listing tools become expensive if each product card pulls too many fields, images, and related values.

Where to look first

• How many TVs are loaded for every product card.
• Whether product images are generated dynamically on every request.
• Whether filters or sorting trigger extra passes through the same dataset.
• Whether uncached blocks are rebuilding large product lists repeatedly.

Why “500 products” is a warning sign, not the real cause

The count itself is not the issue. It only reveals that the current output strategy does not scale well. A lean query can handle far more than that; a noisy one can struggle much earlier.

Practical fixes

Reduce the number of TVs loaded per card, cache stable catalog fragments, pre-generate where possible, and avoid expensive logic inside row templates. If filters are needed, make sure they narrow the dataset before the heavy rendering work begins.

The goal is not just faster SQL. It is a lighter rendering pipeline from query to HTML.