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

Durch die Reduzierung von TBT um das 30-Fache und die Migration zu Next.js konnte The Ecomonic Times den INP fast vervierfachen, was zu einer Verringerung 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. Gute Reaktionsfähigkeit bedeutet, dass eine Seite schnell auf Interaktionen von Nutzenden reagiert. Je niedriger der INP-Wert 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.

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 die INP effektiv gemessen werden kann. Erschwerend erwies sich jedoch der fehlende Community-Support – darunter auch die meisten RUM-Anbieter (Real User Monitoring), die diese Funktion noch nicht unterstützen. Es gab jedoch auch 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 wir die Mindestanforderungen für Core Web Vitals bereits erreicht hatten, schnitten wir im Bereich TBT nicht so gut ab, da es zu Beginn über 3 Sekunden dauerte.

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> Eine Zusammenstellung langer Aufgaben während des Starts, wie sie im Leistungssteuerfeld der Chrome-Entwicklertools angezeigt werden, und ein Bericht mit Seitenmesswerten. Der Hauptthread wird beim Seitenaufbau 3.260 Millisekunden lang blockiert. <ph type="x-smartling-placeholder">
</ph> Der Hauptthread während des Starts vor der Optimierung von TBT. Die TBT beträgt 3.260 Millisekunden.
<ph type="x-smartling-placeholder">
</ph> Eine Zusammenstellung langer Aufgaben während des Starts, wie sie im Leistungssteuerfeld der Chrome-Entwicklertools angezeigt werden, und ein Bericht mit Seitenmesswerten. Der Hauptthread wird beim Seitenaufbau 120 Millisekunden lang blockiert.
Der Hauptthread während des Starts nach der Optimierung von TBT. Die TBT beträgt 120 Millisekunden.

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.

Dauer der 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.

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

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.

Screenshot der DOM-Größenprüfung 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 Anfrage des Nutzers 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:

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

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.

Screenshot der INP-Prüfung in CrUX Der INP-Wert für die Seite beträgt 257 Millisekunden und liegt damit im Bereich „Optimierung erforderlich“. Schwellenwerten.

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.

Screenshot der INP-Verteilungen in CrUX über einen Zeitraum von vier Monaten, von Juli 2022 bis Oktober 2022 Werte innerhalb von &quot;schlecht&quot; und „verbesserungsbedürftig“ sanken, während die Werte in der Spalte Grenzwert erhöht.

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.

Screenshot eines Diagramms in Akamai mPulse, das einen Rückgang von TBT über einen Zeitraum von etwa einem Monat zeigt.

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.

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 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.