Working alongside Yehor Shytikov, we took on a Magento 2 site with more than 180,000 products for a new client. Time to first byte was over 40 seconds. Not page load. The server had not even started answering.
We brought it down to around 2 seconds, and there was still more to do after that.
Why large catalogues break differently
At 180,000 products, ordinary problems become severe ones. Indexing takes longer, category queries get heavier, caching strategies that work on a thousand SKUs collapse, and every unnecessary module multiplies across an enormous dataset. Native Magento handles scale reasonably well until the extensions arrive, which is exactly where Magento speed problems actually start.
A 40-second response is not a slow site, it is an unusable one. Nobody waits. Google barely crawls it.
Why the server response was the right target
We did not begin with image compression or theme tweaks. At 40 seconds those are irrelevant. Time to first byte is the number that gates everything else, which is why it deserves attention before Core Web Vitals scores and why most speed audits measure the wrong thing.
Fixing it improves conversion and crawl efficiency at the same time. Few technical changes do both, and we have seen the same pattern taking a store from five seconds to under one.
Performance work is never finished
We flagged further work rather than declaring victory, because on a catalogue this size performance is maintenance, not a project. That is the difference between a fix and a foundation you keep in good order, and it is what peak trading exposes in the weekend that tests every build.
If your Magento store is slow and the catalogue is large, book a call and we will measure where the time actually goes.