Magento speed problems almost never start where people think they do. Owners blame the theme, the images, the frontend. The real culprit is usually deeper, in the time to first byte.
A few days ago I sat down with Ivan Chepurnyi, someone I have real respect for, to talk about Magento optimisation. Between us we have over 40 years of Magento experience, and we agreed on one harsh truth: native Magento runs fine until you start installing modules. That is where the speed goes to die.
Why time to first byte is the real number
Time to first byte is how long the server takes to start responding before the browser renders anything. If that number is high, no amount of image compression or theme tweaking will save you. The page is slow before the frontend even gets a chance. That is why I care far more about server response than the cosmetic optimisations most audits obsess over, the same story as taking a store from five seconds to under a second at the server level.
Modules are where it goes wrong
Every module you install adds queries, observers, and layout work to that first server response. Ten small extensions later, native Magento is buried under code it was never meant to carry. The fix is rarely a new theme. It is auditing what loads on every request and cutting what does not earn its place, the same discipline as watching tool and module sprawl before it runs up the cost.
Speed is not cosmetic. It decides conversion and it decides survival under load, which is exactly what Black Friday exposes on every unoptimised store.
Fix the foundation, not the symptom
Chasing frontend fixes while the server crawls is treating the symptom. Get the server response right first, then optimise the rest. It is one more case of getting the foundation right before the next tactic, and it is why the partner who knows where to look matters more than the platform badge.
If your Magento store is slow and the usual fixes have not moved it, book a call and we will start where the time actually goes.