Your Hyvä Store Is Still Slow. Here Is Why.

You did the sensible thing. You moved off Luma, paid for a Hyvä build, and waited for the numbers to move. They did not. The store still feels heavy, the mobile score is still embarrassing, and someone on your team is now asking whether Hyvä was worth it.

It was. The theme is almost never the reason a Magento store is slow, and nobody told you that before you signed.

Hyvä does not guarantee performance. The implementation does.

Hyvä replaces the frontend. It gives you a lean template layer without Luma's JavaScript baggage, and it makes development considerably cheaper, because you are no longer fighting Knockout and RequireJS on every change.

What Hyvä does not hand you is a score. Look at Hyvä stores in HTTP Archive and the median Lighthouse score sits around 47.5. Not 90, not 100. That median is the whole argument: the same theme, in different hands, produces completely different results. "We installed Hyvä" is not an answer to "how fast is my store".

What it does not touch is everything that happens before the browser receives a single byte. If your server takes eight seconds to produce the HTML, the fastest theme in the ecosystem will still deliver a slow page. Hyvä fixed the part you could see. The part you could not see was never addressed.

What "still slow" almost always means

In the stores we take over, the cause is nearly always one of three things, and usually all three at once.

• Third-party modules nobody audited. Every extension you installed to solve a small problem is still running on every request, including the ones you stopped using two years ago.
• A database doing far more work than the page needs. Uncached queries multiply quietly. We have opened a single product page and counted 15 million database operations behind it, none of them coming from Magento itself.
• A server tuned for the wrong thing. Redis, Varnish and the cache layers are usually present and usually misconfigured, so the store pays for infrastructure it is not actually using.

None of that is a Hyvä problem. All of it survives a re-theme untouched, and all of it is still there once the invoice for the theme is paid.

How to check whether a performance figure is real

Performance figures are easy to assert and hard to check. A good score can come from a single run, on a carefully chosen page, on a good day. What matters is not the number itself, but whether you can get to it yourself.

Before you believe any figure, ours included, ask for four things.

• Field data, not lab data. A PageSpeed score is a single test on a simulated network, and it changes between runs. The Chrome UX Report and the Core Web Vitals report in Search Console measure real visitors on their real phones.
• The origin measured, and the time window. CrUX reports the 75th percentile over a rolling 28-day window, for one specific origin. If nobody tells you which origin and which window, the number means nothing.
• Before and after on the same property. A comparison is only worth reading if both ends come from the same source, for the same domain, measured the same way.
• The date it was read. Field data moves every week. A figure without a date is a figure without a guarantee.

If a figure passes those four tests, you can verify it yourself, without us. If it does not, it is not a measurement, it is a claim. That is why the figures below come with the method next to them.

Our proof, with the method in the open

Equitana was selling equestrian equipment on Magento 1, six years after the platform reached end of life. We rebuilt the store on Magento 2, Hyvä and Liquid Framework, and moved over 14,500 products, over 300 categories, over 3,400 customer accounts and over 12,000 orders.

The figures below are the 75th percentile from the Chrome UX Report for the origin www.equitana.ro, read on 29 September 2026. "Before" is the last window carrying Magento 1 traffic only, 19 July to 15 August 2026. "After" is the window from 30 August to 26 September 2026, entirely on the new store.

• LCP on phones: 4,234 ms before, 1,109 ms after. How long a real visitor waits to see the main content.
• Server response on phones: 3,653 ms before, 344 ms after. Precisely the part a change of theme does not touch.
• LCP on desktop: 3,502 ms before, 1,001 ms after. Layout shift on phones went from 0.07 to 0.

The Core Web Vitals report in Search Console, for the equitana.ro domain property, read on 4 October 2026, says the same thing a different way. On phones, before: 3 good URLs, 1,194 needing improvement, 198 poor. After: 1,761 good URLs and zero in the other two buckets. That is 0.2% of URLs good before, and 100% after.

The full case study, with the weekly charts and the source of every figure, is here: Equitana, from Magento 1 to Hyvä.

The store that was already on Hyvä

Equitana came off a dead platform, so it is an easy case to explain. Vitacom was not.

Vitacom sells electronics across B2C, B2B and export, and has traded since 1991. When they came to us the store was already on Hyvä. And it was still slow, still fragile and still exposed. By the usual logic, Hyvä had failed.

We did not change the platform and we did not replace the theme. We hardened the server and brought Magento current on every patch, cleaned out the third-party module layer, rebuilt the custom modules that could corrupt data, moved search to OpenSearch, and rebuilt the data and caching layers. Same platform, same theme, three storefronts that work: public, B2B and export.

Measured on real users, again from the Chrome UX Report, 75th percentile for the origin www.vitacom.ro, figures read on 30 September 2026. In the 28 day window ending 27 December 2025, phone LCP was 3.08 s and server response 2.34 s. In the window ending 26 September 2026, phone LCP was 1.35 s and server response 0.67 s. The theme was the same throughout. What changed was everything underneath it.

Hyvä was never the problem. The implementation was.

The project is documented in the Vitacom case study.

The test you can run in five minutes

Load a product page and look at time to first byte, not at the overall score. If it is under 200 ms and the score is still poor, the frontend is worth investigating. If it is measured in seconds, no amount of frontend work will save you, and anyone proposing a re-theme is selling you the wrong thing.

One warning about that test. If Varnish is serving the page from cache, time to first byte looks excellent and tells you nothing about the store. Test a page the cache does not have, for example a product nobody has opened today, or add a meaningless query parameter to the URL to force a fresh generation. The gap between the cached page and the generated one is exactly the work the theme does not do. If the first is fast and the second takes seconds, you have found your problem.

Then run the check on real data, for your own domain. The Core Web Vitals report in Search Console shows how many of your URLs are good, how many need improvement and how many are poor, separately for phones and desktops. If you moved to Hyvä a few months ago and the "good" column on phones has not moved, that is your answer: the change never reached real visitors.

That is the difference between a store that needs tuning and a store that needs a rescue. If you want the step-by-step method on Core Web Vitals, it is in a separate article.

Why take our word for it

LIQUIDLAB works only with Magento. We have been a Hyvä partner since 2024 and we were the first officially certified Hyvä Partner in Romania. We do not only use Hyvä and Magento, we contribute to them: the modules and fixes we put back into the community are public, at github.com/liquidlab-agency. Everything claimed above can be checked independently.

What to do next

If the numbers above sound like your store, get the codebase and the server looked at properly before spending anything else on the frontend. Our deep code and server analysis costs 999 EUR and includes 30 days of support afterwards. The output is a recovery and modernisation plan that belongs to you and works with any agency, including the one you already have. There is no lock-in, and that is deliberate.

If you want the same team to carry the plan through, we offer full Magento services, from audit and takeover to maintenance with an SLA.

The technology was never the thing holding your store back. Find out what was: book a 30-minute call, no strings attached.