Category pages are the workhorse of an ecommerce store. They are also, on any catalogue past a few thousand products, the first thing to buckle. If one page type on your store is noticeably slower than the rest, this is usually it.
The reason is layered navigation. A category page with filters is not one page. It is every combination of filters a visitor might choose, each of which is a separate result set that has to be produced and cached. That changes the maths considerably.
1. The search engine is doing the work badly
Modern Magento uses OpenSearch or Elasticsearch for catalogue queries, including filtering. When it is configured well this is fast even on large catalogues. When it is undersized, poorly tuned, or falling back to the database, it is not.
The symptom that gives this away: the category page is slow specifically when filters are applied, and fine without them. That points at the search layer rather than at rendering.
2. Cache fragmentation
Full page cache works beautifully for a page with one version. A category with eight filters has an enormous number of possible versions, and most of them will be requested once and never again.
The result is a cache that is technically working and practically useless: high memory use, low hit rate, and every visitor who touches a filter getting an uncached page. Fixing this is usually about reducing what is filterable rather than about buying more cache.
3. Indexing that has fallen behind
Category product listings, prices and stock all come from index tables. When those are stale or being rebuilt during business hours, category pages get slow and occasionally wrong: products that should not be there, prices that do not match the product page.
On large catalogues this becomes a scheduling question rather than a configuration one. Reindexing has to happen, and it should not happen while your customers are shopping.
4. Too much on the page
The least technical cause and often the largest single win. A category page showing 60 products, each with a swatch selector, a stock indicator, a wishlist button and a lazy-loaded image, is doing a lot of work per product.
Halving the page size to 24 or 36 products with pagination is not a compromise if visitors rarely scroll past the first dozen. Your analytics can tell you where people actually stop, and that number is usually lower than the page length.
How to tell which one is yours
- Slow only with filters applied: look at the search engine first.
- Slow on the first visit, fast afterwards: cache is being missed or fragmented.
- Slow at particular times of day: reindexing or cron overlapping with traffic.
- Slow everywhere and consistently: page weight and rendering, so count what is on the page.
These are not mutually exclusive and large stores usually have two of them at once. But the pattern above will tell you which to look at first, and starting in the right place is most of the work.