Modules that slow the store down

The three ways a module costs time

Database queries. A module hooked into product display that queries the database once per product turns a category page into dozens of extra queries. That design mistake, a query inside a loop, is invisible on a demo store and shows up as soon as the catalogue grows.

Assets loaded into the page. Every module that adds its stylesheet and its script weighs down all pages, including those where it is useless. A comparison module loading its assets on the payment page is the typical example.

Outbound calls during rendering. This is the most expensive and the most insidious: a module that queries a third-party service while building the page makes the visitor wait as long as that service takes to answer. The day the service is slow, your store is slow, with nothing having changed on your side.

What I do once the module is identified

Rarely a plain uninstall: the module provides a service, and removing it moves the problem into daily operations. Three fixes give measurable results. Restrict asset loading to the pages where the module is genuinely used, which is handled in its code without touching its function. Cache the result of outbound calls, so the third-party service is queried periodically rather than on every visit. Replace a query inside a loop with a single query, which is the most profitable fix when the catalogue is large.

When none of those three is possible because the module is encoded or locked by its licence, the question becomes a choice: replace the module, or accept its cost. I say so plainly rather than billing for an optimisation that cannot succeed.