The plugin was not slow. The query it hid was.

The complaint arrived the way these always do: “the site got slow after the last update, can you look today.” Eleven seconds to render a category page, on a shop doing real money. Everyone had already agreed on the culprit — a filtering plugin installed a month earlier — and someone had already tried the obvious fix of deactivating it, which made things worse in a different way.

Before touching anything I turned on query logging for a single request. That is usually the whole job. The page ran just over four thousand queries, and roughly three thousand nine hundred of them were the same lookup with a different ID: one query per product, per attribute, inside a loop that nobody had written on purpose.

The plugin was not generating those queries. It was asking a perfectly reasonable question, once per product, of a data layer that had no idea it was being asked four thousand times. The plugin author had assumed a small catalogue. The client had eleven thousand products.

The fix took two hours and about forty lines: prime the attribute data in one query before the loop, hand the plugin a cached array instead of a live lookup, and add a guard so the cache is skipped when the catalogue is small enough that it does not matter. Page render went from eleven seconds to under one. No plugin was removed, no template rewritten, nothing for the client to relearn.

What I would take from it: when a site slows down after an update, the update is usually the trigger, not the cause. Something inefficient was already there, tolerated at a smaller scale. Find the loop before you find someone to blame — and resist the urge to rip out working software under time pressure. A deactivated plugin is a new problem wearing a solved problem’s clothes.