121 Core Web Vitals Messungen: Zwei Hypothesen widerlegt

👁 117 Aufrufe

Wir haben diese Website mehrere Tage lang optimiert und nach jeder Änderung eine Messreihe mit Lighthouse durchgeführt statt nur eines einzelnen Durchlaufs. Das Ergebnis war ernüchternd: Zwei unserer besten Hypothesen erwiesen sich als schädlich, und den wahren Schuldigen fanden wir erst, als wir aufhörten, einzelnen Ergebnissen zu vertrauen. 121 Messungen in neun Serien. Hier ist, was dabei herauskam.

Grundregel: Messen Sie Serien, nicht einzelne Durchläufe

Das klingt banal, aber fast niemand macht es - und deshalb sind fast alle „Optimierungen“ im Internet Zufall.

Wir haben Lighthouse zehnmal hintereinander auf derselben unveränderten URL ausgeführt. Die Ergebnisse schwankten zwischen 60 und 96 Punkten. Hätten wir irgendetwas im Code geändert und nach der Änderung einen 96er-Durchlauf und vorher einen 60er erwischt, hätten wir einen Erfolg verkündet. Wäre es umgekehrt gekommen, hätten wir eine gute Korrektur zurückgenommen.

Pro-Tipp: Mindestens fünf Durchläufe pro Variante, vergleichen Sie Mediane und geben Sie immer die volle Spannweite an. Wenn sich die Bereiche vor und nach der Änderung überschneiden, haben Sie kein Ergebnis - Sie haben Rauschen.

Hypothese 1, widerlegt: CSS in eine Datei zusammenführen

Der klassische Rat: weniger HTTP-Anfragen, also Stylesheets zusammenführen. Wir haben ein Paket aus mehreren CSS-Dateien des Themes gebaut, die Korrektheit der relativen Pfade und die Reihenfolge der Imports geprüft und ausgerollt. Messung:

Warum es nicht funktionierte: Fünf separate Stylesheets sind fünf kurze Parsing-Aufgaben, die der Browser mit anderen verschachteln kann. Ein Stylesheet mit 69 KB ist eine lange Aufgabe, die sich nicht unterbrechen lässt - und lange Aufgaben sind genau das, was TBT misst. Wir haben die Anzahl der Anfragen verringert und das Flüssigkeitsgefühl verschlechtert.

Pro-Tipp: Mit HTTP/2 ist die Anzahl der Anfragen kein Problem mehr. Das Zusammenführen von Dateien ist ein Rat aus HTTP/1.1-Zeiten und kann heute schaden.

Hypothese 2, widerlegt: Verzögerung von Hintergrund-Anfragen

Die Shop-Seite sendete beim Start mehrere AJAX-Anfragen. Wir haben sie durch requestIdleCallback mit einem Timeout von 3000 ms verzögert - eine Lehrbuch-Lösung. Messung:

• TBT des Shops: 64 ms → 265 ms
• Start der Anfragen verschob sich vom Bereich 183-1329 ms auf 383-2411 ms

Warum es nicht funktionierte: Das Timeout von 3000 ms führte dazu, dass der Browser alle verzögerten Anfragen in einer Serie abfeuerte - und zwar genau im Fenster, in dem TBT gemessen wird. Statt die Arbeit zu verteilen, haben wir sie in einen Stau gepackt.

Pro-Tipp: requestIdleCallback mit kurzem Timeout ist nicht „mach es später“. Es ist „mach es später, aber auf jeden Fall“. Ohne Timeout oder mit sehr langem verhält es sich anders.

Was funktionierte und warum

Eine Zeile, die 70 ms erzwungene Layout-Neuberechnung eliminierte

Ein Skript las die Position eines Elements aus und änderte sie sofort. Das verursacht erzwungene Layout-Neuberechnung - der Browser muss alles unterbrechen und die Geometrie der Seite berechnen. Lighthouse zeigte 70-75 ms in einer Zeile an.

Die Korrektur ist eine Zeile:

if (window.requestAnimationFrame) requestAnimationFrame(miejsce); else miejsce();

Das Auslesen wird in den Moment verschoben, in dem der Browser das Layout ohnehin neu berechnet. Die Kosten fallen auf null, und der Code macht genau dasselbe.

Entfernung aus dem kritischen Pfad, was die Seite nicht nutzt

Das Template-Stylesheet wog 75.094 Bytes und wurde auf jeder Unterseite geladen, obwohl die meisten Seiten keines dieser Templates verwenden. Die Basisversion hat 9.708 Bytes - also gingen 87% des Gewichts umsonst drauf. Ähnlich jQuery, das trotz fehlenden Konsumenten geladen wurde.

Pro-Tipp: Bevor Sie mit der Minifizierung beginnen, prüfen Sie, ob die Datei auf dieser Seite überhaupt benötigt wird. Entfernung schlägt Kompression jeden Tag.

Der wahre Schuldige: der Werbe-Stack

Nach Verwerfung beider Hypothesen stellten wir eine andere Frage: Woher kommt die Streuung von 60-96 Punkten. Wir blockierten Werbe- und Consent-Domains und wiederholten die Serie:

Die Schlussfolgerung war brutal: Mehrere Tage lang haben wir Code optimiert, der nur für einen Bruchteil des Problems verantwortlich war. Die Streuung kam von externen Skripten, auf die wir keinen Einfluss haben und die wir nicht entfernen können, weil sie die Website finanzieren.

Pro-Tipp, der wichtigste aus dem ganzen Text: Bevor Sie irgendetwas optimieren, messen Sie, wie viel des Ergebnisses von Ihnen kommt und wie viel von externen Skripten. Führen Sie eine Serie mit blockierten Drittanbieter-Domains durch. Wenn der Unterschied groß ist, liegt Ihre reale Obergrenze viel niedriger, als Sie denken - und es ist besser, das vor drei Tagen Arbeit zu wissen als danach.

Zwei Fallen der Tools, in die wir nebenbei tappten

Pingdom kann bei der Kompression lügen

Der Bericht behauptete, der Server komprimiere Antworten nicht. Wir prüften direkt: Der Server sendet br und zstd, und wenn man explizit nach gzip fragt, liefert er die Startseite in 71.306 Bytes statt 289.394 unkomprimiert. Das Tool deklarierte einfach keine Unterstützung für neuere Algorithmen. Die Ablauf-Header waren auch vorhanden.

Das Löschen des gesamten Cache kann das Aussehen zerstören

Das Plugin löschte bei jeder Veröffentlichung den gesamten Cache zusammen mit den minifizierten CSS-Dateien. Im Fenster zwischen Löschung und Neuaufbau verlinkte die Seite auf ein Stylesheet, das nicht existierte - und zeigte sich für einen Moment als nacktes HTML. Bei einem Dutzend Beiträgen pro Tag passierte das regelmäßig.

Pro-Tipp: Nach Veröffentlichung eines Beitrags punktuell löschen - nur den Beitrag selbst, die Startseite, seine Kategorien und den RSS-Feed. Ein neuer Artikel ändert nicht den Inhalt der CSS-Datei, also gibt es keinen Grund, sie zu löschen.

Checkliste, wenn Sie das bei sich wiederholen möchten

1. Führen Sie zehn Messungen auf einer unveränderten Seite durch. Notieren Sie Median und Spannweite. Das ist Ihr Rauschen.
2. Wiederholen Sie die Serie mit blockierten externen Domains. Der Unterschied ist die Obergrenze Ihrer Möglichkeiten.
3. Erst jetzt ändern Sie jeweils eine Sache und messen in Serien, nicht mit einzelnen Durchläufen.
4. Wenn sich die Bereiche vor und nach der Änderung überschneiden - nehmen Sie die Änderung zurück. Fehlender Beweis ist kein Beweis.
5. Beginnen Sie mit Entfernung, nicht mit Minifizierung. Eine Datei, die nicht existiert, ist immer am schnellsten.
6. Suchen Sie nach erzwungenen Layout-Neuberechnungen. Sie können 70 ms für eine Zeile Korrektur wert sein.

// weiterlesenCSS-Dateien nicht zusammenfassen - Messung der Performance-KostenAnleitungenGTA 6 früher spielen: Neuseeland-Trick auf Xbox und PS5AnleitungenGPT-6 Cyber Zugang: Daybreak Red und Blue im ÜberblickAnleitungen

Kinetyra