---
title: "Hyvä vs. Luma, nachgemessen"
description: "Was Luma wirklich langsam macht, was Hyvä ändert und wie Sie den Unterschied am eigenen Katalog messen, statt sich auf Anbieterangaben zu verlassen."
author: "Luboš Zápotočný"
published: "2026-05-21"
language: "de"
canonical: "https://zapolu.com/de/blog/hyva-vs-luma/"
---

# Hyvä vs. Luma, nachgemessen

Jede Diskussion über Magento-Performance landet früher oder später
bei derselben Frage: Ist das Frontend das Problem, und ist Hyvä die
Antwort? Beide Male gilt: meistens ja. Diese Einschätzung sollten
Sie jedoch weder von uns noch von einem Anbieter mit
Verkaufsinteresse ungeprüft übernehmen. Dieser Beitrag erklärt, was
die beiden Frontends strukturell unterscheidet und wie Sie den
Abstand am eigenen Shop messen, bevor Sie ein Budget dafür
freigeben.

## Warum Luma per Konstruktion langsam ist

Luma, das mitgelieferte Magento-Frontend, ist langsam wegen
Entscheidungen, die um 2015 herum in der Plattform getroffen
wurden:

- **RequireJS lädt JavaScript als Abhängigkeits-Wasserfall.** Der
  Browser erfährt erst nach dem Ausführen des bereits Geladenen, was
  er als Nächstes holen muss. Auf einer kalten Mobilfunkverbindung
  heißt das: Roundtrip um Roundtrip, bevor die Seite interaktiv
  wird.
- **Mehrere schwere JS-Schichten werden gleichzeitig ausgeliefert.**
  jQuery, KnockoutJS und Magentos Knockout-basierte
  UI-Component-Schicht werden auf jeder Seite ausgeliefert, ob die
  Seite sie nutzt oder nicht.
- **Layout-XML rendert mehr als nötig.** Blöcke, die niemand sieht,
  werden trotzdem gebaut, und Drittanbieter-Extensions hängen ihre
  Skripte global ein statt dort, wo sie gebraucht werden.

Nichts davon taucht im Profiler als einzelne langsame Zeile auf. Es
zeigt sich als Megabytes an JavaScript und ein Main Thread, der auf
Mittelklasse-Telefonen sekundenlang beschäftigt ist. Genau diese
Geräte nutzen Ihre Kunden.

## Was Hyvä tatsächlich ändert

[Hyvä](https://hyva.io) ist ein vollwertiges Ersatz-Theme. Es
ersetzt den Luma-Frontend-Stack vollständig: kein RequireJS, kein
jQuery, kein Knockout. Die Templates sind serverseitig gerendertes PHP mit
[Alpine.js](https://alpinejs.dev) für die Interaktivität und
Tailwind für die Styles. In unseren eigenen Messungen fällt die
JavaScript-Payload typischerweise von deutlich über einem Megabyte
auf klar unter hundert Kilobyte, was Sie im Netzwerk-Tab jedes
Browsers am Demo-Shop selbst nachprüfen können.

Dabei gilt eine wesentliche Einschränkung: Jede Extension, die das
Frontend berührt, braucht ein Hyvä-kompatibles Modul oder einen
Rewrite. Für populäre Extensions ist das Kompatibilitäts-Ökosystem
ausgereift, für Ihr maßgeschneidertes Modul von 2019 ist es
leer. Im Extension-Audit stecken deshalb die echten Kosten eines
Hyvä-Projekts; die Theme-Lizenz ist der kleinere Posten.

Der Checkout ist eine eigene Entscheidung: Hyvä behält von Haus aus
den Luma-Checkout, sofern Sie nicht Hyvä Checkout oder eine headless
Variante einführen, und gerade dort entscheidet sich oft die
Conversion.

## Wie Sie selbst messen

Vergleichen Sie nicht Ihren Produktions-Shop mit einer Hyvä-Demo;
das vermengt Theme, Katalog, Hosting und Drittanbieter-Skripte. Ein
fairer Vergleich sieht so aus:

1. **Holen Sie die Baseline aus Felddaten, nicht nur aus
   Lighthouse.** CrUX (über PageSpeed Insights) zeigt, was echte
   Besucher über 28 Tage erlebt haben: LCP, INP, CLS. Ein
   ungedrosselter Lab-Lauf auf einem schnellen Entwicklerrechner kann
   weit besser aussehen als das, was echte Besucher auf
   Mittelklasse-Telefonen bekommen.
2. **Trennen Sie Frontend und Backend.** Die TTFB wird von Backend
   und Netzwerk bestimmt (Server, DNS, TLS); liegt die TTFB bei
   1,5 s, löst ein Theme-Wechsel das Problem nicht. Das meiste
   nach der TTFB ist das, was ein Frontend-Wechsel adressieren kann;
   ein langsames Backend oder Netzwerk braucht seine eigene Lösung.
3. **Setzen Sie den Vergleich ehrlich auf.** Gleicher Server,
   gleicher Katalog, gleiche Extensions aktiv, Drittanbieter-Tags
   entweder in beiden Fällen an oder in beiden aus. Lassen Sie
   Lighthouse mehrfach laufen und vergleichen Sie Mediane, denn
   Einzelläufe schwanken stark.
4. **Verfolgen Sie die Geschäftskennzahl parallel.** Conversion nach
   Geräteklasse, vorher und nachher. Der Score ist am Ende nur ein
   Hilfswert.

## Wann die Antwort nicht Hyvä ist

Hyvä ist unsere Standardempfehlung für Luma-Shops mit
Performance-Problem, aber keine automatische Antwort. Ein Shop mit
4 Sekunden TTFB hat ein Backend-Problem. Ein Shop, der bereits auf
PWA Studio läuft, steht vor einer anderen Fragestellung. Und ein
Shop kurz vor dem Replatforming
sollte in keines von beiden investieren. Das ist zuerst eine Frage
von [Replatforming oder Reparatur](/de/blog/replatforming-oder-reparatur/).

Wenn Sie die Messung nicht selbst durchführen möchten, übernimmt
das unser
[Performance-Audit](/de/services/performance-audit/), mit
Frontend/Backend-Split, Extension-Audit und priorisierter
Maßnahmenliste. So beginnt
auch der Großteil unserer [Magento-Arbeit](/de/services/magento/).