Start with the category journey that is actually slow
A Magento category page can appear quickly and still be difficult to use. The product grid may arrive late, selecting a filter may freeze the page, or changing the sort order may start another long request. Calling all of these problems “slow categories” hides the evidence needed to fix them. Our starting point is the exact action: which category, which filter, which customer group and which device?
Choose a busy category and a smaller comparison category. Record the initial visit, one useful filter combination, the next results page and a change of sort order. Include a product with variants if that is how customers normally shop. A homepage score cannot tell you whether these journeys work well. Equally, one unusually large category should not be used to describe every part of the store.
Separate the server wait from the browser work
For the first category request, identify when the HTML begins arriving and when the product list becomes usable. A long wait for the response points towards work before rendering reaches the browser. A fast response followed by a delayed grid points towards assets, JavaScript, layout or a later data request. An extension may change this division, so inspect what the installed storefront actually does.
Repeat the same journey with a comparable device and connection. Note whether the response was served from page cache; a first visit and a repeat visit are different tests. Do not report only the quickest warm response. If initial response time is the main concern, our high TTFB guide explains how to organise that evidence before changing infrastructure.
- 01ChooseCategory, filters, sort and shopper state
- 02SeparateServer response from browser rendering
- 03TraceCache, query and extension evidence
- 04VerifySpeed and correct catalogue behaviour
Understand what filters add to the request
Layered navigation helps shoppers reduce a large catalogue to a manageable choice. Its work depends on the category, eligible products, attribute configuration, price rules and installed search or navigation extensions. Adobe documents that large numbers of attributes and attribute options can affect catalogue browsing and filtering performance. That is a reason to measure the relevant workload, not a reason to remove useful filters indiscriminately.
Compare the unfiltered category with one selected facet and then a realistic combination. Record the products shown and the counts as well as the timing. A response that becomes fast by showing incorrect availability or misleading prices is not a successful improvement. Standard layered navigation, Adobe Live Search and third-party navigation modules have different implementations; a configuration tip for one may not apply to another. If the same products are missing or slow in search results, follow the Magento search troubleshooting guide to distinguish eligibility, indexing and response-time problems.
Ask which filters customers genuinely need. A merchandising decision to expose hundreds of options can affect usability even when the backend is healthy. Conversely, hiding a filter may make a test faster while forcing shoppers to inspect many more products. Agree the commercial requirement before using the number of visible filters as an optimisation target.
Check cache behaviour across realistic page variations
A category URL is not the whole identity of a response. Store view, currency and customer context may affect what can be shared safely. Filters, sort order and pagination can also create many requested variations. Investigate the supported cache behaviour for the actual application and proxy, rather than assuming every request should have the same hit rate.
Look for a repeatable relationship between an expensive request and a cache miss. If repeated visits still rebuild the whole page, follow the full-page cache diagnostic. If the slowdown follows broad purges or imports, review cache stampedes. Never make private pricing or basket state publicly cacheable to obtain a better performance result.
Use a comparison sheet before changing configuration
The following worksheet is deliberately small. It should help a developer reproduce the business problem without requiring a merchant to collect every possible metric. Times should be measured in the same conditions and attached to a dated observation. Blank cells mean evidence is still missing, not that a component has passed.
| Sample | What it can reveal |
|---|---|
| Simple category | Baseline navigation without extra filtering. |
| Large category | Catalogue size, sorting and query differences. |
| Filtered result | Layered navigation, extensions and search work. |
| Customer-specific view | Pricing, permissions or private state. |
| Repeat visit | Cache behaviour under comparable conditions. |
An illustrative example: an unfiltered category is responsive, but choosing two facets makes the results request much slower. The investigation should follow that filtered request and its underlying work. It should not begin with compressing the site logo simply because an automated report mentions images. This is an example of reasoning, not a measured Midoriweb client result.
Inspect product cards and third-party additions
Category pages repeat a product-card component many times. A seemingly small operation inside each card can accumulate: availability checks, review data, additional price calculations or remote information. Profiling should establish whether the work repeats and whether a supported batch or cached approach can preserve the correct result. Avoid replacing a measured query problem with speculative server upgrades.
In the browser, inspect image dimensions, discovery order and unnecessary interaction scripts. Do product cards reserve space while images load? Does a filter update trigger duplicate requests? Do analytics, personalisation or review widgets initialise repeatedly after each grid refresh? The third-party JavaScript guide covers separating essential behaviour from avoidable work without breaking consent or measurement.
Define a useful acceptance test
Agree which category journeys matter, a representative sample and comparable before-and-after conditions. Verify filtering, sorting, pagination, customer-group pricing and the route into a product and basket. Include empty results and a category with a larger catalogue. Test at least the affected mobile and desktop layouts; avoid declaring success from a backend timing alone.
Where traffic changes the symptom, include that fact in the investigation brief. A quiet staging response cannot prove peak capacity. A separately scoped load test may be appropriate, with a representative environment and explicit stop conditions. Do not point a high-volume test at production just to reproduce a slow category.
Choose the right next step
If the store is trading but category performance remains unexplained, a Magento Performance Investigation can turn selected journeys into a prioritised evidence-based plan. Include the affected URLs and filters, the most recent relevant changes and the time periods when the problem is worst. Public-page assessment and an internal investigation provide different depths; choose the scope that can answer your actual question.
If category failures prevent customers reaching products during an active incident, use the emergency support route. Explain the business impact rather than choosing a package solely because the visible symptom contains the word “slow”.
Common questions
Should we disable layered navigation to make categories faster?
Only as an authorised, reversible diagnostic in a suitable environment, or an explicitly agreed temporary containment. Filtering may be essential to conversion. First establish whether it causes the observed delay and what functionality the business must retain.
Does adding more server memory fix slow categories?
It can help when measured memory pressure is the constraint. It does not automatically remove expensive queries, repeated card calculations or unnecessary browser requests. The evidence should connect the proposed capacity change to the bottleneck.
Can a public performance check explain the database cause?
It can show externally visible timing and request behaviour. It cannot directly inspect internal query execution or prove a particular module caused it. Internal access and profiling require the appropriate agreed investigation scope.
Technical references
Use the documentation that matches your installed version, payment provider and deployment.