Vitacom Electronics
Romanian electronics retailer, in business since 1991. Already on Magento and Hyvä, still slow, fragile, and exposed. Then we rebuilt it into a 100 PageSpeed store on eight times less hardware.
Vitacom live stores
Explore the public storefront and the B2B and export portals we rebuilt.
The rescue
The store we inherited
Vitacom had invested in the right platform. Magento 2 with Hyvä is an enterprise-grade, high-performance choice, and the intent behind it was clear. But over the years, extensions, customizations, and server changes had piled up from different teams with no unified strategy. The result was not a bad platform. It was a good platform buried under years of technical debt.
When we picked it up, the store was on Magento 2.4.6-p1, left unpatched for roughly two years, with a dozen known security holes open. Frontend PageSpeed sat at 12 and server response peaked near 16 seconds. On a Hyvä store. That is not what Hyvä does when it is built correctly.
Diagnosis
A single page could trigger 15 million database operations
The audit told the real story. One module that was not even in use fired 9.9 million database queries on every single product view. A product-label module added 5.4 million more. Sorting logic threw 2.2 million. Reindexing had drifted so far that Catalog Search took over two hours, where healthy values are measured in seconds.
This is what the wrong build looks like under the hood. Nothing here was Hyvä. Nothing here was Magento. Every one of these numbers came from how the store had been assembled and configured over time.
Core Web Vitals & Performance Metrics
Google's Core Web Vitals metrics are essential to measuring the quality of user experiences. See how our implementation transformed the site's performance scores.
Before
Extremely slow server response
Poor - Delayed first paint
Poor - Delayed loading of main content
Long wait before usability
Excessive main thread blocking
Slow overall experience
Poor - Unstable, shifting interface
After
Near-instant server response
Excellent - Instant first paint
Excellent - Fast content rendering
Interface usable immediately
Zero main thread blocking
Extremely fast visual progression
Excellent - Perfect layout stability
* Core Web Vitals are Google's user-centric metrics that measure real user experience
The method
Secure, simplify, then accelerate
We never bolt performance onto a broken base. Our approach runs in three phases, and the order is deliberate. First we make the platform secure and stable. Then we strip out the bloat and rebuild a clean Magento skeleton. Only then do we introduce the Liquid Framework to deliver the speed. A performance layer on top of a compromised, overloaded setup would only add more risk.
Phase 1
Secure and harden
We rebuilt production on a purpose-built Magento server, a clean Varnish to Nginx to php-fpm stack, and upgraded Magento from 2.4.6-p1 to 2.4.6-p13 with every missing security patch applied. We closed the exposed test sites, retired TLS 1.0 and 1.1, shut the open FTP port, enforced two-factor authentication, and cleaned up stale admin access.
This step is future-proof by design. Even if Vitacom had chosen to walk away after it, they would have inherited a secure, correctly configured environment instead of a liability.
Phase 1
Deploys stopped being a nightmare
Under the old setup, every release was a gamble. Manual deploys broke things, and the client's IT department spent its weeks firefighting instead of building. We put a proper automated pipeline in place: commit, build, test, deploy, with calm and predictable releases. That alone gave the team back their time.
Phase 2
Clean and simplify
We removed roughly 180 modules, including about 135 from the single dominant vendor, and rebuilt the custom modules that could silently corrupt or lose data. Search moved to OpenSearch. Heavy, overlapping extension suites were replaced with lean, targeted solutions. What was left is a clean Magento skeleton, ready to scale.
Less is more. Fewer modules mean fewer conflicts, fewer outages, cheaper upgrades, and up to 31,500 euro a year saved on extension licenses alone.
The results
Same catalog, same Magento, same Hyvä. A completely different store, on a fraction of the hardware.
99.92%
Server response
Faster TTFB, 16s to 12ms
8x less
Hardware
64 to 8 cores, 256 to 32 GB
12 → 100
PageSpeed
Frontend score
~180
Modules removed
Extension bloat stripped out
15M removed
Database load
All from third-party modules
€31,500/yr
License savings
Extensions retired
Phase 3
Accelerate, on eight times less hardware
On the clean foundation, we rolled out the Liquid Framework and Hyvä Checkout. Then we did something that tells the whole story: we moved the store off its oversized 64-core, 256 GB server and onto a right-sized 8-core, 32 GB machine tuned for Magento. Eight times less hardware, and the server load actually dropped.
From 16 seconds to 12 milliseconds
The headline number is server response time. It went from 15,814 milliseconds to 12. That is a 99.92 percent improvement, roughly 1,300 times faster, on a server with a fraction of the resources.
The transformation (before and after)
The mess we inherited on the left, the store we delivered on the right. Drag to compare.
Hyvä Metrics
First Contentful Paint (FCP)
459ms
Largest Contentful Paint (LCP)
539ms
Cumulative Layout Shift (CLS)
0
Old Metrics
First Contentful Paint (FCP)
2,508ms
Largest Contentful Paint (LCP)
2,900ms
Cumulative Layout Shift (CLS)
0
See the difference
The rebuild turns years of accumulated technical debt into a fast, stable, high-converting store.
The results
Same stack, a completely different store
Same catalog. Same Magento. Same Hyvä. PageSpeed went from 12 to 100. First Contentful Paint landed at 459ms, Largest Contentful Paint at 539ms, and Time to First Byte collapsed to 12ms. Cumulative Layout Shift hit zero. The platform that could not clear a 12 now runs a perfect PageSpeed, and it does it on a fraction of the hardware.
The rescue, in short
Vitacom had the right platform and the wrong build. We secured it, stripped years of bloat, and only then unleashed the speed.
Inherited a Magento 2.4.6-p1 store on Hyvä, unpatched for two years, sitting at a 12 PageSpeed with server response peaking near 16 seconds.
Found 240+ third-party modules, 51 custom modules, 12 open security holes, and single pages triggering up to 15 million database operations.
Rebuilt in three phases: secure and harden, clean and simplify, then accelerate with the Liquid Framework and Hyvä Checkout.
Delivered a 100 PageSpeed and a 12 millisecond server response, on a server with eight times less hardware.
Our approach (secure, simplify, accelerate)
Secure and harden
Rebuilt production on a purpose-built Magento server, upgraded 2.4.6-p1 to 2.4.6-p13 with every missing patch, closed the exposed test sites, retired TLS 1.0 and 1.1, and enforced proper access controls.
Clean and simplify
Removed roughly 180 modules, rebuilt the custom modules that could corrupt data, moved search to OpenSearch, and cut the query storms down to a clean Magento skeleton.
Accelerate
Rolled out the Liquid Framework and Hyvä Checkout on the clean foundation, then right-sized the server from 64 cores to 8. Eight times less hardware, roughly 1,300 times faster.
Why it matters
The technology was never the problem
This is the case study every merchant should read before choosing a Magento partner. Hyvä and Magento deliver exactly what they promise. Whether you get a 12 or a 100 comes down to who builds it. We are not an agency that uses Magento now and then and invoices for it. We are Hyvä and Magento community members, and we contribute to the core code that makes the ecosystem better. That is the difference between a store that fails on great technology and one that flies on it.
