Die Suche nach einer Lösung für INP in der Economic Times

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.

Daya Ram Yadav
Daya Ram Yadav
Saurabh Rajpal
Saurabh Rajpal

Interaction to Next Paint (INP) ist ein Messwert, mit dem bewertet wird, wie gut eine Website auf Nutzereingaben reagiert. Eine gute Reaktionsfähigkeit bedeutet, dass eine Seite schnell auf Nutzerinteraktionen reagiert. Je niedriger der INP einer Seite ist, desto besser kann sie auf Nutzerinteraktionen reagieren.

Gute INP-Werte liegen bei maximal 200 Millisekunden, schlechte Werte über 500 Millisekunden und alles dazwischen muss verbessert werden.

Die unklare Anfänge

Als Google INP als experimentellen Messwert einführte, der sich zu einem der Core Web Vitals-Messwerte entwickeln könnte, nahm das Economic Times-Team die Herausforderung an, ihn zu korrigieren, bevor er zu einem solchen Messwert wird. Denn eine erstklassige Nutzererfahrung ist für unsere wichtigsten Geschäftswerte entscheidend.

Der INP war bisher einer der schwierigsten Messwerte. Anfangs war unklar, wie sich die Nutzerinteraktionen effektiv messen lassen. Erschwerend kam hinzu, dass es kaum Community-Support gab. Die meisten Anbieter von Real User Monitoring (RUM) unterstützten die Funktion noch nicht. Wir hatten jedoch RUM-Tools von Google wie den Chrome User Experience Report (CrUX), die web-vitals JavaScript-Bibliothek und andere unterstützende Tools, die uns ein Gefühl dafür gaben, wo wir standen, während wir den Weg vor uns 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 war bereits gut dokumentiert und wurde von der Community unterstützt. Obwohl wir die Mindestanforderungen für Core Web Vitals bereits erreicht hatten, schnitten wir im Bereich TBT nach mehr als 3 Sekunden nicht so gut ab, als wir anfingen.

Was ist TBT und welche Schritte haben wir unternommen, um es zu verbessern?

TBT ist ein Labormesswert, mit dem die Reaktionsfähigkeit einer Webseite auf Nutzereingaben während des Seitenaufbaus gemessen wird. Aufgaben, deren Ausführung mehr als 50 Millisekunden dauert, werden als lang angesehen. Die Zeit nach dem Grenzwert von 50 Millisekunden wird als Blockierungszeit 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 mehr als 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 ist ein kurzer Lab-Vergleich unserer TBT vor und nach der Verbesserung:

Ein zusammengesetztes Bild langer Aufgaben während des Starts, wie im Performance Panel der Chrome-Entwicklertools zu sehen, und ein Bericht mit Seitenmesswerten. Der Hauptthread ist während des Seitenaufbaus 3.260 Millisekunden lang blockiert.
Der Haupt-Thread während des Starts, bevor die TBT-Optimierung erfolgt. Die TBT beträgt 3.260 Millisekunden.
Ein zusammengesetztes Bild langer Aufgaben während des Starts, wie im Performance Panel der Chrome-Entwicklertools zu sehen, und ein Bericht mit Seitenmesswerten. Der Hauptthread ist während des Seitenaufbaus 120 Millisekunden lang blockiert.
Der Haupt-Thread während des Starts nach der Optimierung der TBT. Die TBT beträgt 120 Millisekunden.

Aufwand für Hauptthread minimieren

Der Haupt-Thread des Browsers verarbeitet alles vom Parsen von HTML über das Erstellen des DOM bis hin zum Parsen von CSS und Anwenden von Stilen sowie zum Auswerten und Ausführen von JavaScript. Der Hauptthread verarbeitet auch Nutzerinteraktionen, also Klicks, Tippen und Tastendrücke. Wenn der Haupt-Thread mit anderen Aufgaben beschäftigt ist, reagiert er möglicherweise nicht effizient auf Nutzereingaben und die Nutzerfreundlichkeit wird beeinträchtigt.

Das war die schwierigste Aufgabe für uns, da wir eigene Algorithmen zur Erkennung der Nutzeridentität für die Auslieferung von Anzeigen basierend auf dem Abostatus und Drittanbieter-Scripts 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. So wird sichergestellt, dass der Callback sofort nach Ablauf des Zeitlimits ausgeführt wird, wenn er nicht bereits aufgerufen wurde.

Scriptauswertungszeit minimieren

Außerdem haben wir Drittanbieterbibliotheken mithilfe von Ladbaren Komponenten verzögert 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 Tree Shaking erforderlich war, um beim Laden der Seite weniger Code zu übertragen und so die anfängliche Bundle-Größe der Anwendung zu reduzieren.

Screenshot des Abdeckungstools in den Chrome-Entwicklertools Hier zeigt das Tool nicht verwendete Teile von JavaScript- und CSS-Dateien beim Laden der Seite an.

DOM-Größe reduzieren

Laut Lighthouse führt eine große DOM-Größe zu einer höheren Arbeitsspeichernutzung, längeren Stilberechnungen und kostspieligen Layout-Neuberechnungen.

Ein Screenshot der Prüfung der DOM-Größe in Lighthouse. Die Anzahl der gemeldeten DOM-Elemente beträgt 2.706.

Wir haben die Anzahl der DOM-Knoten auf zwei Arten reduziert:

  • Zuerst haben wir unsere Menüpunkte auf Nutzeranfrage (bei Klick) gerendert. Die DOM-Größe wurde um etwa 1.200 Knoten reduziert.
  • Zweitens haben wir weniger wichtige Widgets mit Lazy Loading geladen.

Durch diese Maßnahmen konnten wir die TBT deutlich reduzieren und unsere INP entsprechend um fast 50 % senken:

Screenshot der INP-Prüfung in CrUX Der INP-Wert für die Seite beträgt 539 Millisekunden und überschreitet damit den „schlechten“ Grenzwert.

Zu diesem Zeitpunkt waren uns fast alle einfachen Maßnahmen zur weiteren Reduzierung von TBT (und indirekt auch INP) ausgegangen. Wir wussten aber, dass noch viel Spielraum für Verbesserungen bestand. Deshalb haben wir uns entschieden, unsere benutzerdefinierte UI-Boilerplate auf die neueste Version von React und Next.js umzustellen, um Hooks besser zu nutzen und unnötiges erneutes Rendern von Komponenten zu vermeiden.

Aufgrund häufigerer Aktualisierungen und vergleichsweise weniger Zugriffen als auf den anderen Bereichen der Website haben wir damit begonnen, unsere Themenseiten zu Next.js zu migrieren. Außerdem haben wir PartyTown verwendet, um zusätzliche, arbeitsintensive Hauptthread-Aufgaben an Webworker auszulagern, sowie Techniken wie requestIdleCallBack, um nicht kritische Aufgaben zu verschieben.

Wie hat die Verbesserung des INP der Economic Times geholfen?

Aktuelle TBT und INP am Ursprung

Zum Zeitpunkt der Veröffentlichung dieses Beitrags betrug die TBT für unseren Ursprung 120 Millisekunden, verglichen mit 3.260 Millisekunden zu Beginn unserer Optimierungsbemühungen. Ebenso sank der INP für unseren Ursprung nach unseren Optimierungsbemühungen von über 1.000 Millisekunden auf 257 Millisekunden.

Screenshot der INP-Prüfung in CrUX Der INP-Wert für die Seite beträgt 257 Millisekunden, was innerhalb des Grenzwerts für Verbesserungsbedarf liegt.

INP CrUX-Trend

Der Traffic auf Themenseiten macht einen deutlich geringeren Teil des gesamten Traffics 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.

Ein Screenshot von INP-Verteilungen, wie sie in CrUX über einen Zeitraum von vier Monaten dargestellt werden, beginnend im Juli 2022 und endend im Oktober 2022. Die Werte unter den Schwellenwerten „Schlecht“ und „Verbesserungswürdig“ sind etwas gesunken, während die Werte unter dem Schwellenwert „Gut“ gestiegen sind.

Akamai mPulse-TBT-Analyse

Wir verwenden Akamai mPulse als RUM-Lösung, mit der die TBT vor Ort gemessen wird. Wir haben einen kontinuierlichen Rückgang der TBT festgestellt, der eindeutig auf die Ergebnisse unserer Bemühungen zur Reduzierung der INP zurückzuführen ist. Wie im Screenshot unten zu sehen ist, sanken die TBT-Werte im Feld schließlich von etwa 5 Sekunden auf etwa 200 Millisekunden.

Ein Screenshot eines Diagramms in Akamai mPulse, das einen Rückgang der TBT im Laufe von etwa einem Monat zeigt.

Geschäftsergebnis

Insgesamt konnten wir durch unsere Bemühungen, die TBT um das 30-fache zu senken, und die Migration zu Next.js die INP fast um das Vierfache reduzieren. Dies führte schließlich zu einer Reduzierung der Absprungrate um 50 % und einer Steigerung der Seitenaufrufe um 43 % auf Themenseiten.

Screenshot, der zeigt, wie in Google Analytics Seitenaufrufe mit der Absprungrate verglichen werden Durch die Optimierungen von INP auf der Website der The Economic Times konnte die Absprungrate um 50% gesenkt und die Seitenaufrufe um 43% gesteigert werden.

Fazit

Zusammenfassend lässt sich sagen, dass INP maßgeblich an der Ermittlung von Problemen mit der Laufzeitleistung in Teilen der Economic Times-Website mitgewirkt hat. Er hat sich als einer der effektivsten Messwerte erwiesen, um positive Auswirkungen auf die Geschäftsergebnisse zu erzielen. Aufgrund der sehr ermutigenden Zahlen, die wir als Ergebnis dieser Bemühungen festgestellt haben, sind wir motiviert, unsere Optimierungsbemühungen auf andere Bereiche unserer Website auszuweiten und zusätzliche Vorteile zu erzielen.