MG Music Gallery
Rebuilding the foundation of Magento for mgstore.az has made page load times 6 times faster
Sep 2024 - currently
A Faster Foundation for MG Music Gallery - Azerbaijan's Original Electronics Chain
5–6x faster
page response
From 60 minutes to 7
reindex
About the project
MG Music Gallery has been part of Azerbaijani households for longer than most of the categories it sells. Founded in 1993 as the country's first specialised chain for home appliances and electronics, the company started life as a music instruments specialist — hence the name — and grew into a multi-category retailer covering consumer electronics, large and small appliances, and professional audio. Today, MG Music Gallery operates a network of stores across Baku alongside its online flagship at mgstore.az.
There's a particular kind of trust that comes from being there first. For three decades, MG has been the chain people went to when they were buying their first TV, first washing machine, first proper sound system. That history shows up in the engaged audience around the brand today: more than 125,000 followers on Facebook and 121,000 on Instagram — people who interact with MG well beyond the moment of purchase.
A long-running brand carries an obligation that a newer one doesn't. Customers who have known MG for decades expect the website to feel as solid as the store itself. The catalogue is wide — around 75,000 products across electronics, appliances, audio, and related categories — and shoppers come in through every channel, on every device, at every hour. Performance, stability, and reliable catalogue updates aren't features. They're the floor.
The store runs on Magento Open Source with a monolith architecture.
The Challenge
When we joined the project, the symptoms were the kind any commerce team will recognise. Pages that should have rendered fast were lagging. Catalogue updates that should have finished overnight were sometimes still running into the morning. Reindexing locked up fresh content for forty minutes at a time. And every so often an import would die mid-run with a database deadlock, requiring a developer to log in and restart it by hand.
None of these were exotic problems. They were the predictable outcome of a Magento store that had been added to, year after year, without anyone going back and clearing the floor. Modules from a dozen different providers, each adding a few extensions of its own. Commercial extensions doing things newer Magento versions now handle natively. A codebase quietly drifting behind the supported versions of the platform it was built on.
For a chain with thirty years of brand equity to protect, that's not just a developer problem. Every slow page is a customer wondering if the site is broken. Every catalogue lag is a price that doesn't match the in-store one. Every failed import is a category that quietly stops being updated. The brand has spent three decades earning a particular kind of trust — and the website was the one place where that trust was thinning.
So the brief wasn't just "make it faster." It was: figure out why this happened, fix the structural causes, and leave behind a foundation the next round of development can build on without inheriting the same problem again.
What we did
We worked back from the symptoms to the causes.
Diagnosis: the code audit
Before changing anything in production, we sat with the codebase and read it. A full Magento code audit gave us — and the MG team — a shared, honest picture of what was actually in there: which modules were stable, which were redundant, where technical debt had concentrated, and which of the visible symptoms had a single common cause underneath them. That document defined the work that followed. Nothing went into the optimisation plan that didn't trace back to a finding in the audit.
Trimming the codebase down
The most consequential finding wasn't dramatic. It was just too much code. Years of additions had left the store running commercial extensions that duplicated default Magento behaviour, plus modules from multiple providers that didn't always agree with each other on how to do the same job. We worked through them: paid extensions came out where the native platform behaviour was good enough; remaining modules were brought up to current, supported versions; the dependency graph got noticeably simpler.
This isn't the most visible part of the work, but it's the one that made everything else possible. A cleaner module set means fewer conflicts, safer upgrades, and a smaller chance that next year's Black Friday will hinge on whether a paid extension's support contract renewed in time.
Making the store feel fast
With the floor cleared, we rebuilt the layers of the application that determine how quickly a page reaches the browser — caching, query patterns, the request lifecycle around catalogue pages.
The result: product and category pages now render in 0.5–0.7 seconds with a warm cache, and 2–5 seconds cold — a 5–6x improvement on the response times we started with. Cold-cache numbers have further to go, and we expect them to keep coming down as work continues.
Making the catalogue keep up
A catalogue with active price and stock changes is only useful if the store can keep up with itself. Two layers had to be fixed:
Reindexing. Time dropped from 40–60 minutes to about 7. For a catalogue this size, that's the difference between a website that reflects current pricing and one that's perpetually a step behind.
Imports. Product imports went from 2 hours to 1. Price imports from 30 minutes to 15. And, just as importantly, the import process itself stopped silently dying on database deadlocks: we built a retry layer on top of the standard Magento importer that treats occasional deadlocks as expected behaviour under high concurrent load and recovers from them automatically, rather than failing the whole job and waiting for someone to notice.
A search that matches how people actually shop
MG's customers don't only search for product names. They search for brands, for categories, for help-centre articles, for promotional landing pages. We moved the store onto a multi-source search architecture that returns matches across all of those in a single result set — with ranking tuned to MG's actual catalogue and shopper behaviour, not generic defaults.
And the process around it
Performance work doesn't stick if the development workflow around it is shaky. So alongside the code, we tightened the work itself, task structure, release process, testing, so that future changes go in safely rather than re-introducing the kind of drift we had just cleared out.
Results
| Metric | Before | After |
|---|---|---|
| Page response time (warm cache) | 3–4s | 0.5–0.7s |
| Page response time (cold cache) | 10s+ | 2–5s |
| Reindex time | 40–60 min | ~7 min |
| Product import (full catalogue, ~75k SKUs) | 2 hours | 1 hour |
| Price import | 30 min | 15 min |
| Import reliability | Frequent manual retries needed | Automatic retry on deadlocks |
The honest framing of this kind of work: for a thirty-year-old brand, the prize isn't a new growth curve hiding inside a faster page load. The prize is that the website finally feels like it belongs to the same company as the store. Catalogue updates finish on time. Reindexing doesn't hold the storefront hostage. Imports recover themselves. And the foundation underneath all of it is clean enough that whatever MG decides to build next sits on something supportable.