Wie wir die Hyvä-Geschwindigkeit mit Lighthouse testen – und die Stolpersteine

Lighthouse-Zahlen sind in Hyvä-Diskussionen allgegenwärtig, auch auf unseren eigenen Seiten. Ein Wert von 94 sagt nichts aus, wenn Sie nicht wissen, wie er gemessen wurde. Testen Sie dieselbe Seite zweimal, erhalten Sie womöglich zwei unterschiedliche Zahlen. Testen Sie falsch, erhalten Sie womöglich einen perfekten Wert für eine Seite, die nie geladen wurde.

Dieser Beitrag erklärt die Methode, mit der wir Hyvä- und Luma-Shops messen. Außerdem listet er die Stolperfallen auf, in die wir selbst getappt sind, damit Sie sie bei der Prüfung Ihres eigenen Shops vermeiden können.

Warum ein Lighthouse-Lauf nicht reicht

Lighthouse simuliert ein Mittelklasse-Smartphone mit gedrosselter Verbindung. Das Ergebnis hängt von der Seite ab, aber auch von der Reaktionszeit des Servers in diesem Moment, vom CDN und vom Rechner, auf dem der Test läuft.

Ein einzelner Lauf kann in beide Richtungen ein Ausreißer sein. Deshalb zitieren wir nie einen einzelnen Lauf. Wir testen jede Seite dreimal und verwenden den Median.

Außerdem testen wir die drei Seitentypen, die für einen Shop am wichtigsten sind: Start-, Kategorie- und Produktseite. Eine schnelle Startseite mit einer langsamen Produktseite macht noch keinen schnellen Shop.

Unsere Methode Schritt für Schritt

1. Nutzen Sie die Lighthouse-CLI. Wir führen Lighthouse 13 über die Kommandozeile aus, nicht in einem Browser-Tab mit installierten Erweiterungen. Browser-Erweiterungen können Skripte einschleusen und das Ergebnis verändern.
2. Nutzen Sie Headless Chrome. Wir starten Chrome mit --headless=new, dem Headless-Modus mit derselben Rendering-Engine wie das normale Chrome.
3. Testen Sie die echte URL. Wir testen die öffentliche URL hinter dem CDN, nicht eine Server-IP oder einen internen Hostnamen. Kunden erreichen den Shop über das CDN, also sollte der Test das auch tun.
4. Leeren und wärmen Sie zuerst den Cache. Nach einem Deploy leeren wir den Cache und rufen jede Seite vor der Messung einmal auf. Sonst misst der erste Lauf einen kalten Cache.
5. Drei Läufe pro Seite. Wir nehmen den Median aus 3 mobilen Läufen plus 1 Desktop-Lauf.
6. Speichern Sie den vollständigen Bericht. Wir speichern die JSON-Ausgabe, damit wir uns LCP, Total Blocking Time, Anzahl der Requests und Übertragungsgröße ansehen können, nicht nur den Wert.

Ein typischer Befehl sieht so aus:

lighthouse https://www.example.com/women/dresses.html \
  --only-categories=performance \
  --chrome-flags="--headless=new" \
  --output=json --output-path=./category-run1.json

Für den Desktop-Lauf ergänzen wir --preset=desktop. Mobil ist der Standard-Formfaktor.

Stolperfalle 1: Bot-Schutz blockiert den Test

Das hat uns überrascht. Unsere nginx-Konfiguration blockiert Bot-User-Agents, die “lighthouse” oder “headless” enthalten. Das ist eine sinnvolle Regel gegen Scraper, blockiert aber auch den Test.

Wird der Request blockiert, liefert der Server eine 403-Fehlerseite aus. Lighthouse misst dann diese kleine Fehlerseite, und der Wert kann hervorragend aussehen. Die Zahl ist echt, beschreibt aber die falsche Seite.

Die Lösung: Führen Sie den Test mit einem normalen Browser-User-Agent aus oder lassen Sie Ihren eigenen Testrechner zu. Prüfen Sie immer die finale URL und den Screenshot im Bericht, bevor Sie einem Wert vertrauen.

Stolperfalle 2: am CDN vorbei testen

Wer den Origin-Server direkt testet, erhält möglicherweise ein langsameres Ergebnis, als Kunden es erleben, weil das CDN nichts cacht. Wer eine Seite testet, die noch nicht im CDN gecacht ist, erhält wiederum ein anderes Ergebnis.

Bei Bildern sind wir auf eine weniger offensichtliche Variante dieses Problems gestoßen. Produktbilder wurden angefragt und im CDN gecacht, bevor Magento die skalierten Versionen erzeugt hatte. Das CDN lieferte auch nach Abschluss des Resize weiter die falsche Antwort aus.

Die Lösung: zuerst catalog:images:resize ausführen, dann den CDN-Cache nach Hostname leeren. Das komplette Bild-Setup behandeln wir in WebP-Produktbilder hinter Cloudflare ausliefern.

Stolperfalle 3: Developer-Modus und fehlende statische Inhalte

Im Developer-Modus erzeugt Magento Dateien bei Bedarf und überspringt viele Optimierungen. Ein Lighthouse-Wert aus dem Developer-Modus sagt über den Produktionsbetrieb fast nichts aus.

Wir messen nur im Produktionsmodus, nach dem Static Content Deploy und mit Indexern im Schedule-Modus. Das Setup beschreiben wir in Produktionsmodus und Deploys für Hyvä-Shops.

Stolperfalle 4: Laborwerte vergleichen, die nicht vergleichbar sind

Auch ein sauberes Luma-Theme auf einem schnellen Server hinter Cloudflare im Produktionsmodus erzielt gute Werte. In unserem eigenen Benchmark erreichte sauberes Luma mobil 88 bis 99, Hyvä 93 bis 100.

Der größere Unterschied lag darin, was der Browser laden muss:

Echte Luma-Shops mit Extensions und Tracking-Skripten erzielen meist deutlich niedrigere Werte als eine saubere Installation. Auf echten Einsteiger-Smartphones fällt ein halbes Megabyte JavaScript stärker ins Gewicht, als das Labor zeigt. Deshalb vergleichen wir die Last, nicht nur den Wert. Die vollständigen Zahlen finden Sie in unserem Hyvä-vs-Luma-Benchmark.

Labordaten und Felddaten

Lighthouse liefert Labordaten: ein simuliertes Gerät, ein Standort, ein Zeitpunkt. Ideal, um Builds zu vergleichen und Regressionen zu erkennen.

Felddaten stammen von echten Besuchern, etwa über den Chrome User Experience Report in der Search Console. Sie spiegeln echte Smartphones, echte Netzwerke und echte Tracking-Skripte wider.

Mit Lighthouse setzen wir Ziele und prüfen jedes Release. Nach dem Launch schauen wir auf echte Nutzerdaten und abgeschlossene Checkouts, denn das ist es, was Kunden tatsächlich erleben. Unser Core-Web-Vitals-Checkliste behandelt die Feldmetriken ausführlicher.

FAQ

Warum weicht mein PageSpeed-Insights-Wert von Ihrem ab?

PageSpeed Insights führt Lighthouse auf den Servern von Google aus, von einem anderen Standort und zu einem anderen Zeitpunkt. Liegen genügend Felddaten vor, zeigt es auch diese an. Kleine Abweichungen zwischen den Tools sind normal – deshalb arbeiten wir mit einer festen Methode und dem Median.

Sollten wir Seiten für angemeldete Nutzer testen?

Für Speed-Ziele testen wir öffentliche Seiten, die für Gäste gecacht werden. Warenkorb, Checkout und Kontoseiten prüfen Sie besser mit echten Nutzerdaten und Funktionstests.

Welchen Wert garantieren Sie zum Launch?

Einen Lighthouse-Performance-Wert von mindestens 89 mobil für Start-, Kategorie- und Produktseiten. Er gilt auf einem für Hyvä optimierten Server und mit den im Projektplan vereinbarten Bildern und Skripten.

Sie möchten wissen, wie Ihr aktueller Shop wirklich abschneidet? Sehen Sie sich an, wie Hyvä im Vergleich zu Luma abschneidet, oder fordern Sie bei uns einen Magento-Audit an – mit Messungen nach genau der hier beschriebenen Methode.