Case Study

From 30-second category pages
to about one second.
Without replatforming.

A Finnish mobile-electronics retailer on headless Magento: a custom Nuxt storefront over GraphQL, a headless CMS, and Kubernetes on Google Cloud. The shop looked like proof that "Magento is slow". It wasn't.

20–30 s → ~1 s

Heaviest category page

~2.5 s → under 1 s

Time to first byte, site-wide

~3,000 → 0

Pages rated red for layout shift (CLS)

0

Open issues since early 2026

Slow, inconsistent, and blamed on Magento.

Category pages took 20–30 seconds, worst where products had many variants.
Every page waited about 2.5 seconds before anything arrived.
Around 3,000 pages failed Google's layout-stability test.
Customers saw different prices and stock on the listing, the product page and the cart.
Features that work out of the box on standard Magento (Klarna checkout, server-side Meta tracking, even the sitemap) had to be custom-built for the storefront.
Analytics events fired before tracking had loaded, so they were silently lost.

None of this was one big mistake. It was years of reasonable-looking decisions whose cost nobody had measured.

We measured each layer separately.

Backend response time and frontend render time were measured on their own: the step most teams skip, and the reason the real causes had stayed hidden.

Three findings:

Over-fetching. The storefront asked for every attribute of every product variant, and the backend returned all of it, on every page. Trimming the queries to what the page actually shows saved up to 20 seconds on its own.
Split hosting. The frontend and backend ran in separate environments, so every page paid an extra network round trip. Moving them into the same cluster saved about half a second per page by itself.
Unsynchronised caches. Three cache layers expired on their own schedules, with no way for Magento to tell the storefront that something had changed. That's why prices and stock disagreed between pages.

What we changed.

Trimmed and split the category queries.
Gave category and search their own templates, and reserved layout space for content loaded from the CMS.
Built cache invalidation end to end: saving a product in Magento now clears exactly the right storefront cache entries. Stock comes from its own uncached request, so it's always live.
Moved the frontend into the backend's Kubernetes cluster and rebalanced resources. Smaller footprint, more stable, no extra hardware.
Fixed analytics tracking and the page heading structure.
Built the Klarna checkout, server-side Meta tracking and sitemap for the custom storefront.

Not everything turned green.

Layout stability sits at Google's "needs improvement" level, not "good". That's the realistic ceiling for a storefront where every section is rendered dynamically from a CMS. Getting past it would mean rebuilding how pages render. Some architecture choices carry permanent costs, and part of the job is telling you which ones you're living with.

The platform was never the problem.

Every symptom traced back to a decision that could be fixed. If your shop looks like proof that "Magento is slow", an assessment will tell you whether it's the platform or the build, in two weeks, at a fixed price.

Request an assessment

Client details anonymised. Happy to walk through any part of this work in as much technical depth as you like.

From 30-second category pages to about one second. Without replatforming.