How to diagnose a slow e-commerce store
Switching hosting at random rarely fixes a slow store, because slowness almost always has a precise, locatable cause. Measuring it before acting avoids spending time and money on the wrong lead.
The diagnostic approach
-
Measure with an external tool
PageSpeed Insights or GTmetrix give a first objective measurement: load time, TTFB, total page weight, and a breakdown of the slowest-loading resources.
-
Separate server time from rendering time
A high TTFB (above 600–800 ms on a dynamic page) points to a server or database issue. A correct TTFB but a slow full render points instead to resource weight or JavaScript rendering.
-
Count the SQL queries on the slowest page
On PrestaShop, debug mode enables a profiling bar that lists every SQL query and its execution time. On WooCommerce, the Query Monitor plugin provides an equivalent feature.
-
Check the cache status
A cache that's disabled, misconfigured, or systematically invalidated is one of the most common causes and one of the simplest to fix, before considering any other optimisation.
-
Check the server configuration
The PHP version in use, whether OPcache is enabled, and the available memory_limit have a direct impact, particularly on a large catalogue.
-
Isolate suspect modules or plugins
A module or plugin that runs heavy code on every page (external call, tracking, product recommendation) can slow down the whole site even when its feature isn't in use at that moment.
Why measure before switching hosting
A more powerful server temporarily masks a problem of poorly indexed queries or badly optimised modules, but the slowness returns as soon as the catalogue or traffic grows again. Conversely, hosting that's genuinely undersized for the traffic it receives won't be fixed by optimising code alone.
That's why measurement always comes before the decision: it shows whether the problem is structural (an unindexed database, no cache) or capacity-related (insufficient server resources for the actual volume of visits). The two are handled differently and rarely with the same urgency.
On a catalogue of several thousand products, missing indexes on the columns used in joins (product ID, store ID, language ID) is a recurring cause, invisible as long as the data volume stays low in a test environment.
Signals that warrant a diagnosis
- A product page or category page that takes more than three seconds to display
- A gradual slowdown over the months with no apparent technical change
- A back office that only becomes slow once the catalogue exceeds several thousand products
- A poor PageSpeed score or Core Web Vitals despite hosting marketed as high-performance
- Slowness that only appears during traffic peaks
Frequently asked questions
Does a performance diagnosis risk slowing the site down further?
How long does a full diagnosis take?
Is it normal for a site to be fast locally but slow in production?
If the slowness only affects the back office, is it still worth worrying about?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.