You do not need to be technical to make good decisions about your store, but you do need to know what people are talking about. This is the vocabulary that comes up in every performance conversation, explained the way we would explain it on a call.
The metrics
TTFB, time to first byte
How long the server takes to send the very first piece of the page. Everything else happens after this, so a slow TTFB delays the whole load regardless of how light your frontend is.
What a bad number tells you: the problem is on the server. Cache, database, hosting. A new theme will not help.
LCP, largest contentful paint
How long until the biggest visible thing on the page has loaded, usually the hero image or the product photo. It is a reasonable proxy for "when does this look like a page".
What a bad number tells you: either the server was slow to respond, or the main image is too large or loaded too late.
INP, interaction to next paint
How long between someone tapping something and the screen visibly responding. It replaced the older FID metric and it measures the whole interaction rather than just the delay before it starts.
What a bad number tells you: too much JavaScript is running when someone interacts. Category filters and product options are the usual places this shows up.
CLS, cumulative layout shift
How much the page moves around while it loads. If you have ever tried to tap a button and had an image push it out from under your finger, that is what this measures.
What a bad number tells you: something is loading without space reserved for it. Images without dimensions, banners, cookie bars, fonts that swap.
Lab data and field data
Lab data is a controlled test: one simulated device, one connection. Field data is what your real visitors experienced over the past weeks, across every device they happen to own.
Why it matters: a green lab score with a failing field report is not a contradiction. The field report is what counts, and the gap between the two is usually where the interesting problem is.
The infrastructure
Full page cache
Magento assembles a page from many pieces. Full page cache keeps the finished result so it only has to be assembled once, then served to everyone after that.
Why it matters: without it, every visitor triggers the full assembly. It is the difference between doing the work once and doing it thousands of times.
Varnish
A cache that sits in front of Magento and serves finished pages from memory. When it has the page, Magento is not involved at all.
Why it matters: it is the single biggest lever on TTFB for a store with meaningful traffic.
Redis
A fast in-memory store, used by Magento for cache and sessions. The alternative is writing those to disk or to the database, both of which are considerably slower.
Why it matters: a store running sessions in the database gets slower as concurrent visitors increase, exactly when you least want it to.
OpenSearch and Elasticsearch
The search engine Magento uses for the search box and for filtering on category pages. Two names for what is, for these purposes, the same job.
Why it matters: when it is undersized or misconfigured, filtered category pages and search both get slow, and those are your highest-intent pages.
CDN
A network of servers that keeps copies of your images, stylesheets and scripts close to your visitors, so those files do not have to travel from your server.
Why it matters: most for international audiences. It does nothing for TTFB on the page itself, which is why it is not an alternative to Varnish.
The operations
Indexers
Magento precomputes prices, stock and category membership into tables built for fast reading. Indexers are the processes that build those tables.
Why it matters: set to update on save, every product change triggers a rebuild while someone waits. Set to update by schedule, it happens in the background. This single setting explains a lot of slow admins.
Cron
The background scheduler. It runs indexing, sends emails, processes queues and cleans up. It is meant to run every minute, forever.
Why it matters: when cron dies, nothing errors. Work piles up quietly and the store degrades over weeks. It is the most common silent failure we find.
Production mode
Magento can run in developer, default or production mode. Production mode uses precompiled code and cached configuration; developer mode recompiles on every request and logs verbosely.
Why it matters: a store left in developer mode is slower on every single page, and nothing about it looks broken. Always the first thing we check.
Message queue
A list of jobs to be done later. Order emails, ERP updates and bulk operations can go here instead of happening while the customer waits.
Why it matters: it is how you take work out of the critical path. Particularly relevant in checkout, where every extra second is expensive.
The frontend
Luma and Hyvä
Luma is the theme Magento ships with. Hyvä is an alternative theme built to send far less JavaScript to the browser. Both are Magento themes, so switching does not change your catalogue, orders or admin.
Why it matters: theme choice mainly affects what happens in the browser, so it moves INP more than TTFB. If your server is the bottleneck, a lighter theme will not rescue it.
Critical CSS
The small amount of styling needed for the part of the page a visitor sees first, delivered inline so the page can render without waiting for a stylesheet.
Why it matters: it removes a render-blocking request from the start of the load, which shows up directly in LCP.
Lazy loading
Deferring the download of images until they are close to being visible. Useful for the tenth product image, harmful for the first one.
Why it matters: lazy loading your main product image is one of the most common self-inflicted LCP problems we see.