Eine Fallstudie zu einigen wichtigen Änderungen, die bei Wix eingeführt wurden, um die Ladeleistung von Websites für Millionen von Websites zu verbessern und so gute PageSpeed Insights- und Core Web Vitals-Bewertungen zu erhalten.
Durch die Nutzung von Branchenstandards, Cloud-Anbietern und CDN-Funktionen sowie eine umfassende Neufassung der Website-Laufzeit hat sich der Prozentsatz der Wix-Websites, die bei allen Core Web Vitals-Messwerten gute Werte im 75. Perzentil erreichen, laut Daten von CrUX und HTTPArchive mehr als verdreifacht.
Wix hat eine leistungsorientierte Unternehmenskultur eingeführt und wird weitere Verbesserungen für die Nutzer einführen. Da wir uns auf Leistungs-KPIs konzentrieren, gehen wir davon aus, dass die Anzahl der Websites, die die Core Web Vitals-Grenzwerte einhalten, steigen wird.
Übersicht
Die Welt der Leistung ist wunderschön komplex, mit vielen Variablen und Feinheiten. Studien zeigen, dass die Geschwindigkeit einer Website einen direkten Einfluss auf die Conversion-Raten und den Umsatz von Unternehmen hat. In den letzten Jahren hat die Branche mehr Wert auf die Sichtbarkeit der Leistung und die Beschleunigung des Webs gelegt. Ab Mai 2021 werden Signale für die Nutzerfreundlichkeit von Seiten in das Ranking der Google Suche aufgenommen.
Die besondere Herausforderung bei Wix besteht darin, Millionen von Websites zu unterstützen, von denen einige vor vielen Jahren erstellt wurden und seitdem nicht mehr aktualisiert wurden. Wir haben verschiedene Tools und Artikel, mit denen Nutzer die Leistung ihrer Websites analysieren und verbessern können.
Wix ist eine verwaltete Umgebung und nicht alles liegt in der Hand des Nutzers. Die gemeinsame Nutzung gemeinsamer Infrastrukturen stellt für alle diese Standorte viele Herausforderungen dar, bietet aber auch Chancen für umfassende Verbesserungen, d.h. die Nutzung von Skaleneffekten.
Eine gemeinsame Sprache sprechen
Eine der Hauptschwierigkeiten bei der Leistung besteht darin, eine gemeinsame Terminologie zu finden, um verschiedene Aspekte der Nutzererfahrung zu besprechen und dabei sowohl die technische als auch die wahrgenommene Leistung zu berücksichtigen. Durch eine klar definierte, gemeinsame Sprache innerhalb des Unternehmens konnten wir die verschiedenen technischen Teile und Kompromisse leicht besprechen und kategorisieren, unsere Leistungsberichte klären und uns ein besseres Bild davon machen, welche Aspekte wir zuerst verbessern sollten.
Wir haben alle unsere Monitoring- und internen Diskussionen so angepasst, dass Branchenstandardmesswerte wie Web Vitals berücksichtigt werden. Dazu gehören:
Bewertung der Komplexität und Leistung der Website
Es ist ziemlich einfach, eine Website zu erstellen, die sofort geladen wird, solange Sie sie sehr einfach gestalten, nur HTML verwenden und sie über ein CDN bereitstellen.
In Wirklichkeit werden Websites jedoch immer komplexer und ausgefeilter. Sie funktionieren eher wie Anwendungen als wie Dokumente und unterstützen Funktionen wie Blogs, E-Commerce-Lösungen und benutzerdefinierten Code.
Wix bietet eine sehr große Vielfalt an Vorlagen, mit denen Nutzer ganz einfach eine Website mit vielen Geschäftsfunktionen erstellen können. Diese zusätzlichen Funktionen gehen oft mit einigen Leistungseinbußen einher.
Die Reise
Am Anfang war HTML
Jedes Mal, wenn eine Webseite geladen wird, beginnt es mit einer ersten Anfrage an eine URL, um das HTML-Dokument abzurufen. Diese HTML-Antwort löst alle zusätzlichen Clientanfragen und Browserlogik aus, um Ihre Website auszuführen und zu rendern. Dies ist der wichtigste Teil des Seitenladevorgangs, da erst etwas passiert, wenn der Beginn der Antwort eintrifft (TTFB – Time to First Byte).
Früher: clientseitiges Rendering (CSR)
Beim Betrieb von Systemen im großen Maßstab müssen Sie immer Kompromisse eingehen, z. B. in Bezug auf Leistung, Zuverlässigkeit und Kosten. Bis vor einigen Jahren verwendete Wix das clientseitige Rendering (CSR), bei dem der eigentliche HTML-Inhalt über JavaScript auf der Clientseite (d. h. im Browser) generiert wurde. So konnten wir eine große Anzahl von Websites unterstützen, ohne hohe Backend-Betriebskosten zu verursachen.
Mit CSR konnten wir ein gängiges HTML-Dokument verwenden, das im Grunde leer war. Es wurde lediglich der Download des erforderlichen Codes und der Daten ausgelöst, mit denen dann die vollständige HTML-Seite auf dem Clientgerät generiert wurde.
Heute: serverseitiges Rendering (SSR)
Vor einigen Jahren haben wir auf das serverseitige Rendering (SSR) umgestellt, da dies sowohl für die Suchmaschinenoptimierung als auch für die Leistung von Vorteil war. So konnten wir die Zeit bis zur ersten Sichtbarkeit der Seite verkürzen und die Indexierung für Suchmaschinen verbessern, die JavaScript nicht vollständig unterstützen.
Dadurch wurde die Sichtbarkeit verbessert, insbesondere auf langsameren Geräten und Verbindungen, und es wurden weitere Leistungsoptimierungen möglich. Dies bedeutete jedoch auch, dass für jede Webseitenanfrage eine eindeutige HTML-Antwort generiert wurde, was bei vielen Aufrufen alles andere als optimal ist.
Caching an mehreren Standorten
Der HTML-Code für jede Website war größtenteils statisch, aber es gab einige Einschränkungen:
- Sie ändert sich häufig. Jedes Mal, wenn ein Nutzer seine Website bearbeitet oder Änderungen an den Websitedaten vornimmt, z. B. am Inventar des Onlineshops.
- Es gab bestimmte Daten und Cookies, die besucherspezifisch waren. Das bedeutet, dass zwei Nutzer, die dieselbe Website besuchen, etwas unterschiedliche HTML-Seiten sehen. So können beispielsweise Produktfunktionen unterstützt werden, z. B. das Speichern der Artikel, die ein Besucher in den Einkaufswagen gelegt hat, oder der Chat, den der Besucher zuvor mit dem Unternehmen gestartet hat.
- Nicht alle Seiten sind im Cache verfügbar. Eine Seite mit benutzerdefiniertem Code, auf der die aktuelle Uhrzeit als Teil des Dokuments angezeigt wird, kann beispielsweise nicht im Cache gespeichert werden.
Wir haben uns anfangs für den relativ sicheren Ansatz entschieden, die HTML-Seite ohne Besucherdaten im Cache zu speichern und dann nur bestimmte Teile der HTML-Antwort für jeden Besucher und jeden Cache-Treffer in Echtzeit zu ändern.
Interne CDN-Lösung
Dazu haben wir eine eigene Lösung bereitgestellt: Varnish HTTP-Cache für Proxying und Caching, Kafka für Invalidation-Nachrichten und einen Scala/Netty-basierten Dienst, der diese HTML-Antworten proxyt, aber das HTML mutiert und der gecachten Antwort besucherspezifische Daten und Cookies hinzufügt.
Mit dieser Lösung konnten wir diese schmalen Komponenten an vielen weiteren Standorten und in mehreren Regionen von Cloud-Anbietern auf der ganzen Welt bereitstellen. 2019 haben wir über 15 neue Regionen eingeführt und nach und nach das Caching für über 90% unserer Seitenaufrufe aktiviert, die für das Caching infrage kamen. Durch die Bereitstellung von Websites an zusätzlichen Standorten konnte die Netzwerklatenz zwischen den Clients und den Servern, die die HTML-Antwort senden, reduziert werden, da die Inhalte näher an den Besuchern der Website bereitgestellt wurden.
Außerdem haben wir damit begonnen, bestimmte schreibgeschützte API-Antworten zu cachen. Dabei wird der Cache bei jeder Änderung der Websiteinhalte ungültig gemacht. Beispielsweise wird die Liste der Blogbeiträge auf der Website im Cache gespeichert und ungültig, wenn ein Beitrag veröffentlicht oder geändert wird.
Komplexität reduzieren
Durch die Implementierung des Cachings konnte die Leistung erheblich verbessert werden, vor allem in den Phasen TTFB und FCP. Außerdem wurde die Zuverlässigkeit erhöht, da die Inhalte von einem Standort aus bereitgestellt wurden, der sich näher am Endnutzer befindet.
Die Notwendigkeit, das HTML für jede Antwort zu ändern, führte jedoch zu einer unnötigen Komplexität, die bei Beseitigung die Möglichkeit für weitere Leistungsverbesserungen bot.
Browser-Caching (und Vorbereitungen für CDNs)
ca. 13 %
HTML-Anfragen werden direkt aus dem Browsercache bereitgestellt, was viel Bandbreite spart und die Ladezeiten bei wiederholten Aufrufen reduziert
Im nächsten Schritt wurden diese besucherspezifischen Daten vollständig aus der HTML-Datei entfernt und nach dem Eintreffen der HTML-Datei über einen separaten Endpunkt abgerufen, der zu diesem Zweck vom Client aufgerufen wurde.
Wir haben diese Daten und Cookies sorgfältig zu einem neuen Endpunkt migriert, der bei jedem Seitenaufbau aufgerufen wird, aber eine schlanke JSON-Datei zurückgibt, die nur für den Hydratisierungsprozess erforderlich ist, um die vollständige Interaktivität der Seite zu erreichen.
So konnten wir das Browser-Caching der HTML-Datei aktivieren. Das bedeutet, dass Browser die HTML-Antwort jetzt für wiederholte Besuche speichern und den Server nur aufrufen, um zu prüfen, ob sich die Inhalte geändert haben. Dazu wird der HTTP-ETag verwendet, eine Kennung, die einer bestimmten Version einer HTML-Ressource zugewiesen ist. Wenn die Inhalte unverändert sind, wird vom Server eine Antwort vom Typ 304 Nicht geändert ohne Textkörper an den Client gesendet.
Außerdem bedeutet diese Änderung, dass unser HTML-Code nicht mehr Besucherspezifisch ist und keine Cookies enthält. Mit anderen Worten: Sie kann praktisch überall im Cache gespeichert werden. Das eröffnet die Möglichkeit, CDN-Anbieter zu verwenden, die an Hunderten von Standorten auf der ganzen Welt eine viel bessere geografische Präsenz haben.
DNS, SSL und HTTP/2
Durch das Aktivieren des Cachings wurden die Wartezeiten reduziert und andere wichtige Teile der ursprünglichen Verbindung wurden optimiert. Durch die Verbesserung unserer Netzwerkinfrastruktur und -überwachung konnten wir die DNS-, Verbindungs- und SSL-Zeiten verbessern.
HTTP/2 wurde für alle Nutzerdomains aktiviert, wodurch sowohl die Anzahl der erforderlichen Verbindungen als auch der Overhead bei jeder neuen Verbindung reduziert wurde. Diese Änderung war relativ einfach umzusetzen und wir konnten gleichzeitig die Vorteile in Bezug auf Leistung und Ausfallsicherheit von HTTP/2 nutzen.
Brotli-Komprimierung (im Vergleich zu gzip)
21–25 %
Verringerung der mittleren Dateiübertragungsgröße
Bisher wurden alle unsere Dateien mit der GZIP-Komprimierung komprimiert, der gängigsten HTML-Komprimierungsoption im Web. Dieses Komprimierungsprotokoll wurde vor fast 30 Jahren implementiert.
Die neuere Brotli-Komprimierung bietet Komprimierungsverbesserungen mit fast keinen Einschränkungen und wird langsam immer beliebter, wie im jährlichen Web Almanac im Kapitel zur Komprimierung beschrieben. Es wird schon seit einiger Zeit von allen gängigen Browsern unterstützt.
Wir haben die Brotli-Unterstützung für alle Clients, die sie unterstützen, auf unseren nginx-Proxys an den Edge-Standorten aktiviert.
Durch die Umstellung auf die Brotli-Komprimierung konnten wir die mittlere Dateiübertragungsgröße um 21 bis 25 % reduzieren. Das führte zu einer geringeren Bandbreitennutzung und kürzeren Ladezeiten.
Content Delivery Networks (CDNs)
Dynamische CDN-Auswahl
Bei Wix haben wir schon immer CDNs verwendet, um den gesamten JavaScript-Code und alle Bilder auf den Websites der Nutzer bereitzustellen.
Vor Kurzem haben wir eine Lösung unseres DNS-Anbieters integriert, um automatisch das leistungsstärkste CDN entsprechend dem Netzwerk und dem Ursprung des Kunden auszuwählen. So können wir die statischen Dateien vom für jeden Besucher besten Standort aus bereitstellen und Verfügbarkeitsprobleme bei einem bestimmten CDN vermeiden.
Demnächst: Nutzerdomains, die von CDNs bereitgestellt werden
Der letzte Teil des Puzzles besteht darin, den letzten und wichtigsten Teil über ein CDN bereitzustellen: die HTML-Datei aus der Nutzerdomain.
Wie oben beschrieben, haben wir eine eigene Lösung entwickelt, um die websitespezifischen HTML- und API-Ergebnisse im Cache zu speichern und bereitzustellen. Die Bereitstellung dieser Lösung in so vielen neuen Regionen hat auch Betriebskosten und das Hinzufügen neuer Standorte wird zu einem Prozess, den wir verwalten und kontinuierlich optimieren müssen.
Wir arbeiten derzeit mit verschiedenen CDN-Anbietern zusammen, um die gesamte Wix-Website direkt über CDN-Standorte bereitzustellen. So möchten wir die Verteilung unserer Server auf der ganzen Welt verbessern und die Antwortzeiten weiter verkürzen. Dies ist aufgrund der großen Anzahl von Domains, die wir hosten, eine Herausforderung, da für diese die SSL-Terminierung am Edge erforderlich ist.
Durch die Einbindung von CDNs sind Wix-Websites näher am Kunden als je zuvor. Außerdem werden das Laden und neuere Technologien wie HTTP/3 verbessert, ohne dass wir zusätzliche Arbeit haben.
Leistungsüberwachung
Wenn Sie eine Wix-Website haben, fragen Sie sich wahrscheinlich, wie sich das auf die Leistung Ihrer Wix-Website auswirkt und wie wir im Vergleich zu anderen Website-Plattformen abschneiden.
Die meisten der oben genannten Änderungen wurden im letzten Jahr eingeführt, einige werden noch eingeführt.
Der Web Almanac von HTTPArchive hat vor Kurzem die Ausgabe 2020 veröffentlicht, die ein hervorragendes Kapitel zur Nutzerfreundlichkeit von CMS enthält. Viele der in diesem Artikel beschriebenen Zahlen stammen aus der Mitte des Jahres 2020.
Wir freuen uns auf den aktualisierten Bericht 2021 und beobachten aktiv die CrUX für unsere Websites sowie unsere internen Leistungsmesswerte.
Wir arbeiten kontinuierlich daran, die Ladezeiten zu verbessern und unseren Nutzern eine Plattform zu bieten, auf der sie Websites nach ihren Vorstellungen erstellen können, ohne die Leistung zu beeinträchtigen.
DebugBear hat vor Kurzem eine sehr interessante Website Builder Performance Review veröffentlicht, in der einige der oben genannten Bereiche angesprochen und die Leistung sehr einfacher Websites untersucht wird, die auf den einzelnen Plattformen erstellt wurden. Diese Website wurde vor fast zwei Jahren erstellt und seitdem nicht mehr geändert. Die Plattform wird jedoch kontinuierlich verbessert und damit auch die Websiteleistung. Das können Sie anhand der Daten der letzten anderthalb Jahre sehen.
Fazit
Wir hoffen, dass Sie sich von unseren Erfahrungen inspirieren lassen, eine leistungsorientierte Kultur in Ihrem Unternehmen zu etablieren, und dass die oben genannten Details für Ihre Plattform oder Website hilfreich und anwendbar sind.
Zusammenfassend:
- Wählen Sie eine Reihe von Messwerten aus, die Sie mit branchenweit anerkannten Tools einheitlich erfassen können. Wir empfehlen Core Web Vitals.
- Nutze Browser-Caching und CDNs.
- Migrieren Sie zu HTTP/2 (oder nach Möglichkeit zu HTTP/3).
- Verwenden Sie die Brotli-Komprimierung.
Vielen Dank für Ihr Interesse an unserer Geschichte. Wir laden Sie ein, Fragen zu stellen und Ideen auf Twitter und GitHub zu teilen und sich auf Ihren bevorzugten Kanälen über die Webleistung auszutauschen.