The Tradeoffs in Time and Space
"Why does the third page of my sapphire fashion rings take so much time to load?" I'm glad you asked, because this means that for today's dev dive, we can talk about one of the most frequent decisions that developers have to make when creating a piece of software.
Pulling a list of products, with different filters for brand, category, size, etc. can be a lot of work for a server. That's for two reasons: it requires a pretty complex set of operations, and there are tens or even hundreds of thousands of products to parse through. This is what computer scientists call "time complexity." Some algorithms can run in a constant amount of time regardless of how much they need to look through, but others can take exponentially longer if looking through larger data sets. Pulling products is closer to the latter - when data sets grow, so does the time it takes to run the same pull on those products.
But let's say, hypothetically, that instead of trying to do all that processing every time, you want to pick your most important jewelry categories and make those load as fast as possible. Once you’ve done the processing once, rather than making the server keep doing that work over and over, you could instead cache the results. Then, when the server needs that list of products again, it can immediately grab those previously found products and return them much faster. There's a catch, though - there are hundreds of thousands, or even millions of ways that users may want to filter your products, and it's simply not feasible to store every single one of those results. In computer science, we call this "space complexity" - how much memory are we willing to use in order to reduce the processing that we make the server do?
On your website, we default to storing results for all of the base brand and category grid pages so that users browsing have the most responsive experience possible. Once users add a certain number of filters or go past a certain number of pages, however, we start to pull from the database again rather than using those cache files, so that the server doesn't run out of storage. This is because most of the views on your grid are on these higher-level pages, so making them as fast as possible will improve the UX for almost every user.
This tradeoff between time and space is a fundamental issue in computing, actually. It can be seen in cache files on your website, storing variables in code - even your CPU has cache that it can use to save time! Unfortunately, it's never possible to optimize both; it's always a give and take.