Durch die 30-malige Reduzierung von TBT und die Migration auf Next.js konnte The Ecomonic Times den INP fast vervierfachen, 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, der die Reaktionsfähigkeit einer Website auf Nutzereingaben bewertet. 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 erstmals als experimentellen Messwert einführte, der sich zu einem der Core Web Vitals-Messwerte entwickeln konnte, nahm sich das Economic Times-Team die Herausforderung, das Problem zu beheben, bevor es zu einem wird. Denn eine erstklassige Nutzererfahrung ist für unsere wichtigsten Geschäftswerte von entscheidender Bedeutung.
INP gehört bisher zu den am schwierigsten zu lösenden Messwerten. Anfangs war nicht klar, wie INP effektiv gemessen werden kann. Erschwerend wurde dies durch den Mangel an Community-Unterstützung, einschließlich der meisten RUM-Anbieter (Real User Monitoring), die diese Funktion noch nicht unterstützen. Wir hatten jedoch Google RUM-Tools wie den Chrome User Experience Report (CrUX), die web-vitals-JavaScript-Bibliothek und andere, die diese unterstützen. So konnten wir uns ein Bild davon machen, wo wir standen, während wir den künftigen Weg beurteilen. Unser INP lag zu Beginn bei fast 1.000 Millisekunden auf der Ursprungsebene.
Bei der Behebung von INP-Problemen im Feld wurde unter anderem die Total Blocking Time (TBT) als Ziel für das Lab-Messwert festgelegt. TBT wurde bereits gut dokumentiert und von der Community unterstützt. Obwohl wir die Grenzwerte für Core Web Vitals bereits erreicht haben, schnitten wir mit dem TBT-Front-End nicht so gut ab, da wir zu Beginn über drei Sekunden gebraucht haben.
Was ist TBT und welche Schritte haben wir unternommen, um es zu verbessern?
TBT ist ein Labormesswert, der die Reaktion 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-Schwellenwert wird als Blockierzeit bezeichnet.
Die TBT wird anhand der Summe der Blockierzeit aller langen Aufgaben während des Seitenaufbaus berechnet. Wenn zum Beispiel während des Ladevorgangs zwei lange Aufgaben stattfinden, wird die Blockierzeit wie folgt bestimmt:
- 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 das TBT, desto besser. TBT korreliert ebenfalls gut mit INP.
Hier ist ein kurzer Laborvergleich unseres TBT vor und nach den Maßnahmen zur Verbesserung:
Aufwand für Hauptthread minimieren
Der Hauptthread des Browsers übernimmt alles vom Parsen des HTML-Codes über das Erstellen des DOMs über das Parsen von CSS und das Anwenden von Stilen sowie das Auswerten und Ausführen von JavaScript. Der Hauptthread verarbeitet auch Nutzerinteraktionen, d. h. Klicken, Tippen und das Drücken von Tasten. Wenn der Hauptthread für andere Aufgaben beschäftigt ist, reagiert er möglicherweise nicht effizient auf Nutzereingaben, was zu Verzögerungen führen kann.
Das war für uns die schwierigste Aufgabe, da wir mithilfe unserer eigenen Algorithmen die Nutzeridentität für die Anzeigenbereitstellung basierend auf dem Abostatus und Drittanbieter-Scripts für A/B-Tests, Analysen und mehr erkennen.
Zuerst haben wir kleine Schritte unternommen, z. B. haben wir das Laden weniger wichtiger Unternehmens-Assets herabgestuft. Zweitens haben wir requestIdleCallback für nicht kritische Aufgaben verwendet, wodurch die TBT reduziert werden kann.
if ('requestIdleCallback' in window) {
this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}
Bei Verwendung von requestIdleCallback wird empfohlen, ein Zeitlimit anzugeben. Wenn die angegebene Zeit verstrichen ist und der Callback noch nicht aufgerufen wurde, wird der Callback sofort nach dem Zeitlimit ausgeführt.
Skriptauswertungszeit verkürzen
Außerdem haben wir Drittanbieterbibliotheken mit ladbaren Komponenten per Lazy Loading geladen. Außerdem haben wir nicht verwendetes JavaScript und nicht verwendetes CSS entfernt, indem wir in den Chrome-Entwicklertools mit dem Tool zur Abdeckung der Seite ein Profil erstellt haben. So konnten wir die Bereiche ermitteln, in denen Wackeln erforderlich war, um beim Seitenaufbau weniger Code zu senden, und so die anfängliche Bundle-Größe der Anwendung reduzieren.
DOM-Größe reduzieren
Pro Lighthouse führen große DOM-Größen zu erhöhter Arbeitsspeichernutzung, längeren Stil-Neuberechnungen und kostspieligen dynamischen Umbrüchen im Layout.
Wir haben die Anzahl der DOM-Knoten auf zwei Arten reduziert:
- Zunächst haben wir unsere Menüpunkte auf Anforderung des Nutzers (durch Klicken) gerendert. Die DOM-Größe verringerte sich um etwa 1.200 Knoten.
- Zweitens haben wir weniger wichtige Widgets als Lazy Loading geladen.
Dank all dieser Bemühungen haben wir die TBT deutlich reduziert und unseren INP entsprechend um fast 50 % gesenkt:
Zu diesem Zeitpunkt gab es fast keine einfachen Erfolge, um die TBT weiter zu reduzieren (und INP durch Proxy), aber wir wussten, dass wir noch viel Raum für Verbesserungen haben. An diesem Punkt haben wir beschlossen, unseren benutzerdefinierten UI-Boilerplate-Code zusammen mit Next.js auf die neueste Version von React zu aktualisieren, um Hooks besser zu nutzen und unnötiges Re-Rendering von Komponenten zu vermeiden.
Aufgrund häufigerer Aktualisierungen und im Vergleich zu den anderen Teilen der Website haben wir mit der Migration unserer Themenseiten zu Next.js begonnen. Außerdem haben wir PartyTown verwendet, um Web-Workern zusätzliche aufwendige Hauptthreads zu übertragen, sowie Techniken wie requestIdleCallBack zum Verschieben nicht kritischer Aufgaben.
Wie hat die Verbesserung des INP der Economic Times geholfen?
Aktuelle TBT und INP beim Ursprung
Zum Zeitpunkt der Veröffentlichung dieses Beitrags betrug die TBT für unseren Ursprung 120 Millisekunden, von 3.260 Millisekunden zu Beginn unserer Optimierungsmaßnahmen. Der INP für unseren Ursprung betrug nach unserer Optimierung 257 Millisekunden und sank von über 1.000 Millisekunden.
INP CrUX-Trend
Die Zugriffe auf Themenseiten machen einen deutlich kleineren Teil des gesamten Traffics aus. Daher war es ein idealer Ort für Experimente. Die Ergebnisse von CrUX und die Geschäftsergebnisse waren sehr ermutigend und haben uns dazu veranlasst, unsere Bemühungen auf die gesamte Website auszuweiten, um von weiteren Vorteilen zu profitieren.
Akamai mPulse-TBT-Analyse
Wir verwenden Akamai mPulse als RUM-Lösung, die die TBT vor Ort misst. Wir konnten einen beständigen Rückgang der TBT beobachten, was eindeutig den Ergebnissen unserer Bemühungen zur Senkung des INP entspricht. Wie im Screenshot unten zu sehen ist, sanken die TBT-Werte im Feld schließlich von etwa 5 Sekunden auf etwa 200 Millisekunden.
Geschäftsergebnis
Insgesamt konnten wir durch unsere Bemühungen, das TBT um das 30-Fache zu reduzieren, und die Umstellung auf Next.js haben uns geholfen, den INP fast um das Vierfache zu reduzieren, was letztendlich zu einer Steigerung der Absprungrate um 50% und einer Steigerung der Seitenaufrufe um 43% auf Themenseiten führte.
Fazit
Zusammenfassend lässt sich sagen, dass INP maßgeblich dazu beigetragen hat, Probleme mit der Laufzeitleistung in Teilen der Website der Economic Times zu ermitteln. Dies hat sich als eine der effektivsten Metriken erwiesen, die sich positiv auf die Geschäftsergebnisse auswirken. Aufgrund der sehr ermutigenden Zahlen, die wir mithilfe dieser Bemühungen festgestellt haben, sind wir motiviert, unsere Optimierungsmaßnahmen auf andere Bereiche unserer Website auszuweiten und zusätzliche Vorteile zu erzielen.