Eine Fallstudie zu Änderungen, die GoDaddy implementiert hat, um die Websiteleistung für Millionen von Websites zu verbessern und dadurch gute PageSpeed Insights- und Core Web Vitals-Werte zu erzielen.
GoDaddy ist die weltweit größte Dienstleistungsplattform für Unternehmer. Wir haben es uns zur Aufgabe gemacht, unsere weltweite Community von über 20 Millionen Kunden – und auch Unternehmern auf der ganzen Welt – zu unterstützen, indem wir ihnen die Hilfe und die Tools an die Hand geben, die sie für ihr Onlinewachstum benötigen.
Im Jahr 2019 hat GoDaddy „Websites + Marketing“ eingeführt, um nutzerfreundliche Tools und Dienste bereitzustellen, die Geschäftsinhabern dabei helfen, ihre Ziele zu erreichen. „Websites + Marketing“ verbindet die Website-Erstellung mit Marketing- und E-Commerce-Tools und bietet erstklassige Anleitungen, um Kunden zum Erfolg bei neuen Unternehmen zu verhelfen.
Seit der Einführung von Websites und Marketing war die Leistung ein wichtiger Teil des Produkts und etwas, das kontinuierlich beobachtet und weiterentwickelt wurde. In diesem Artikel werfen wir einen Blick auf den Weg von GoDaddy vom Einsatz von Lab-Leistungstests bis zur Verwendung von echten Daten mit Core Web Vitals. Außerdem sehen wir uns die Reihe von Produktverbesserungen an, mit denen das Produkt verbessert wurde, um eine sehr hohe Erfolgsquote für die Websites unserer Kunden zu erzielen.
Leistung mit Lighthouse erfassen
Wir haben uns zur Leistungsmessung auf Lighthouse-Daten verlassen. 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 https://github.com/godaddy/lighthouse4u bereitstellt. So konnten wir uns einen guten Überblick über die allgemeine Leistung der Websites in einer Lab-Einstellung verschaffen.
Da die Millionen von Websites, die wir auf unserer Plattform hosten, eine große Bandbreite an Funktionen und Inhalten bieten, war es wichtig, die Leistungsdaten mit Metadaten zu jeder getesteten Website zu kombinieren (z. B. verwendete Vorlage, gerenderte Widget-Typen usw.). So konnten wir Schlussfolgerungen darüber ziehen, welche Websitefunktionen eine geringere Leistung aufwiesen, und gleichzeitig erkennen, wo wir nach Verbesserungen suchen sollten.
So konnten wir beispielsweise feststellen, dass sich das Pop-up-Dialogfeld negativ auf die Seitengeschwindigkeit auswirkte. Websites mit dieser Funktion erzielten 12 Punkte weniger als ohne. Nachdem wir den Code aktualisiert hatten, um das Laden von JavaScript zu verzögern, haben wir unsere Lighthouse-Punktzahl um 2 Punkte verbessert. Diese Erkenntnisse konnten wir auf andere Funktionen anwenden, z. B. das Cookie-Banner, das kurz nach dem Seitenaufbau gerendert wird.
Wir haben uns nicht nur problematische Websites basierend auf Funktionen angesehen, sondern auch eine Analyse unseres JavaScript-Bundles durchgeführt. Dabei haben wir festgestellt, dass ein großer Teil der Größe von externen Abhängigkeiten (immutable.js und draft.js) stammt. Wir haben die Paketgröße reduziert, indem wir die Nutzer in Lazy-Loading-Abhängigkeiten bei Bedarf umstrukturiert haben. Dadurch sank die gängige Größe des JavaScript-Bundles um mehr als 50% und stieg von über 200 KB auf etwa 90 KB an (minimiert). Durch die kleinere Bundle-Größe konnte der Browser externe Assets und wichtige Skripts früher während des anfänglichen Lebenszyklus der Website ausführen, was zu Verbesserungen bei Largest Contentful Paint (LCP) und First Input Delay (FID) führte.
Dank unserer kontinuierlichen Bemühungen ist die durchschnittliche Bewertung der Lighthouse-Punktzahl auf einer Kundenwebsite von 40 Punkten im November 2020 auf über 70 Punkte im Mai 2021 gestiegen. Allerdings haben nicht alle unsere Versuche funktioniert und wir waren manchmal überrascht, wenn die Ergebnisse in lokalen Testumgebungen nicht immer mit den Ergebnissen in der Praxis übereinstimmten. Die Ergebnisse des Labs waren wirklich hilfreich, doch jetzt war es an der Zeit, sich auf die realen Beobachtungen aus der Praxis zu konzentrieren.
Echte Nutzerdaten mit Core Web Vitals erfassen
Nachdem wir die web-vitals-Bibliothek zu den Websites unserer Kunden hinzugefügt hatten, konnten wir Daten auf tatsächlichen Geräten von echten Besuchern messen, bei denen Hardware, Netzwerkgeschwindigkeit und Nutzerinteraktionen (z. B. Scrollen oder Klicken) nicht im gleichen Normalbereich wie bei einer Lab-Umgebung mit Lighthouse liegen. Das war ein großer Schritt in die richtige Richtung, denn jetzt hatten wir Daten, die für die Erfahrungen unserer Website-Besucher repräsentativ waren.
Fokus auf das schwächste Glied: Cumulative Layout Shift (CLS)
Durch die Analyse neuer Daten erhielten wir eine neue Perspektive darauf, wie wir die Websitegeschwindigkeit verbessern konnten. Aufgrund unserer Bemühungen, den Lighthouse-Wert zu verbessern, lag der LCP-Wert im 75. Perzentil bei 860 ms und der FID-Wert unter demselben Grenzwert unter 10 ms. Daher erzielten wir eine hohe Erfolgsquote für diese Messwerte auf den Websites unserer Kunden: 78% und 98 %. Die Cumulative Layout Shift (CLS)-Werte sehen jedoch ziemlich anders aus als in Lighthouse. Unsere CLS lag beim 75. Perzentil bei 0,17 und lag über dem Grenzwert von 0,1, sodass die Erfolgsquote für alle unsere Websites bei nur 47% lag.
Aufgrund dieses Messwerts ist unsere Erfolgsquote insgesamt auf 40 % gesunken. Wir haben uns das ehrgeizige Ziel gesetzt, diese Zahl bis Ende August 2021 auf über 60% zu erhöhen. Dazu müssten wir uns auf CLS konzentrieren.
In Wirklichkeit interagieren Nutzer mit der Seite und scrollen an „Above the fold“-Content vorbei, was mit Core Web Vitals besser erfasst werden kann. Aufgrund der unterschiedlichen Interaktionen der Nutzer mit der Website während des Ladevorgangs weichen die CLS-Werte von den Labor- und Felddaten ab.
Der Weg zum Bestehen aller Core Web Vitals
Die Leistung zu verbessern erfordert Ausprobieren. Und nicht jeder Versuch funktioniert wie erwartet. Es gibt jedoch einige Verbesserungen, die uns geholfen haben, unsere Ziele zu erreichen.
Durch Platzreservierung für das Laden von Bildern hat sich der CLS-Wert erheblich verbessert, da sich der Inhalt unter den Bildern nicht verschieben lässt. Zur Behebung dieses Problems in Browsern verwendet, die die CSS-Eigenschaft aspect-ratio unterstützen. Für diejenigen, die dies nicht hatten, luden wir ein transparentes Platzhalterbild, das im Cache gespeichert war und nur ein paar Byte groß war. Dadurch wurde das Bild fast augenblicklich geladen.
Dank dieses allgemeinen Bildverhaltens konnten wir die endgültige Bildhöhe beim serverseitigen Rendering anhand der Breite des Darstellungsbereichs und des Bildseitenverhältnisses im Voraus berechnen. Dies führte zu HTML-Markup mit vertikalem Platz, der für das endgültige Bild reserviert war. Die Verbesserung war besonders auf Mobilgeräten erkennbar, da die Bilder in der gesamten Spanne der mobilen Darstellungsbereiche gerendert werden.
Bestimmte Komponenten auf den Websites unserer Kunden enthalten dynamische Inhalte (z. B. eine Liste externer Kundenrezensionen) und konnten nicht in reines CSS konvertiert werden, um die Leistungsvorteile des serverseitigen Renderings zu nutzen. Es ist schwierig, Layoutverschiebungen in diesen Bereichen zu verbessern, da der Inhalt (also die Höhe) variiert. In diesen Fällen wurde die Komponente in einen Container mit einem min-height verpackt, der anhand der Beobachtung der durchschnittlichen Höhe jeder einzelnen Komponente festgelegt wurde. Das min-height-Element wird entfernt, sobald die innere dynamische Komponente gerendert wurde. Diese Lösung ist zwar nicht perfekt, aber es ermöglicht uns, Layoutverschiebungen deutlich zu reduzieren.
Wir konzentrierten uns auf die Verbesserung der CLS-Werte und arbeiteten weiter am LCP. Auf vielen Websites tragen Bilder am meisten zum LCP bei. Für uns war dies ein offensichtlicher Bereich für Verbesserungen. Wir haben das Lazy Loading von Bildern mit IntersectionObserver verbessert, stellten jedoch fest, dass die Bildgrößen nicht für jeden Haltepunkt (Mobilgerät, Tablet, Computer, großer Desktop-Computer) optimal eingestellt waren. Daher haben wir unseren Code zur Bildgenerierung aktualisiert, um Bilder an Haltepunkt anzupassen und zu skalieren und die Auflösung dann wieder basierend auf der Pixeldichte zu skalieren. So wurde beispielsweise die Größe eines bestimmten großen Bildes von 192 KB auf 102 KB reduziert.
Um Websites auf Geräten mit schlechter Netzwerkverbindung schnell zu rendern, haben wir Code hinzugefügt, mit dem die Bildqualität je nach Verbindungsgeschwindigkeit dynamisch verringert wird. Dazu kann die Eigenschaft downlink verwendet werden, die von navigator.connection zurückgegeben wird. Wir wenden URL-basierte Suchparameter an, um die Bildqualität basierend auf diesen Netzwerkbedingungen über unsere Asset API zu verringern.
Eine Reihe von Bereichen unserer Kundenwebsites wird dynamisch geladen. Da wir wissen, welche Bereiche auf einer bestimmten Website gerendert werden, wenn sie veröffentlicht wird, haben wir den Ressourcenhinweis rel=preconnect verwendet, um die Verbindung und die erforderlichen Handshakes vorab zu initialisieren. Außerdem verwenden wir Hinweise auf Ressourcen, um Schriftarten und andere wichtige Ressourcen schnell zu laden.
Kunden fügen beim Erstellen ihrer Websites verschiedene Abschnitte hinzu, die möglicherweise Inline-Scripts enthalten, um verschiedene Funktionalitäten zu ermöglichen. Nicht immer ist optimal, wenn diese Skripts auf der gesamten HTML-Seite vorhanden sind. Wir haben beschlossen, diese Skripts zu externalisieren, damit der Browser Skriptinhalte asynchron laden und parsen kann. Neu externe Skripts können auch auf anderen Seiten geteilt werden. Dies ermöglichte zusätzliche Leistungssteigerungen in Form von Browser- und CDN-Caching. Wir haben wichtige Skripts inline gespeichert, damit der Browser sie schneller parsen und ausführen kann.
Ergebnisse
Der Fokus auf CLS hat sich ausgezahlt: Unsere Core Web Vitals-Erfolgsrate stieg von rund 40% auf fast 70 % – eine Verbesserung um 75 %.
Wenn Nutzer auf unsere Plattform zurückkehren, um Aktualisierungen vorzunehmen und ihre Websites neu zu veröffentlichen, profitieren sie von den neuesten Leistungsverbesserungen. Dadurch wächst die Anzahl der Websites, die Core Web Vitals bestehen, stetig weiter, wie im folgenden Diagramm dargestellt:
Ergebnisse
Ob Sie Bereiche für Leistungsverbesserungen ermitteln und den Fortschritt erfolgreich verfolgen können, hängt stark davon ab, welche Tools zur Messung eingesetzt werden. Lighthouse war zwar nützlich, um die „Above the fold“-Leistung in einer „Lab-Einstellung“ zu messen, aber sie erfasste nicht genau Leistungsprobleme, die nur durch Nutzerinteraktionen wie das Scrollen durch die Seite verursacht wurden.
Durch das Erfassen echter Core Web Vitals mit Metadaten konnten wir die Verbesserungen visualisieren, gezielt ausrichten und ihre Wirkung messen. Durch die Verbesserung der Core Web Vitals-Werte konnte das Team nicht leistungsfähige Muster, die in unserer Codebasis gefunden wurden, identifizieren und ersetzen. Manchmal zeigten vielversprechende Änderungen nicht annähernd die erwarteten Auswirkungen, andere Male war das Gegenteil der Fall. Es ist keine reine Welt da draußen, also musst du es weiter versuchen.