Die Ecomonic Times reduzierte den INP-Wert um das 30-Fache von TBT und den Wechsel zu Next.js, was zu einer Senkung der Absprungrate um 50% und einer Steigerung der Seitenaufrufe um 43% führte.
Interaction to Next Paint (INP) ist ein Messwert, mit dem bewertet wird, wie gut eine Website auf Nutzereingaben reagiert. Gute Reaktionsfähigkeit bedeutet, dass eine Seite schnell auf Nutzerinteraktionen reagiert. Je niedriger der INP-Wert einer Seite ist, desto besser kann sie auf Nutzerinteraktionen reagieren.
Der ungenaue Anfang
Als Google INP ursprünglich als experimentellen Messwert einführte, der sich zu einem der Core Web Vitals-Messwerte entwickeln könnte, stellte sich das Team der Economic Times die Herausforderung, dieses Problem zu beheben, bevor es zu einem konsolidierten, da eine erstklassige Nutzererfahrung für unsere wichtigsten Unternehmenswerte von entscheidender Bedeutung ist.
Der INP-Wert war bisher einer der am schwierigsten zu ermittelnden Messwerte. Am Anfang war unklar, wie sich die INP effektiv messen lässt. Erschwerend erwies sich jedoch der fehlende Community-Support – darunter auch die meisten RUM-Anbieter (Real User Monitoring), die diese Funktion noch nicht unterstützen. Wir nutzten jedoch Google RUM-Tools wie den Chrome User Experience Report (CrUX), die web-vitals JavaScript-Bibliothek und andere, die diese unterstützen. So erhielten wir einen Eindruck davon, wo wir standen, als wir den bevorstehenden Weg evaluierten. Als wir anfingen,lag unser INP auf der Ursprungsebene bei fast 1.000 Millisekunden.
Bei der Korrektur des INP-Werts in diesem Feld stellte sich heraus, dass einer der Lab-Messwerte, die Sie anvisieren sollten, Total Blocking Time (TBT) (Gesamtblockierungszeit) anstreben sollte. TBT wurde bereits gut dokumentiert und von der Community unterstützt. Obwohl die Core Web Vitals-Anforderungen bereits erreicht waren, schnitten wir im Bereich TBT nach mehr als 3 Sekunden nicht so gut ab.
Was ist TBT und wie haben wir es verbessert?
TBT ist ein Lab-Messwert, der die Reaktionsfähigkeit einer Webseite auf Nutzereingaben während des Seitenaufbaus misst. Jede Aufgabe, deren Ausführung mehr als 50 Millisekunden dauert, wird als lange Aufgabe betrachtet. Die Zeit nach dem 50-Millisekunden-Grenzwert wird als Blockierzeit bezeichnet.
Zur Berechnung von TBT wird die Summe der Blockierzeit aller langen Aufgaben beim Seitenaufbau berechnet. Wenn z. B. beim Laden zwei lange Aufgaben auftreten, wird die Blockierzeit wie folgt bestimmt:
- Aufgabe A dauert 80 Millisekunden (30 Millisekunden über 50 Millisekunden).
- Aufgabe B dauert 100 Millisekunden (50 Millisekunden über 50 Millisekunden).
Die TBT der Seite beträgt: 80 Millisekunden (30 + 50). Je niedriger der TBT ist, desto besser. Außerdem korreliert TBT gut mit INP.
Hier ein kurzer Lab-Vergleich zu unserem TBT vor und nach den Maßnahmen zur Verbesserung:
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">Aufwand für Hauptthread minimieren
Der Hauptthread des Browsers übernimmt alles, vom Parsen von HTML über das Erstellen des DOMs über das Parsen von CSS und Anwenden von Stilen bis hin zum Auswerten und Ausführen von JavaScript. Der Hauptthread verarbeitet auch Nutzerinteraktionen, d. h. Klicken, Tippen und Tastendruck. Wenn der Hauptthread mit anderen Aufgaben beschäftigt ist, reagiert er möglicherweise nicht effizient auf Nutzereingaben und kann die Nutzererfahrung beeinträchtigen.
Das war die schwierigste Aufgabe für uns, da wir unsere eigenen Algorithmen zur Erkennung der Nutzeridentität für die Anzeigenbereitstellung basierend auf dem Abostatus und Drittanbieter-Skripts für A/B-Tests, Analysen und mehr haben.
Zunächst haben wir kleinere Schritte unternommen, um beispielsweise weniger wichtige Geschäfts-Assets zu laden. Zweitens haben wir requestIdleCallback für nicht kritische Aufgaben verwendet, was dazu beitragen kann, TBT zu reduzieren.
if ('requestIdleCallback' in window) {
this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}
Bei der Verwendung von requestIdleCallback wird empfohlen, ein Zeitlimit anzugeben, da damit sichergestellt wird, dass der Callback sofort nach Ablauf des Zeitlimits ausgeführt wird, wenn die angegebene Zeit verstrichen ist und der Callback nicht bereits aufgerufen wurde.
Zeit für die Skriptauswertung minimieren
Außerdem haben wir mithilfe von ladebaren Komponenten Drittanbieterbibliotheken per Lazy Loading geladen. Außerdem haben wir nicht verwendetes JavaScript und CSS entfernt, indem wir ein Profil der Seite mit dem coverage-Tool in den Chrome-Entwicklertools erstellt haben. So konnten wir Bereiche identifizieren, in denen Baumbewegungen erforderlich waren, um beim Seitenaufbau weniger Code zu senden und so die anfängliche Bundle-Größe der Anwendung zu reduzieren.
DOM-Größe reduzieren
Per Lighthouse erhöhen große DOM-Größen die Arbeitsspeichernutzung, führen zu längeren Neuberechnungen des Stils und kostspieligen Umbrüchen im Layout.
Wir haben die Anzahl der DOM-Knoten auf zwei Arten reduziert:
- Zuerst haben wir unsere Menüpunkte auf Nutzeranfrage hin gerendert (auf Klick). Die DOM-Größe wurde um etwa 1.200 Knoten reduziert.
- Zweitens haben wir weniger wichtige Widgets per Lazy Loading geladen.
Aufgrund all dieser Bemühungen haben wir TBT deutlich reduziert und unser INP entsprechend um fast 50 % gesenkt:
An diesem Punkt gingen uns fast keine einfachen Erfolge aus, um TBT (und INP nach Proxy) weiter zu reduzieren, aber wir wussten, dass wir noch viel Raum für Verbesserungen hatten. Zu diesem Zeitpunkt haben wir beschlossen, unseren benutzerdefinierten UI-Boilerplate-Code auf die neueste Version von React mit Next.js zu aktualisieren, um Hooks besser zu nutzen und unnötiges erneutes Rendern von Komponenten zu vermeiden.
Aufgrund häufiger Aktualisierungen und vergleichsweise geringerer Zugriffszahlen im Vergleich zu den anderen Bereichen der Website haben wir begonnen, unsere Themenseiten zu Next.js zu migrieren. Außerdem haben wir PartyTown verwendet, um zusätzliche aufwendige Hauptthreads an Web Worker auszulagern, sowie Verfahren wie requestIdleCallBack zum Aufschieben nicht kritischer Aufgaben.
Wie hat die Verbesserung des INP der Economic Times geholfen?
Aktuelle TBT und INP beim Ursprung
Bei der Veröffentlichung dieses Posts betrug die TBT für unseren Ursprung 120 Millisekunden, nachdem wir mit unseren Optimierungsmaßnahmen begonnen hatten, 3.260 Millisekunden. Nach unserer Optimierung betrug der INP-Wert 257 Millisekunden, von über 1.000 Millisekunden.
INP-CrUX-Trend
Die Zugriffe auf Themenseiten machen einen erheblich kleineren Anteil der gesamten Zugriffe aus. Daher war es ein idealer Ort für Experimente. Die CrUX-Ergebnisse und die Geschäftsergebnisse waren sehr ermutigend und veranlassten uns, unsere Bemühungen auf die gesamte Website auszuweiten, um weitere Vorteile zu erzielen.
Akamai mPulse TBT Analysis
Wir verwenden Akamai mPulse als RUM-Lösung, die TBT im Feld misst. Wir haben einen konstanten Rückgang bei TBT festgestellt, was sich eindeutig auf die Ergebnisse unserer Bemühungen zur Reduzierung von INP widerspiegelt. Wie im folgenden Screenshot zu sehen ist, fielen die TBT-Werte schließlich von etwa 5 Sekunden auf etwa 200 Millisekunden.
Geschäftsergebnis
Insgesamt haben wir durch unsere Bemühungen, TBT um das 30-Fache zu reduzieren und zu Next.js zu wechseln, den INP fast um das Vierfache reduziert. Dies führte schließlich zu einem Rückgang der Absprungrate um 50% und einer Steigerung der Seitenaufrufe um 43% auf Themenseiten.
Fazit
Zusammenfassend lässt sich sagen, dass INP maßgeblich bei der Ermittlung von Problemen mit der Laufzeitleistung in Teilen der Economic Times-Website mitgewirkt hat. Sie gehört zu den effektivsten Messwerten, die sich positiv auf die Geschäftsergebnisse auswirken. Aufgrund der sehr erfreulichen Ergebnisse dieser Bemühungen sind wir motiviert, unsere Optimierungsmaßnahmen auf andere Bereiche unserer Website auszuweiten und von zusätzlichen Vorteilen zu profitieren.