Magento optimization case studies — three anonymised stores
Three Magento 2 performance projects I worked on as an Adobe-Certified Magento + Hyvä developer, with anonymised metrics and the exact changes that moved the numbers.
Magento 2 performance optimisation — three anonymised case studies
Magento 2 performance optimisation is the practice of reducing time-to-first-byte, Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift on a Magento 2 storefront so that the site loads under the Core Web Vitals thresholds and converts at modern e-commerce rates. The three case studies below are real Magento engagements I shipped between 2023 and 2026. I have anonymised the brands and rounded the numbers so I do not breach NDA, but the architecture, the bottlenecks and the fixes are accurate to the work performed.
I write these up because most Magento "case studies" on the web are agency marketing — five bullet points and a logo wall, with no actual diagnosis. The point of this page is the opposite: show the audit findings, show the fix, show what moved. If your store looks like one of these three shapes, the same playbook will work. If it does not, the diagnosis still applies — only the order of operations changes.
Every engagement on this list followed the same intake: a paid $499 audit that produced a written report with Lighthouse traces, server-timing breakdowns and a prioritised fix list. The client then chose whether to take that report to their internal team or commission the sprint. All three commissioned the sprint. For context on the audit framework I use, see the Magento performance optimization service page.
Case 1: Mid-market fashion retailer — Hyvä migration
Profile
European mid-market fashion retailer, roughly 3,000 SKUs, Magento Open Source 2.4.7-p2, Luma-based theme heavily customised by a previous agency. Around 90k monthly sessions, 68% on mobile, paid traffic dependent on Meta Ads. The brand was burning ad spend because mobile LCP was sitting at ~5.8s on 4G and Meta's quality score had tanked.
Audit findings
Mobile Lighthouse was 31. The Luma theme was loading 41 RequireJS modules before the hero painted, Font Awesome 5 and a separate icon CDN were both shipping, four legacy Knockout.js components were running on the homepage with no actual function attached, and the LCP element was a webfont-rendered hero headline with `font-display: block`. Server side was fine — TTFB was ~410ms with Varnish hits. The frontend was the entire problem.
The sprint
Full Luma to Hyvä migration scoped at ~80 hours. Hyvä theme installed, Tailwind tokens matched to the existing brand palette, 12 third-party module compat checks via the Hyvä compatibility checker, Alpine.js components rewritten for the size-picker, mini-cart and ajax search. Webfont swapped to `font-display: swap` with a system-font fallback during load. Two heavy "personalisation" modules that had not been used in a year were uninstalled. The exact migration sequence I follow on every Luma store is documented in the Luma → Hyvä migration playbook.
Result
Mobile LCP from ~5.8s to ~2.1s (under the 2.5s Core Web Vitals threshold). Lighthouse mobile from 31 to 89. CLS from 0.21 to 0.03. JavaScript main-thread time on the homepage dropped from ~6.9s to ~1.2s. Conversion rate, measured against the same Meta cohort over 60 days, moved +18%. Meta's landing-page quality score recovered and CPA fell ~22% as a side effect. Cost: 80h at the standard rate, plus the $499 audit credited toward the sprint.
Case 2: Enterprise B2B distributor — backend tuning + Varnish + Redis upgrade
Profile
European enterprise B2B distributor, around 80,000 SKUs, Adobe Commerce 2.4.6-p4, customer-group pricing, three storefronts (DE / NL / EN). 2,000–3,000 logged-in B2B buyers placing reorders daily. Frontend was already fine — TTFB was the problem. Buyers were waiting 12–18 seconds for the admin order grid to load, and category pages took 4–5s on first hit.
Audit findings
Magento was running on a single-tenant server, but Varnish was configured for a Luma front-end and ESI holes were leaking the entire cart/account block on every category page, dropping the FPC hit rate to ~14%. Redis was sharing one database for cache, session and FPC — under load the eviction policy was thrashing. The admin order grid was joining `sales_order_grid` against three custom EAV attributes with no indexes, scanning ~1.4M rows on every paginated request. The indexer was running in `Update by Schedule` mode but `catalogrule_product` had not finished in 36 hours.
The sprint
Scoped at ~110 hours, billed `~110h @ $25/hr`. Split Redis into three databases (cache / session / FPC) on Redis 7 with `allkeys-lru`. Rewrote the VCL to drop ESI for B2B-specific blocks and replaced it with the `customer-data` JS pattern so the FPC hit rate climbed back to ~78%. Added covering indexes on the three EAV joins, plus a `Panth\SalesGridIndex` patch that batches the rebuild. Refactored the `catalogrule_product` indexer to chunked mode and pinned it to a dedicated worker. Upgraded MariaDB 10.4 to 10.11 and bumped InnoDB buffer pool to fit the working set.
Result
TTFB from ~1.6s to ~280ms on a cold category page. Admin order grid from 14s to under 2s. FPC hit rate from 14% to 78%. The `catalogrule_product` indexer reindex went from 36h+ to ~22 minutes. No frontend work was needed on this engagement — the existing Luma theme was already lean enough, and the client did not want a redesign. Cost over 60 days: ~110 hours at $25/hr plus the audit.
Case 3: DTC multi-brand operator — Core Web Vitals lift
Profile
A DTC multi-brand operator running four storefronts (different brands, shared catalogue) on a single Magento Open Source 2.4.8 install with the Hyvä theme already in place from a previous agency. Roughly 12,000 SKUs total, ~140k monthly sessions, 82% mobile. The brand was getting "Poor" labels in Google Search Console's Core Web Vitals report on three of the four storefronts, with INP being the biggest offender.
Audit findings
The previous build had installed Hyvä correctly but layered a third-party "wishlist + bundle builder" module that injected ~180KB of compiled JS into every page, much of it event listeners bound on `document` with no debounce. INP was ~520ms on the PLP. CLS was ~0.34 — a header announcement bar was loading async from a 3rd-party AB-test platform and pushing the hero down ~80px on every visit. The LCP image was the hero PNG, but it was being lazy-loaded by mistake because the previous agency had wrapped the entire above-the-fold section in a `loading="lazy"` block.
The sprint
Scoped at ~45 hours. Replaced the wishlist module with a Hyvä-native Alpine implementation, removed the 3rd-party AB-test inject and rewrote the announcement bar as a server-rendered slot with reserved height, and fixed the lazy-load attribute on the hero. Added `fetchpriority="high"` on the LCP image, swapped the webfont preload list down from 6 fonts to 2, and ran a CLS hunt across all template files (using the recipe I documented in the LCP / INP / CLS recipe).
Result
CLS from ~0.34 to ~0.04 (well under the 0.1 Core Web Vitals target). INP from ~520ms to ~180ms. LCP held at ~2.0s. All four storefronts moved into "Good" in Search Console's Core Web Vitals report within 28 days of deploy. Conversion lifted ~9% on the worst-performing storefront over the following 45 days. Cost: 45 hours, fixed-fee at $2,499 + a small overage.
What every case had in common
Three different stores, three different bottlenecks — and yet the engagement shape was identical. Every project started with a paid audit, every one produced a written report before code was touched, and every one had a "tip-of-the-iceberg" finding that the client had not suspected.
The fashion retailer thought they had a server problem; it was the frontend. The B2B distributor thought they needed Hyvä; they needed indexes. The DTC operator thought they had a Hyvä bug; they had three layers of third-party JavaScript bolted on top of Hyvä. In every case, measuring before fixing was the unlock.
| Pattern | Case 1 | Case 2 | Case 3 |
|---|---|---|---|
| Bottleneck layer | Frontend JS | DB + cache | Third-party JS |
| Did Hyvä migration help? | Yes, primary lever | Not needed | Already on Hyvä |
| Audit duration | ~6h | ~8h | ~4h |
| Sprint duration | ~80h | ~110h | ~45h |
| Primary metric moved | LCP, conversion | TTFB, indexer time | CLS, INP |
| Time to measurable result | ~30 days | ~14 days | ~28 days |
How to run a similar optimisation on your store
If your store looks like one of these three — a Luma-heavy mid-market with mobile LCP above 4s, a B2B install with slow admin and low FPC hit rate, or a Hyvä store with CLS / INP in the red — the order of operations is the same. Step one: measure. Pull a Lighthouse mobile trace, a CrUX field-data sample, a server-timing breakdown and a slow-query log over a 24h window. Do not touch code until those four artefacts exist.
Step two: classify. Is your bottleneck frontend, backend or third-party? The matrix above is a quick triage. If your TTFB is under 600ms but LCP is over 4s, you have a frontend problem and Hyvä is on the table. If your TTFB is over 1s, fix the server and database before you redesign anything. If your CLS is over 0.1, it is almost always a third-party tag or an unreserved layout slot.
Step three: fix the highest-leverage item first. Do not run 40 small optimisations in parallel — you will not know what moved the number. Fix one big thing, measure, then move to the next. The fashion retailer's full Hyvä migration was one decision; the B2B distributor's Redis split was one decision; the DTC operator's third-party-tag removal was one decision. Each of those single decisions did more than any optimisation checklist would have done.
If you want me to run this for you, the engagement starts at the $499 audit. If your store ends up needing the sprint, the audit fee is credited toward it. For the broader service description see the Core Web Vitals tune-up page, or for the technical TTFB walkthrough see the TTFB optimization case study.
Frequently asked questions
Why are the case studies anonymised?
Every client engagement is covered by a non-disclosure agreement that prevents me from naming the brand or publishing exact metrics. The architecture, bottlenecks and fixes are accurate to the actual projects, and the numeric ranges are within the real lift seen. If you need named references, I can supply them privately on a discovery call.
How long does a typical Magento performance project take?
Audit takes ~5–8 hours of my time, delivered as a written report within a week. The sprint itself ranges from ~40 hours (CLS / INP tune on an existing Hyvä store) to ~110 hours (backend + cache + indexer overhaul on enterprise B2B). Full Luma to Hyvä migrations typically land between 80 and 180 hours depending on theme complexity and module count.
Do I always need a Hyvä migration to hit Core Web Vitals?
No. Case 2 hit its targets without touching the frontend at all — the bottleneck was Varnish + Redis + indexer config. Case 3 was already on Hyvä when I arrived. Hyvä is the right answer when frontend JavaScript is the bottleneck, but on B2B / enterprise stores the bottleneck is often the database or the cache layer instead.
What metrics do you commit to in the sprint?
Targets are agreed in the audit report. The default targets I aim for are: mobile LCP under 2.5s, INP under 200ms, CLS under 0.1, FPC hit rate above 70%, TTFB under 600ms on a cold category page. If I cannot hit a target due to scope outside the sprint (e.g. a third-party app the client refuses to remove), it is called out in the report before the sprint starts.
What if my store is on Adobe Commerce, not Open Source?
Same playbook. Case 2 was Adobe Commerce. The only difference is licence-specific tooling — Adobe Commerce ships with B2B modules, the page builder, and Live Search that need their own performance review. I am Adobe-Certified Magento 2 Developer (cert issued September 2021), so the Adobe Commerce surface area is covered.
How do you measure the conversion lift?
Conversion lift is measured against the same traffic source and audience cohort over a 60-day window before/after deploy, using the client's GA4 or Adobe Analytics. I never claim a conversion lift from Lighthouse-only data — that would be dishonest. Where conversion data is not available, I report only the Core Web Vitals and server-side metrics that I can verify directly.
Can you ship these results with my existing dev team?
Yes — this is how most engagements actually run. I work alongside an internal Magento team or another agency, deliver the audit and the architectural plan, and either implement the high-leverage changes myself or hand the spec to your team and review their PRs. Both shapes work; the hand-off shape is cheaper.
What's the smallest engagement you'd take?
The $499 audit on its own. You get the written report, the prioritised fix list, the Lighthouse traces and the server-timing breakdown — and you are free to give that document to your internal team or another agency. About 30% of audit clients do exactly that and never come back for the sprint, which is fine.
Do you publish before/after numbers publicly?
Ranges only, anonymised, as on this page. If a client gives explicit written permission to publish their store name and full metrics, I will — but I do not ask for that permission unless they offer it first, because the case-study marketing benefit goes to the client, not the developer.
How do I start?
Use the get in touch page or message me on Upwork. The first call is 30 minutes, no charge. If it looks like a fit, I send a scope for the $499 audit and we get going within a week.
Want a written audit of your Magento store before any code is touched? Fixed-fee from $499 audit · $2,499 sprint · ~Nh @ $25/hr.
Book a Magento audit