Magento 2 · Performance
Magento performance optimisation that starts with measurement
A slow Magento store is rarely slow for one reason. We find where the time goes, on the server and in the browser, fix the causes in order of commercial impact and report the before and after figures for your own store.
The causes
Why Magento stores get slow
Magento is not slow by nature. It is demanding, and it slows down when any of these is left unattended.
-
Too many extensions, or poor ones
Every module adds code to each request. Badly written ones add plugins, observers and queries to pages that never needed them.
-
Uncached blocks
One block marked as not cacheable in layout XML switches off full page caching for the whole page, so every visit is built from scratch.
-
Heavy Luma JavaScript
The default Luma front end loads a large amount of JavaScript through RequireJS and Knockout before the page can respond.
-
Slow queries
Unindexed custom tables, bloated log and quote tables, and collections loaded without limits turn into slow SQL as the store grows.
-
Indexers and cron
Indexers set to update on save, overlapping cron jobs and stalled queue consumers compete with shoppers for the same server.
-
Under-specified hosting
Too little memory, no Varnish, or every service squeezed onto one small machine. PHP, MySQL, Redis and search each need room.
Diagnosis
How we find out what is actually slow
We start with evidence, not a checklist. Three kinds of data answer three different questions.
Field data
What real visitors experienced, collected by Chrome and published in the Chrome User Experience Report and Google Search Console. This is how Magento Core Web Vitals are judged: Largest Contentful Paint (how soon the main content appears), Interaction to Next Paint (how quickly the page reacts to a tap) and Cumulative Layout Shift (how much the page jumps as it loads).
Lab data
Repeatable tests in a controlled browser, such as Lighthouse and WebPageTest. They will not match what customers see, but they show which request, script or image is responsible.
Server profiling
Time to first byte tells us whether the delay is on the server or in the browser. On the server we profile real requests with a tool such as New Relic or Blackfire, read the MySQL slow query log and check the full page cache hit rate.
Magento speed optimisation
What we fix, on the server and in the browser
Server side
- Full page cache served by Varnish, with uncacheable blocks found and corrected
- Redis for cache and sessions, sized for the store
- OpenSearch tuned for your catalogue
- A supported PHP version with OPcache set up for a Magento codebase
- Slow queries rewritten, indexes added, oversized tables cleaned
- Indexers on schedule, a cron that runs reliably and queue consumers kept under control
Front end
- A move from Luma to Hyvä where the measurements justify it
- Images in modern formats such as WebP, sized to the space they fill
- Critical CSS inlined so the first screen paints without waiting
- JavaScript bundled, deferred or removed
- Third-party scripts audited, delayed or dropped
- Fonts self-hosted, subset and preloaded
Where the money is
Checkout and search speed
Cart and checkout pages are personal to each shopper, so the full page cache cannot serve them. Their speed depends on the application itself: how quickly totals are calculated, how long shipping and payment services take to answer, and how much JavaScript the checkout loads.
Search deserves the same attention. A shopper who searches usually knows what they want, and a slow results page gives them time to look elsewhere.
-
Checkout
We profile each step, remove repeated totals calculations and slow external calls, and review payment and address lookup scripts.
-
Search and category pages
In Magento 2.4 the search engine also drives category listings, so OpenSearch settings and layered navigation both affect speed.
-
Logged-in customers
Customer-specific prices reduce what can be cached. We keep private content separate so the rest of the page still is.
Process
Five steps, in the same order every time
-
01
Record the baseline
Field and lab figures for your key page types, plus server response times, before anything is changed.
- Baseline measurements
-
02
Find the causes
Profiling, query analysis, cache inspection and a front-end review, written up with the evidence.
- Audit report
-
03
Work in priority order
Fixes are ranked by effect against effort and risk, then released through staging in small batches so each can be measured.
- Prioritised backlog
-
04
Measure again
The same tests are repeated after each release. Lab results are immediate. Field data takes a few weeks to catch up.
- Before and after report
-
05
Keep it fast
Speed drifts as extensions, tags and content are added. Monitoring under a support retainer catches regressions early.
- Monitoring and alerts
Deliverables
What you receive
-
Audit report
Findings in plain English, each with the evidence behind it and the pages it affects.
-
Prioritised backlog
Every fix ranked by impact, effort and risk, so you decide how far to go and in what order.
-
Before and after measurements
The same tests, run on your store before and after the work. We do not quote improvement figures in advance, because honest ones only exist once your store has been measured.
Questions
Magento performance questions
Why is my Magento 2 store slow?
The usual causes are a full page cache that is missing or being bypassed, too many or poorly written extensions, the JavaScript-heavy Luma front end, slow database queries, misconfigured indexers and cron, and hosting that is too small. Most slow stores have several of these at once, which is why diagnosis comes before any fix.
What are Core Web Vitals and do they matter for Magento?
Core Web Vitals are Google’s three measures of real user experience: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability. Google uses them when assessing page experience, and they are a fair reflection of how a Magento store feels to shoppers on ordinary phones.
Will Hyvä make my Magento store faster?
Usually, yes. Hyvä replaces the Luma front end and its RequireJS and Knockout JavaScript with a much lighter one built on Alpine.js and Tailwind CSS. That helps loading and responsiveness in the browser. It does not fix slow queries or a bypassed cache, so the server still needs checking.
How long does Magento speed optimisation take?
It depends on what the audit finds. Configuration fixes to caching, indexers and cron are small pieces of work, while replacing a front end or rewriting slow custom code is a project in its own right. After the audit you receive a scope, a schedule and a fixed price before any optimisation begins.
Do I need better hosting to speed up Magento?
Sometimes, but not always. A bigger server hides inefficient code and a bypassed cache without fixing them, and the problem returns as traffic grows. We check whether hosting is the limiting factor first. If it is, we tell you what the store needs and work with your provider on the change.