Performance-Best-Practices: Critical CSS, Lazy Loading, warum Hyvä spürbar schneller ist als Luma
Performance-Best-Practices: Critical CSS, Lazy Loading, warum Hyvä spürbar schneller ist als Luma
~8 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026
Kapitel 1 hat bereits erklärt, warum Hyvä grundsätzlich schneller ist als Luma (weniger JavaScript, serverseitiges Rendering). Dieses Kapitel geht einen Schritt weiter: konkrete Techniken, um diese Grundgeschwindigkeit noch weiter auszunutzen.
Critical CSS
Auch eine gebaute Tailwind-styles.css kann, je nach Projektgröße, mehrere hundert Kilobyte umfassen - für die allererste sichtbare Bildschirmfläche ("above the fold") wird aber nur ein Bruchteil davon gebraucht. Hyvä-Themes unterstützen das Extrahieren von Critical CSS: ein kleiner, inline in den <head> eingebetteter CSS-Block mit genau den Regeln, die für den sichtbaren Bereich beim ersten Rendern gebraucht werden. Der Rest der CSS-Datei wird asynchron nachgeladen, ohne das erste Rendern zu blockieren.
Tipp: Critical CSS lohnt sich vor allem für stark besuchte Einstiegsseiten (Startseite, Kategorieseiten) - für seltener besuchte Seiten ist der Konfigurationsaufwand oft größer als der tatsächliche Performance-Gewinn.
Lazy Loading von Bildern
Bilder außerhalb des sichtbaren Bereichs (z. B. weiter unten auf einer langen Kategorieseite) sollten das native loading="lazy"-Attribut nutzen - der Browser lädt sie dann erst, wenn sie sich dem sichtbaren Bereich nähern, statt alle Bilder sofort beim Seitenaufruf zu laden.
<img src="<?= $escaper->escapeUrl($product->getImageUrl()) ?>"
loading="lazy"
alt="<?= $escaper->escapeHtmlAttr($product->getName()) ?>">Achtung: Das erste, sofort sichtbare Bild einer Seite (z. B. das Hauptbild auf der Produktseite) sollte kein loading="lazy" bekommen - das würde das für den Largest Contentful Paint entscheidende Bild künstlich verzögern. Lazy Loading gehört auf Bilder, die beim ersten Rendern ohnehin noch nicht sichtbar sind.
Passende Bildgrößen über view.xml
Wie in Kapitel 4 erwähnt, definiert etc/view.xml Bildgrößen pro Kontext (Produktliste, Produktseite, Galerie-Thumbnail). Ein häufiger Performance-Fehler ist, ein großformatiges Originalbild überall unverändert einzubinden statt kontextgerecht verkleinerte Varianten zu nutzen - das kostet unnötig Ladezeit und Bandbreite, besonders auf Mobilgeräten.
Weniger, gezieltere Alpine-Komponenten
Auch wenn Alpine winzig ist: Sehr viele, tief verschachtelte x-data-Bereiche auf einer Seite erzeugen trotzdem Overhead beim Initialisieren. Faustregel: eine Alpine-Komponente pro logisch zusammengehörigem UI-Bereich (wie die gesamte Team-Filterung aus Kapitel 21 in einem einzigen x-data), statt für jedes einzelne Element eine eigene.
Den produktiven Build immer testen
Der Watcher aus Kapitel 5 erzeugt unminifiziertes, unoptimiertes CSS für schnellere Entwicklungs-Rebuilds. Performance-Messungen (Lighthouse, PageSpeed Insights) sollten deshalb immer gegen den produktiven Build laufen (npm run build, gefolgt von der vollständigen Deploy-Sequenz aus Kapitel 5/27), nicht gegen die Watcher-Version - sonst fallen die Ergebnisse künstlich schlechter aus.