The store is on Hyvä and it's still slow. Where the problem actually is

We get this question often from stores we didn't build: they migrated to Hyvä, paid the licence, and PageSpeed is still red. The frustration is legitimate — but Hyvä never promised what many people think it promised.

Hyvä fixes the frontend. It cannot repair a slow backend, undersized hosting, or 40 badly written extensions.

Here are the five causes we find, in order of frequency.

1. High TTFB — the problem is the server, not the theme

Time To First Byte measures how long the server takes to send the first byte. If your TTFB is over 600 ms, the theme is irrelevant: the page starts loading late however light the frontend is.

• Check that Varnish is active and genuinely serving from cache, not merely installed.
• Check that Redis is configured for sessions and cache, not just running.
• Look at Magento's indexing — stuck indexes, or “update on save” mode on a large catalogue, will destroy performance.
• Check the server's actual resources. Magento on shared hosting cannot be fast.

2. Extensions that inject JavaScript

Hyvä removes Knockout and RequireJS from the theme. It cannot remove the scripts third-party extensions add. A chat widget, a reviews extension and three marketing ones can reintroduce exactly the weight you just removed.

The check is simple: open the Network tab, filter to JS, and look at what loads before first paint. Anything not essential to rendering has to be deferred or removed.

3. Unoptimised images

The most mundane cause and the most common. An 800 KB product image served at 400 px wide ruins LCP by itself, whatever the theme.

• Serve WebP or AVIF, with a fallback.
• Size images to what's actually displayed, not to what the client uploaded in the admin.
• Put width and height on every image — otherwise you pay for it in CLS.
• Lazy-load everything below the fold, but never the main product image.

4. Third-party scripts

Google Tag Manager with 15 tags, a Meta pixel, heatmaps, chat, A/B testing. Each looks harmless. Together they add seconds.

Measure them: temporarily disable GTM and compare. Often half the speed problem sits in things the marketing team added, not the development team.

5. The Hyvä implementation itself

This happens too: a migration done in a hurry, where old components were ported rather than rewritten, or where compatibility with Luma extensions was kept through compat layers. The result is Hyvä on paper and Luma in practice.

The clear sign: if requirejs or knockout still appear in the JS bundle, the migration isn't complete.

How to find out which of the five applies to you

1. 01Measure TTFB separately from everything else. If it's high, stop there — nothing else matters until you fix it.
2. 02Run PageSpeed on field data, not lab data. Lab data lies beautifully.
3. 03Open Network and sort by size. The first five resources usually tell you everything.
4. 04Compare with and without GTM.
5. 05Search the page source for requirejs.

What we do when we take on a slow Hyvä

We start with the code audit: which extensions you have, what each one injects, and what was ported badly during the migration. The report produces the list of interventions, in order of impact on sales — not in order of how easy they are.

If the store needs continuous care rather than a one-off fix, the maintenance retainer includes Core Web Vitals monitoring, so you don't end up here again in a year. There's more on what we do on the Hyvä page and on performance optimisation.