A surgical technologist opens the catalog on her phone, in the hallway outside the operating room, and checks “knee” in the anatomical region filter. The screen stays blank for a couple of seconds. She checks “arthroplasty” to narrow it down and waits again. In the Marketing office, nobody complains about the catalog's speed, because from there the whole site takes about the same time to load.
That gap between what the team sees and what a visitor sees is the first clue.
What caching does, in plain terms
Every page on a site with a content management system is built when someone requests it: the server queries the database, gathers the products, applies the template, and returns the result. With a large catalog, that takes time. The cache stores the finished page and serves it, ready to go, to the next person who requests the same thing, in a fraction of the time.
Anyone who logs in with an administrator account always gets the page built on the spot, so they can see the changes they just made. That's why, from the dashboard, the home page and the filtered catalog take about the same time, and the slowness a visitor experiences in one part of the site can't be told apart. Any speed test is run logged out, in a browser nobody from the company has logged into.
Why filters complicate things
In a medical device catalog, each filter combination produces a different URL: humerus plates, titanium humerus plates, humerus plates from one brand. For the cache, each URL is a different page that has to be stored separately. With five navigation dimensions (area of interest, anatomical region, product type, procedure, and brand), there are thousands of possible combinations.
Faced with that, many sites leave filtered views out of the cache, sometimes because of a rule someone added to solve a one-off problem. As a result, the part of the site people use most to find a product is the part that gets built from scratch with every click.
At SAI: 2.6 seconds per click
SAI, an Argentine orthopedic manufacturer and distributor, has a catalog of nearly 270 products with those five navigation dimensions. A server resource-usage alert led the review to the filtered catalog, which was being built on the fly 13,114 times a day. Filtered views weren't going through the cache: a rule prevented it, added earlier to keep one brand's results from mixing with another's.
Before touching it, we confirmed that the reason no longer existed: the site's cache stored one version for each URL and served the right one. With that confirmed, the rule was changed so views with a single filter are cached. That's where most real clicks happen, and the number of pages to store stays manageable. Combinations of two or more filters are still built on the fly, on purpose, and so is site search.
- Catalog view with one filter2.6 s0.18 s
The check was done logged out: five rounds with three different filters. All fifteen responses came from the cache, and each filter showed its own products, with no mixing between brands, which was the risk that had justified the original rule. Undoing the change only takes editing a single character, which made it possible to test it on the live site, with real traffic.
Measure properly before fixing
The first suspect in a slow catalog is usually the filter: too many database queries to decide which products to show. At SAI, that part was optimized too, and the improvement was small. The comparison that pointed to the filter was pitting a page served from the cache against one that couldn't be. Under equal conditions, both took about the same time to build. The cache was what made the difference.
There's a second trap in measurement. When the server is in another country, much of the time measured from the office is the round trip, which no adjustment to the site can fix. Before blaming the code, we separate how long the server takes to respond from how long the response takes to arrive.
What to ask if the catalog is already slow
Rebuilding the site is rarely the answer. Slowness is usually in one specific layer, and these questions help identify it quickly:
- Is the filtered catalog served from cache? Check in a logged-out test by comparing the first request for a view with the second.
- Is there an old rule blocking it? If so, the next question is why it was added and whether that reason still exists.
- Which filter combinations do people actually use? Site analytics show which ones, and that determines how many are worth caching.
- Can the change be undone in minutes? If not, it isn't tested on the live site.
Services covered in this article
