Is Your PrestaShop Store Slow? Measure Before You Optimize

Last updated: June 2026.

When a PrestaShop store feels slow, the most common reaction is also the most expensive one: install a caching or optimization module, flip every toggle on, and hope. Sometimes it helps. Often it does nothing — and occasionally it makes things worse, because the real bottleneck was never where the module operates. Speed problems are diagnostic problems first. The honest advice from anyone who does this work for a living is the same: measure before you optimize. Find the actual cause, then spend money on the fix that addresses it — which sometimes means spending nothing at all.

Why guessing is so expensive

"My store is slow" is a symptom, not a diagnosis. The underlying cause can sit in any of several very different places, and a tool that fixes one does nothing for the others:

• A single module firing an N+1 query on every product page — one extra query per item in a loop, multiplied by your catalog.
• A heavy theme that ships hundreds of kilobytes of render-blocking CSS and JavaScript before anything paints.
• Slow TTFB (time to first byte) from an overloaded shared host or a database server that is already at its CPU or IO ceiling.
• Unoptimized images — full-resolution uploads served to mobile, no modern formats, no proper sizing.
• No full-page cache, so PrestaShop rebuilds every page from scratch for every visitor.
• A MySQL instance starved of memory, doing table scans where an index should be.

Here is the trap. If your problem is a render-blocking theme and slow TTFB, a page-cache module might shave a little off repeat views while leaving the first impression — the one Google measures — untouched. If your problem is an overloaded database, no amount of front-end asset optimization will move the needle. You can spend on the wrong layer indefinitely and never feel faster. That is why we treat a performance audit as step one: it tells you which layer is actually costing you, so the next purchase (if any) is aimed correctly.

What a performance audit actually measures

A proper audit is not a single speed-test score. It separates the page into its real components and finds where the time goes:

Server time vs. browser time

The first split is TTFB versus front-end render. TTFB is everything that happens before your server sends the first byte — PHP execution, database queries, cache lookups. Front-end render is everything the browser then does with the response. A 3-second page with 2.4s of TTFB is a back-end problem; the same 3-second page with 0.2s TTFB and 2.8s of render is a front-end problem. They need opposite fixes, and only the measurement tells you which one you have.

Queries per page and the worst offenders

PrestaShop pages can run anywhere from a few dozen to several hundred SQL queries. The audit counts them per page type and ranks the worst offenders — frequently a single module that should cache a lookup but re-queries on every hook. Finding that one query is often worth more than any amount of caching layered on top of it.

Module overhead

Every module hooked into a page adds work, and some hook into every page whether they are needed there or not. The audit profiles which modules contribute meaningful execution time and which fire needlessly, so you can disable or replace the genuine culprits rather than guessing.

Asset weight and caching

It measures total page weight, request count, and how well CCC (combine-compress-cache), critical-CSS, and deferred JavaScript are configured — or whether they are configured at all. It also checks the caching stack end to end: full-page cache hit ratio, OPcache for compiled PHP, and Redis for the object/query cache. A cache that exists but rarely hits is worth almost nothing, and only the hit ratio reveals that.

Hosting ceiling, mobile, and Core Web Vitals

Finally it looks at the hardware reality — CPU, IO, and memory headroom under load — and tests mobile separately from desktop, because most of your traffic and most of Google's measurement is mobile. That ties directly into Core Web Vitals: LCP, CLS, and INP. These are not vanity metrics; they are a real ranking signal, which is why speed and search overlap and why a technical SEO audit and a performance audit so often surface the same issues.

A self-check you can run in ten minutes

You do not need to order anything to get a first read on your own store. Open your homepage and a busy product page in Chrome and try this:

• Run a waterfall. Open DevTools, go to the Network tab, hard-reload, and look at the very first request. Its "Waiting (TTFB)" time tells you how much is server-side. Over ~600ms on a warm cache points back-end.
• Count requests and weight. The Network tab footer shows total requests and transferred size. Hundreds of requests or several megabytes per page is a strong asset/CCC signal.
• Read the PrestaShop profiler. Enable debug mode on a staging copy and turn on the profiler — it prints the query count and the slowest queries per page. A product page running 250+ queries deserves attention.
• Throttle mobile. In DevTools, set the device to a mid-range mobile profile with "Slow 4G" throttling and reload. If the experience falls apart here, that is what most of your visitors actually feel.

These numbers are illustrative thresholds, not guarantees — every store is different. But they will usually point you at the right neighbourhood before anyone spends a euro.

Measure TTFB from the command line

If you'd rather get a precise server-time number without opening DevTools, curl reports the timing breakdown directly. It's read-only — it just fetches the page and prints how long each phase took:

# Print connection, TLS, TTFB and total time for one page load
curl -s -o /dev/null \
  -w "dns:    %{time_namelookup}s\nconnect: %{time_connect}s\nTLS:     %{time_appconnect}s\nTTFB:    %{time_starttransfer}s\ntotal:   %{time_total}s\n" \
  https://yourdomain.com/your-product-page

The number that matters most here is TTFB (time_starttransfer): everything up to the first byte of the response. Run it a few times so a cold cache doesn't skew the result. If that figure stays high — well past half a second on a warm cache — your bottleneck is server-side (PHP, queries, hosting), and no amount of front-end asset optimization will fix it. If TTFB is low but the page still feels slow in the browser, the cost is in render and assets instead. That single split is the whole reason to measure before you buy.

The honest turn: what the audit tells you to do

The whole point of measuring first is that the verdict is often not "buy an optimization module." A good audit ends in one of a few clear directions:

• It's the hosting. If TTFB is high even on a cache hit and the server is at its CPU/IO ceiling, no module fixes that — you need better hosting or a tuned stack, which is exactly what a hosting audit scopes out.
• It's configuration. Frequently the caches exist but are misconfigured: CCC half-on, OPcache too small, Redis not actually wired up. That is a settings change, not a purchase.
• It's a specific module or theme. Sometimes one heavy module or an inefficient theme is the entire problem, and the fix is to replace or remove it.
• You genuinely need a tool. If the bottleneck is front-end assets and missing full-page caching, a focused, open-code module like Performance Revolution is the right buy — once you know that's the layer that's costing you, not before.
• It's already fine. Occasionally the audit shows the store is healthy and the perceived slowness is a single slow third-party script or a regional network issue. Knowing that saves you from "optimizing" something that isn't broken.

Buying blindly is how stores end up with three overlapping caching modules and a slower site than they started with. Diagnosing first is cheaper, even when the diagnosis costs something, because it stops you spending on the wrong layer.

How to start

If you want a structured read rather than a DIY afternoon, our performance audit is built for exactly this. You enter your store URL, a quick read-only readiness check runs first — no admin credentials handed over, see our store audit readiness notes for how we handle access — and only then is the audit ordered. It sits alongside the rest of our expert services for the cases where the fix turns out to be hosting, configuration, or development rather than a product. Whichever way it lands, you will know why the store is slow before you spend on making it fast — and that is the part that actually saves money.

Frequently asked questions

I already have a caching module installed. Why is my store still slow?

Because caching only helps the layer it sits on. A full-page cache does nothing for a slow first byte on an overloaded database, and a front-end optimizer can't fix a server that's at its CPU ceiling. It's also common for a cache to be installed but barely hitting — half-configured CCC, OPcache too small, Redis not actually wired up. The TTFB split above tells you whether your bottleneck is even in a layer caching can touch. Often it isn't, which is why the module "did nothing."

What's a "good" TTFB for PrestaShop?

As a rough guide, under ~200ms is healthy, ~200–600ms is acceptable, and consistently over ~600ms on a warm cache points to a server-side problem worth chasing. These are neighbourhoods, not hard lines — a heavy product page legitimately does more work than the homepage. The useful comparison is your own store cold versus warm, and your TTFB against the render time the browser adds afterward. That ratio, not any single number, tells you which way to spend.

Can a performance audit guarantee my store will be faster?

No, and be wary of anyone who promises it. An audit tells you why the store is slow and which fix addresses it — it doesn't perform the fix or guarantee a number. If the cause is hosting, the speed-up depends on the new stack; if it's a heavy module, on whether you can replace it; if it's already fine, the honest result is "don't spend anything." The value is aiming the spend correctly, not a promised millisecond count.

Will the audit slow down or risk my live store?

No. The readiness check and the measurements are read-only — they load pages the way a visitor would and record timings; nothing is written or changed. The profiler step in the self-check is the one thing you should run on a staging copy rather than live, because debug mode exposes internals and adds overhead. The audit itself doesn't need debug mode on your production site.

How is this different from just running PageSpeed Insights?

PageSpeed measures the front-end render of one URL and scores it against Core Web Vitals — genuinely useful, and worth running. What it can't see is your server: query counts, which module is firing on every hook, your cache hit ratios, or whether the database is the real ceiling. A page can score well on PageSpeed and still be slow under real catalog load, or score poorly for a reason a module can't fix. The audit covers the back-end half PageSpeed is blind to.

Related articles

• Is It Safe to Give a PrestaShop Auditor Access to Your Store?
• Introducing Expert Services: PrestaShop Audits Before You Buy Another Module
• How to Tell If Your PrestaShop Store Needs an SEO Audit
• Signs Your PrestaShop Store Needs a Security Audit (And How to Self-Check First)
• PrestaShop SEO: The Complete Guide to Ranking Higher