A store with a hundred products is fast on any engine. The real test starts when you upload a supplier’s full price list: tens and hundreds of thousands of items, each with prices, stock, attributes and photos. This is exactly where most platforms start “thinking” for several seconds on every click. We reworked how the Turboshop storefront talks to the database and builds pages, and verified the result on catalogs of up to 300,000 products. Here is what changed and why it matters for sales.
Why catalog speed is money
Shoppers do not analyse technical specs — they simply leave when a page stalls. It shows up most on three scenarios that happen constantly on a large catalog:
- opening a category with thousands of items;
- applying a filter or sorting — shoppers expect a marketplace-grade instant reaction;
- clicking “Show more” when products load in batches.
Add mobile connections to that and every extra second turns into a bounce. Speed also feeds SEO directly: search engines factor page speed and page experience into ranking, and on large catalogs they also budget their crawling time — a slow store is simply indexed worse.
What exactly we did
This is not a single “speed switch” but systematic work on three levels at once.
1. Reworked how the storefront uses the database
The storefront stopped doing redundant work: where a page used to ask the database the same thing several times, there is now a single query; where the database had to scan the entire price list, there is now a storage structure that leads straight to the rows it needs. The gain is largest exactly where it used to hurt most on big catalogs: availability checks, price ranges and product counts in filters.
2. Made batch loading lighter
The “Show more” button no longer drags redundant data between the browser and the server. Previously every click sent the entire accumulated product list over the network — the further a shopper scrolled, the heavier each next step became. Now the page keeps only a list of what has already been shown, and cards appear at a steady pace: the fifth batch loads as fast as the first.
3. Made page rendering cheaper
Every product card in a listing means dozens of small operations: a link, a template, a price, a wishlist button. On a grid of 48 cards those details multiply. We removed the repetitive work that used to run for every single card — pages are assembled noticeably cheaper and the server handles more concurrent visitors.
300,000 products — and the storefront keeps up
We tested the platform on catalogs of up to 300,000 items: categories with thousands of products, filters with many values, batch loading and product pages. The storefront stays fast — and that was exactly the goal we set: not “it kind of works”, but rendering and displaying without delays, like on a small store.
In practice this means you do not have to trim your assortment for the sake of speed. You can upload a supplier’s full price list, keep every variant and size, run several price types — the storefront will handle it.
Who benefits most
- Dropshipping. You work with someone else’s price lists and do not control their size: 20,000 items today, 200,000 tomorrow. The store has to survive both;
- Wholesale and B2B. Large nomenclature catalogs with dozens of attributes per item — and customers who search with filters, not with their eyes;
- Auto parts, fasteners, electrics, building materials. Niches where “many similar small items” is the norm;
- Multi-vendor assortments. Several suppliers, each with their own nomenclature — the catalog grows faster than you expect;
- Any growing store. The speed problem does not arrive on launch day — it arrives in year two, when the assortment has grown tenfold.
What the store owner has to do
Nothing. The speed-up ships with the platform update — no settings, no theme edits, no developer. Your store simply starts working faster on the same data.
A few things still worth keeping in mind on a large catalog:
- fill in attributes and custom fields — they power the filters, and on a large catalog filters matter more than search;
- keep an eye on the category structure — shoppers should not scroll 5,000 items inside one category;
- do not be afraid of the full price list — trimming the assortment “so it does not lag” is no longer necessary.
FAQ
Is there a hard limit on the number of products? There is no artificial limit. We deliberately tested catalogs of up to 300,000 items — the storefront runs without slowdowns.
Do I need to enable anything to get the speed-up? No, it arrives with the platform update.
Will it change my store design? No. Nothing changes visually — what changes is how fast the page appears.
Will it help SEO? Speed is one of the factors search engines take into account, and a behavioural factor at the same time: fewer bounces, more pages viewed. No magic is guaranteed, but the SEO foundation gets healthier.
What about filters on a large catalog? They are faster too: product counts next to values are computed in a single query and cached — see the article on filters with product counts.
What if my catalog is larger than 300,000 items? Get in touch — we will look at your price list and catalog structure together.
Summary
A fast storefront is not a nice-to-have — it is the condition under which a large assortment makes sense at all. We reworked database queries, batch loading and page rendering so that a store with hundreds of thousands of items opens and filters as easily as a store with a hundred. Nothing to configure — it all works right after the update. Explore more platform capabilities in the “Features” section.