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

Durch die Verringerung der TBT um das 30-fache und die Migration zu Next.js konnte The Economic Times die INP fast viermal reduzieren. Dies führte zu einer Senkung der Absprungrate um 50% und einer Steigerung der Seitenaufrufe um 43 %.

Daya Ram Yadav
Daya Ram Yadav
Saurabh Rajpal
Saurabh Rajpal

Interaction to Next Paint (INP) ist ein Messwert, mit dem die Reaktionsfähigkeit einer Website auf Nutzereingaben bewertet wird. 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 200 Millisekunden oder weniger, schlechte Werte bei mehr als 500 Millisekunden. Werte dazwischen müssen optimiert werden.

Die unklare Anfangsphase

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 Kerngeschäftswerte von entscheidender Bedeutung.

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. Zu Beginn lag unsere INP auf Ursprungsebene bei fast 1.000 Millisekunden.

Bei der Behebung von INP-Problemen im Feld haben wir festgestellt, dass einer der Lab-Messwerte, auf den man sich konzentrieren sollte, die Gesamte Blockierzeit (Total Blocking Time, TBT) sein könnte. TBT war bereits gut dokumentiert und wurde von der Community unterstützt. Obwohl wir die Grenzwerte für die Core Web Vitals bereits erfüllten, waren wir bei der TBT nicht so gut aufgestellt, da sie zu Beginn über 3 Sekunden betrug.

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.

Die TBT wird berechnet, indem die Blockierungszeit aller langen Aufgaben während des Seitenaufbaus addiert wird. Wenn während des Ladevorgangs beispielsweise zwei lange Aufgaben ausgeführt werden, wird die Blockierungszeit so ermittelt:

  • Aufgabe A dauert 80 Millisekunden (30 Millisekunden mehr als 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, desto besser. Außerdem correliert er gut mit dem 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 Bereich „Leistung“ 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 Bereich „Leistung“ 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.

Arbeit im Hauptthread minimieren

Der Haupt-Thread des Browsers verarbeitet alles vom Parsen von HTML, dem Erstellen des DOM, dem Parsen von CSS und dem Anwenden von Stilen bis hin zur Auswertung und Ausführung von JavaScript. Der Haupt-Thread 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.

Wir haben zuerst kleine Schritte unternommen, z. B. das Laden weniger kritischer Geschäfts-Assets herabgestuft. Zweitens haben wir requestIdleCallback für nicht kritische Aufgaben verwendet, was dazu beitragen kann, die 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 die Seite mit dem Abdeckungstool in den Chrome-Entwicklertools profiliert 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. Dadurch wurde die DOM-Größe 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 Die INP für die Seite beträgt 539 Millisekunden, was den Grenzwert für „schlecht“ überschreitet.

Zu diesem Zeitpunkt waren uns fast alle einfachen Maßnahmen zur weiteren Reduzierung der TBT (und indirekt auch der 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 der INP The 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. Der INP für unseren Ursprung betrug nach unseren Optimierungsbemühungen 257 Millisekunden, verglichen mit über 1.000 Millisekunden zuvor.

Screenshot der INP-Prüfung in CrUX Die INP für die Seite beträgt 257 Millisekunden, was unter dem Grenzwert für „Optimierung erforderlich“ liegt.

INP CrUX-Trend

Der Traffic auf Themenseiten macht einen deutlich geringeren Anteil am Gesamttraffic aus. Daher war es ein idealer Ort für Experimente. Die Ergebnisse der CrUX-Analyse und die Geschäftsergebnisse waren sehr ermutigend. Deshalb haben wir unsere Bemühungen auf die gesamte Website ausgeweitet, 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.

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

Fazit

Zusammenfassend hat INP maßgeblich dazu beigetragen, Laufzeitleistungsprobleme auf Teilen der Website der Economic Times zu ermitteln. 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.