How to Tell If Your Magento Store Is Actually Slow

Everybody who works on a store has a theory about why it's slow. It's the hosting. It's the theme. It's that extension somebody installed in 2021. The theories are usually sincere and frequently wrong, and none of them can be settled by discussion, because "slow" isn't a measurement.

Four numbers settle it. This article is about getting them, reading them, and knowing what they can't tell you.

The four numbers

TTFB — time to first byte. How long the server takes to start answering. Google's threshold for good is 800ms. This is the one that sets the ceiling: if HTML doesn't start arriving for two seconds, nothing the browser does afterwards can produce a fast page.

LCP — largest contentful paint. When the biggest thing on screen finishes rendering, which is roughly when a person would say the page appeared. Good is 2.5 seconds or less. Between 2.5 and 4 needs work. Above 4 is failing.

INP — interaction to next paint. How long the page takes to respond when somebody clicks or types. Good is 200ms or less. This is the one that catches heavy JavaScript, and it's the one most stores have never looked at.

CLS — cumulative layout shift. How much the page moves around while it loads. Good is 0.1 or less. Usually caused by images without dimensions, banners injected late, or a font swap that resizes everything.

Three of those — LCP, INP and CLS — are the Core Web Vitals Google ranks on. TTFB isn't one, and it's the one that decides whether the other three are achievable.

Field data, not a Lighthouse score

Two people can look at the same store, measure it honestly, and disagree completely — because they measured different things.

Lighthouse is a lab test. One page, one simulated connection, one first-time anonymous visitor, in a browser that just started. It's a diagnostic tool and a good one.

Field data is what happened to real people. Google collects it in CrUX — the Chrome User Experience Report — from actual Chrome users on actual devices, and it's what Search Console reports and what ranking uses.

The two disagree constantly, and when they do the field data is right. Real visitors arrive on pages that missed the full-page cache. Some of them are logged in, which bypasses the cache entirely. Some are on a four-year-old Android on a train. Lighthouse never sees any of that.

So: PageSpeed Insights, on your real domain. The top half of that page is field data, if your store has enough traffic to have any. The bottom half is a fresh Lighthouse run. Read the top half to find out whether you have a problem, and the bottom half to work out what it is.

If PageSpeed says there's no field data for your URL, the store doesn't get enough Chrome traffic for CrUX to report on it. That's not a failure — it just means you're working from lab numbers, and you should be more careful about testing the slow paths yourself.

Measure the right pages

Almost every performance conversation starts with the homepage, and the homepage is the least useful page on the site to measure.

It's the page that has already been optimized, because it's the page everyone looks at. It's often simpler than the rest of the store. And most visitors never see it: they arrive from search on a product or a category.

Measure these, on mobile, separately:

• A category page, ideally a deep one with layered navigation and a few hundred products behind it.
• A product page, ideally a configurable one with a lot of options.
• The search results page, if a meaningful share of your traffic uses search.

Mobile first, because that's where the numbers are worse and where the majority of the traffic usually is. A store that's fine on desktop and failing on mobile is failing.

The path nobody tests

A logged-in customer with items in their cart bypasses the full-page cache. Every request they make is a real Magento request — full bootstrap, full layout, real database queries. On a lot of stores this path is several times slower than the cached one, and it's the path that every returning customer takes.

Check it by hand. Log in, add something to the cart, and time a category page in the browser's network panel. Compare it to the same page in a private window. If the gap is large, your cache is doing more work than you thought and your real customers are getting the slow version.

The same goes for the checkout, which can't be cached at all.

What the numbers tell you

Once you have them, they narrow the search considerably.

TTFB is high, everything else is proportionate. The problem is server-side and the frontend is innocent. Look at the full-page cache first — not whether Varnish is installed, but what the hit rate actually is. A store running Varnish at a 40% hit rate is a store where most visitors get the slow path anyway. After that: slow database queries, an extension doing work on every request, PHP workers exhausted at peak, or hosting that's simply undersized.

TTFB is fine, LCP is bad. The server is answering quickly and the browser is taking a long time to do anything with it. Render-blocking CSS and JavaScript, an unoptimized hero image, fonts that block text from painting, or a theme shipping several megabytes.

INP is bad. Too much JavaScript executing on the main thread. Frequently a third-party script — a chat widget, a tag manager container, a personalization tool — and frequently one nobody remembers adding.

CLS is bad. Something is loading late and pushing content around. Images without width and height, a cookie banner inserted after paint, a font swap.

The numbers are fine and it still feels slow. Then measure the logged-in path and the checkout, because that's where you haven't looked.

What you can't see from outside

Most of these investigations start from outside the store, so the limits of that view matter.

From outside you can measure response times, read cache headers, check field data, and often infer the Magento version. What you can't see is the reason: the slow query log, the cache hit rate, whether cron is running, whether the indexers are in the right mode, how many PHP workers there are, or which of the forty installed extensions is adding 300ms to every page.

That's not a small gap. It's the difference between knowing a store is slow and knowing what to do about it, and it's why "buy more hosting" is such a common and expensive wrong answer. If the database is the bottleneck, more PHP workers make it worse — they queue up against the same contended resource.

Then what

Write the numbers down with the date on them. CrUX is a 28-day rolling window, so a fix deployed today won't fully show up for about a month, and you will want to know what it looked like before.

Then work in order: server-side first, because it sets the ceiling, and the frontend last, because it can never outrun a slow backend. The Magento 2 performance checklist is that list in order, with the commands to verify each item.

If the numbers say there's a problem and you can't see the cause from where you're sitting — which is the normal outcome — that's exactly what the free store health check is for. A person reads your store, and you get back what we found.