Eine Fallstudie zu Änderungen, die GoDaddy implementiert hat, um die Websiteleistung für Millionen von Websites zu verbessern und ihnen zu guten PageSpeed Insights- und Core Web Vitals-Werten zu verhelfen.
GoDaddy ist die weltweit größte Dienstleistungsplattform für Unternehmer auf der ganzen Welt. Wir möchten unsere weltweite Community mit über 20 Millionen Kunden und Unternehmern dabei unterstützen, online erfolgreich zu sein. Dazu stellen wir ihnen alle nötigen Tools und Informationen zur Verfügung.
2019 hat GoDaddy Websites + Marketing eingeführt. Mit diesem Produkt möchten wir Nutzern nutzerfreundliche Tools und Dienstleistungen zur Verfügung stellen, mit denen sie ihre Geschäftsziele erreichen können. Websites + Marketing kombiniert Website-Erstellung mit Marketing- und E-Commerce-Tools und bietet erstklassige Anleitungen, damit Kunden mit ihren neuen Unternehmen erfolgreich sein können.
Seit der Einführung von „Websites & Marketing“ ist die Leistung ein wichtiger Bestandteil des Produkts, der aktiv überwacht und verbessert wird. In diesem Artikel sehen wir uns an, wie GoDaddy von der Verwendung von Leistungstests im Labor zur Verwendung von Realdaten mit Core Web Vitals übergegangen ist. Außerdem gehen wir auf die Reihe von Verbesserungen am Produkt ein, die zu einer sehr hohen Bestehensquote für die Websites unserer Kunden geführt haben.
Leistung mit Lighthouse erfassen
Für die Leistungsüberwachung haben wir Lighthouse-Daten verwendet. Jedes Mal, wenn eine Website auf der Plattform veröffentlicht wird, messen wir ihre Leistung mit unserem internen Tool „Lighthouse4u“, das Google Lighthouse als Dienst bereitstellt (https://github.com/godaddy/lighthouse4u). So konnten wir uns ein gutes Bild davon machen, wie Websites im Allgemeinen in einer Labumgebung abschneiden.
Da die Millionen von Websites, die wir auf unserer Plattform hosten, eine breite Palette von Funktionen und Inhalten haben, war es wichtig, Leistungsdaten mit Metadaten zu den einzelnen getesteten Websites zu kombinieren, z. B. zur verwendeten Vorlage oder zum Typ der gerenderten Widgets. So konnten wir Rückschlüsse darauf ziehen, welche Websitefunktionen eine geringere Leistung hatten, und gleichzeitig nachvollziehen, wo wir Verbesserungen vornehmen sollten.
So konnten wir beispielsweise feststellen, dass sich das Pop-up-Modal negativ auf die Seitengeschwindigkeit auswirkte. Websites mit dieser Funktion schnitten 12 Punkte schlechter ab als Websites ohne. Nachdem wir den Code aktualisiert hatten, um das Laden von JavaScript zu verschieben, konnten wir unseren Lighthouse-Wert um zwei Punkte verbessern. Diese Erkenntnisse konnten wir auf andere Funktionen anwenden, z. B. auf das Cookie-Banner, das kurz nach dem Laden der Seite angezeigt wird.
Neben der Prüfung problematischer Websites aufgrund von Funktionen haben wir auch unser JavaScript-Bundle analysiert und festgestellt, dass ein großer Teil seiner Größe auf externe Abhängigkeiten (immutable.js und draft.js) zurückzuführen ist. Wir haben die Größe des Bundles reduziert, indem wir die Verbraucher so umstrukturiert haben, dass Abhängigkeiten bei Bedarf verzögert geladen werden. Dies führte zu einer Reduzierung der Größe gängiger JavaScript-Bundles um über 50 %, von über 200 KB auf etwa 90 KB (minimiert). Durch die kleinere Bundle-Größe konnte der Browser externe Assets laden und wichtige Scripts früher im ursprünglichen Ladezyklus der Website ausführen. Dies führte zu Verbesserungen beim Largest Contentful Paint (LCP) und bei der First Input Delay (FID).
Dank unserer kontinuierlichen Bemühungen konnte der durchschnittliche Lighthouse-Wert der Kundenwebsites von etwa 40 Punkten im November 2020 auf über 70 Punkte im Mai 2021 gesteigert werden. Nicht alle unsere Versuche waren jedoch erfolgreich und wir waren manchmal überrascht, dass die Ergebnisse in lokalen Testumgebungen nicht immer mit den Ergebnissen übereinstimmten, die wir in der Praxis erhalten haben. Die Laborergebnisse waren sehr hilfreich, aber es war an der Zeit, sich auf die tatsächliche Nutzererfahrung im Feld zu konzentrieren.
Echte Nutzerdaten mit Core Web Vitals erfassen
Nachdem wir die web-vitals-Bibliothek auf die Websites unserer Kunden eingebunden hatten, konnten wir Daten auf tatsächlichen Geräten von echten Besuchern erfassen, bei denen Hardware, Netzwerkgeschwindigkeit und Nutzerinteraktionen (z. B. Scrollen oder Klicken) nicht auf einem einheitlichen Niveau wie in einer Laborumgebung mit Lighthouse sind. Das war ein großer Schritt in die richtige Richtung, da wir jetzt Daten hatten, die repräsentativ für die Erfahrungen unserer Websitebesucher waren.
Der schwächste Link: Cumulative Layout Shift (CLS)
Die Analyse neuer Daten hat uns eine neue Perspektive darauf gegeben, was getan werden musste, um die Websitegeschwindigkeit zu verbessern. Durch die Verbesserungen des Lighthouse-Werts betrug die LCP beim 75. Perzentil 860 ms und die FID bei demselben Grenzwert unter 10 ms. So konnten wir eine hohe Bestehensquote für diese Messwerte auf den Websites unserer Kunden erzielen: 78% bzw. 98 %. Die Werte für den Cumulative Layout Shift (CLS) sehen jedoch ziemlich anders aus als bei Lighthouse. Unser CLS beim 75.Perzentil betrug 0,17, was über dem Grenzwert von 0,1 für „bestanden“ liegt.Die Bestehensquote betrug daher nur 47% auf allen unseren Websites.
Dieser Messwert hat unsere Gesamtdurchfallquote auf 40 % gesenkt. Deshalb haben wir uns ein ehrgeiziges Ziel gesetzt, diese Zahl bis Ende August 2021 auf über 60% zu steigern. Dazu müssten wir uns auf den CLS konzentrieren.
In der Praxis interagieren Nutzer mit der Seite und scrollen an den Inhalten „above the fold“ vorbei. Das wird von Core Web Vitals besser erfasst. Aufgrund der unterschiedlichen Interaktionen der Nutzer mit der Website während des ersten Ladens unterschied sich der CLS von den Labor- und Felddaten.
So erreichen Sie alle Core Web Vitals
Die Leistungssteigerung erfordert viel Ausprobieren und nicht jeder Versuch funktioniert wie erwartet. Hier sind jedoch einige Verbesserungen, die uns dabei geholfen haben, unsere Ziele zu erreichen.
Durch das Reservieren von Speicherplatz für das Laden von Bildern konnte der CLS-Wert drastisch verbessert werden, da sich die Inhalte unter den Bildern nicht mehr verschieben. Wir haben die CSS-Eigenschaft aspect-ratio verwendet, um dieses Problem in Browsern zu beheben, die sie unterstützen. Bei Geräten ohne Cache haben wir ein transparentes Platzhalterbild geladen, das nur wenige Byte groß war und daher fast augenblicklich geladen wurde.
Durch dieses generische Bildverhalten konnten wir die endgültige Bildhöhe beim serverseitigen Rendering basierend auf der Breite des Darstellungsbereichs und dem Seitenverhältnis des Bildes vorab berechnen. Das Ergebnis war ein HTML-Markup mit vertikalem Abstand, der für das endgültige Bild reserviert war. Die Verbesserung war besonders auf Mobilgeräten zu beobachten, da Bilder auf der gesamten Breite mobiler Ansichten gerendert werden.
Bestimmte Komponenten auf den Websites unserer Kunden enthalten dynamische Inhalte (z. B. eine Liste externer Kundenrezensionen) und konnten nicht in reines CSS umgewandelt werden, um die Leistungsvorteile des serverseitigen Renderings zu nutzen. In diesen Bereichen lassen sich Layoutänderungen nur schwer verbessern, da sich die Inhalte (und damit die Höhe) unterscheiden. In diesen Fällen haben wir die Komponente in einen Container mit einer min-height gepackt, die anhand der durchschnittlichen Höhe der einzelnen Komponenten festgelegt wurde. Das min-height wird entfernt, sobald das Rendern der inneren dynamischen Komponente abgeschlossen ist. Diese Lösung war zwar nicht perfekt, aber sie ermöglichte es uns, die Layoutverschiebung erheblich zu reduzieren.
Während wir uns auf Verbesserungen bei der CLS konzentrierten, haben wir auch weiter an der LCP gearbeitet. Auf vielen Websites sind Bilder der größte Faktor für das LCP. Für uns war dies ein offensichtlicher Verbesserungsbedarf. Wir haben Verbesserungen am Lazy-Load-Bilder-Code mit IntersectionObserver vorgenommen, aber festgestellt, dass die Bildgrößen für die einzelnen Breakpoints (Smartphone, Tablet, Computer, großer Computer) nicht optimal festgelegt waren. Deshalb haben wir den Code zur Bildgenerierung aktualisiert, um Bilder pro Breakpoint zu begrenzen und zu skalieren und dann die Auflösung basierend auf der Pixeldichte zu skalieren. So wurde beispielsweise die Größe eines bestimmten großen Bildes von 192 KB auf 102 KB reduziert.
Damit Websites auf Geräten mit schlechter Netzwerkverbindung schnell gerendert werden können, haben wir Code hinzugefügt, mit dem die Bildqualität dynamisch anhand der Verbindungsgeschwindigkeit herunterskaliert wird. Dazu können Sie die Property downlink verwenden, die von navigator.connection zurückgegeben wird. Wir wenden URL-basierte Suchparameter an, um die Bildqualität über unsere Asset API basierend auf diesen Netzwerkbedingungen zu reduzieren.
Einige Bereiche unserer Kundenwebsites werden dynamisch geladen. Da wir wissen, welche Bereiche auf einer bestimmten Website nach der Veröffentlichung gerendert werden, haben wir den rel=preconnect Ressourcenhinweis verwendet, um die Verbindung und die erforderlichen Handshakes vorab zu initialisieren. Außerdem verwenden wir Ressourcenhinweise, um Schriftarten und andere wichtige Ressourcen schnell zu laden.
Beim Erstellen ihrer Websites fügen Kunden verschiedene Bereiche hinzu, die Inline-Scripts enthalten können, um verschiedene Funktionen zu ermöglichen. Die Einbettung dieser Scripts in die gesamte HTML-Seite ist nicht immer leistungsförderlich. Wir haben uns entschieden, diese Scripts zu externalisieren, damit der Browser Scriptinhalte asynchron laden und parsen kann. Neu externisierte Scripts können auch für mehrere Seiten freigegeben werden. Dies ermöglichte zusätzliche Leistungssteigerungen durch Browser- und CDN-Caching. Wir haben wichtige Scripts inline gelassen, damit der Browser sie schneller parsen und ausführen kann.
Ergebnisse
Die Konzentration auf CLS hat sich gelohnt: Die Bestehensquote für Core Web Vitals stieg von etwa 40% auf fast 70 % – eine Verbesserung um 75 %.
Wenn Nutzer unsere Plattform wieder aufrufen, um ihre Websites zu aktualisieren und neu zu veröffentlichen, erhalten sie die neuesten Leistungsverbesserungen. Daher steigt die Anzahl der Websites, die die Core Web Vitals bestehen, wie im folgenden Diagramm dargestellt, stetig an:
Ergebnisse
Die Bereiche für Leistungsverbesserungen und der Fortschritt sind stark von den Tools abhängig, die für die Messung verwendet werden. Lighthouse war zwar nützlich, um die Leistung im Above-the-Fold-Bereich in einer „Lab-Umgebung“ zu messen, erfasste aber nicht genau Leistungsprobleme, die nur durch Nutzerinteraktionen auftraten, z. B. durch Scrollen auf der Seite.
Durch das Erfassen der tatsächlichen Core Web Vitals mit Metadaten konnten wir die Auswirkungen unserer Verbesserungen visualisieren, steuern und messen. Bei der Verbesserung der Core Web Vitals-Werte konnte das Team in unserer Codebasis nicht leistungsstarke Muster identifizieren und ersetzen. Manchmal hatten vielversprechende Änderungen nicht annähernd die erwartete Wirkung, manchmal war das Gegenteil der Fall. Die Welt ist nicht perfekt, also müssen Sie weiter versuchen.