Eine Fallstudie zu einigen wichtigen Änderungen, die bei Wix eingeführt wurden, um die Ladeleistung von Millionen von Websites zu verbessern und den Weg für gute PageSpeed Insights- und Core Web Vitals-Werte zu ebnen.
Laut Daten von CrUX und HTTPArchive hat sich der Prozentsatz der Wix-Websites, die bei allen Core Web Vitals-Messwerten gute Werte im 75. Perzentil erreichen, dank der Nutzung von Branchenstandards, Cloud-Anbietern und CDN-Funktionen in Kombination mit einer umfassenden Umschreibung der Websitelaufzeit mehr als verdreifacht.
Wix hat eine leistungsorientierte Kultur eingeführt und weitere Verbesserungen werden für die Nutzer eingeführt. Da wir uns auf Leistungs-KPIs konzentrieren, erwarten wir, dass die Anzahl der Websites, die die Core Web Vitals-Grenzwerte überschreiten, zunehmen wird.
Überblick
Die Welt der Leistung ist schön komplex und hat viele Variablen und Feinheiten. Untersuchungen zeigen, dass sich die Geschwindigkeit der Website direkt auf die Conversion-Raten und den Umsatz von Unternehmen auswirkt. In den letzten Jahren hat die Branche immer mehr Wert auf Sichtbarkeit und Geschwindigkeit 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 Standorten zu unterstützen, von denen einige vor vielen Jahren erstellt wurden und seitdem nicht mehr aktualisiert wurden. Wir bieten verschiedene Tools und Artikel zur Unterstützung unserer Nutzer bei der Analyse und Verbesserung der Leistung ihrer Websites.
Wix ist eine verwaltete Umgebung und nicht alles ist in der Hand der Nutzer. Die gemeinsame Nutzung gemeinsamer Infrastrukturen stellt all diese Standorte vor viele Herausforderungen, eröffnet aber auch Möglichkeiten für wesentliche Verbesserungen, d.h. die Nutzung von Skaleneffekten.
In einer gemeinsamen Sprache sprechen
Eine der größten Schwierigkeiten in Bezug auf die Leistung besteht darin, eine gemeinsame Terminologie zu finden, mit der verschiedene Aspekte der Nutzererfahrung besprochen werden, wobei sowohl die technische als auch die wahrgenommene Leistung berücksichtigt werden. Durch die Nutzung einer klar definierten, gemeinsamen Sprache innerhalb des Unternehmens konnten wir die verschiedenen technischen Aspekte und Kompromisse leicht diskutieren und kategorisieren, unsere Leistungsberichte klarer darstellen und deutlich machen, auf welche Aspekte wir uns zuerst verbessern sollten.
Wir haben alle unsere Beobachtungen und internen Diskussionen um branchenübliche Messwerte wie Web Vitals angepasst, darunter:
Websitekomplexität und Leistungsbewertungen
Es ist ziemlich einfach, eine Website zu erstellen, die sofort geladen wird. Sie müssen nur HTML ganz einfach verwenden und über ein CDN bereitstellen.
Die Realität ist jedoch, dass Websites immer komplexer und ausgefeilter werden und eher wie Anwendungen als Dokumente funktionieren und Funktionen wie Blogs, E-Commerce-Lösungen, benutzerdefinierten Code usw. unterstützen.
Wix bietet eine sehr große Vielzahl von Vorlagen, mit denen seine Nutzer problemlos eine Website mit vielen Geschäftsfunktionen erstellen können. Diese zusätzlichen Funktionen verursachen oft einige Leistungskosten.
Der Weg
Am Anfang stand HTML
Jedes Mal, wenn eine Webseite geladen wird, beginnt sie immer mit einer ersten Anfrage an eine URL, um das HTML-Dokument abzurufen. Diese HTML-Antwort löst alle zusätzlichen Clientanfragen und die Browserlogik zum Ausführen und Rendern Ihrer Website aus. Dies ist der wichtigste Teil des Seitenaufbaus, da bis zum Eintreffen der Antwort nichts geschieht (als TTFB – Zeit bis zum ersten Byte).
In der Vergangenheit: clientseitiges Rendering (CSR)
Wenn Sie große Systeme betreiben, müssen Sie immer Kompromisse in Bezug auf Leistung, Zuverlässigkeit und Kosten berücksichtigen. Bis vor ein paar Jahren nutzte Wix clientseitiges Rendering (CSR), bei dem der eigentliche HTML-Inhalt über JavaScript auf Clientseite (d. h. im Browser) generiert wurde. Dadurch konnten wir eine große Anzahl von Websites unterstützen, ohne hohe Backend-Betriebskosten zu verursachen.
Mithilfe von CSR konnten wir ein gängiges HTML-Dokument verwenden, das im Wesentlichen leer war. Es wurde lediglich der Download des erforderlichen Codes und der Daten ausgelöst, mit denen dann der vollständige HTML-Code auf dem Clientgerät generiert wurde.
Derzeit: serverseitiges Rendering (SSR)
Vor einigen Jahren sind wir auf serverseitiges Rendering (SSR) umgestiegen, da dies sowohl für die SEO als auch für die Leistung von Vorteil war. Wir haben die Sichtbarkeit der ersten Seite verbessert und eine bessere Indexierung für Suchmaschinen sichergestellt, die JavaScript nicht vollständig unterstützen.
Dieser Ansatz verbesserte die Sichtbarkeit, insbesondere bei langsameren Geräten/Verbindungen, und ermöglichte weitere Leistungsoptimierungen. Außerdem wurde für jede Webseitenanfrage eine eindeutige HTML-Antwort generiert, die viel vom Optimum entfernt ist, insbesondere bei Websites mit vielen Aufrufen.
Jetzt neu: Caching an mehreren Standorten
Der HTML-Code für jede Website war zumeist statisch, hatte jedoch einige Einschränkungen:
- Sie ändert sich häufig. Jedes Mal, wenn ein Nutzer seine Website bearbeitet oder Änderungen an Websitedaten vornimmt, z. B. am Store-Inventar auf der Website.
- Sie enthielt bestimmte besucherspezifische Daten und Cookies, d. h. zwei Nutzer, die dieselbe Website besuchen, sehen unterschiedliche HTML-Elemente. Beispielsweise zur Unterstützung von Produktfunktionen wie die Erinnerung an die Artikel, die ein Besucher in den Einkaufswagen gelegt hat, oder den Chat, den der Besucher zuvor mit dem Unternehmen begonnen hat, und mehr.
- Nicht alle Seiten können im Cache gespeichert werden. Beispielsweise kann eine Seite mit benutzerdefiniertem Nutzercode, auf der die aktuelle Uhrzeit als Teil des Dokuments angezeigt wird, nicht im Cache gespeichert werden.
Anfangs haben wir den relativ sicheren Ansatz verwendet, den HTML-Code ohne Besucherdaten im Cache zu speichern. Dann haben wir nur bestimmte Teile der HTML-Antwort für jeden Besucher und jeden Cache-Treffer spontan geändert.
Interne CDN-Lösung
Dazu haben wir eine interne Lösung bereitgestellt: Den Varnish-HTTP-Cache für Proxy und Caching, Kafka für Entwertungsnachrichten und einen Scala/Netty-basierten Dienst, der diese HTML-Antworten weiterleitet, den HTML-Code ändert, der im Cache gespeicherten Antwort jedoch besucherspezifische Daten und Cookies hinzufügt.
Mit dieser Lösung konnten wir diese schlanken Komponenten an vielen weiteren geografischen Standorten und in mehreren Regionen von Cloud-Anbietern bereitstellen, die auf der ganzen Welt verteilt sind. 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 Caching infrage kommen. Die Bereitstellung von Websites an zusätzlichen Standorten reduzierte die Netzwerklatenz zwischen den Clients und den Servern, die die HTML-Antwort bereitstellen, da die Inhalte näher an den Besuchern der Website gebracht werden.
Außerdem haben wir damit begonnen, bestimmte schreibgeschützte API-Antworten im Cache zu speichern, indem wir dieselbe Lösung verwendet und den Cache bei jeder Änderung am Websiteinhalt entwertet haben. Beispielsweise wird die Liste der Blogposts auf der Website im Cache gespeichert und ungültig gemacht, wenn ein Beitrag veröffentlicht/geändert wird.
Komplexität verringern
Durch die Implementierung von Caching wurde die Leistung erheblich verbessert, hauptsächlich in der TTFB- und FCP-Phase. Außerdem verbesserte sich unsere Zuverlässigkeit, da die Inhalte von einem Ort in der Nähe des Endnutzers bereitgestellt wurden.
Die Notwendigkeit, den HTML-Code für jede Antwort zu ändern, führte jedoch zu unnötiger Komplexität, die, wenn sie entfernt wurde, die Möglichkeit für weitere Leistungsverbesserungen bot.
Browser-Caching (und Vorbereitungen für CDNs)
~ 13%
HTML-Anfragen, die direkt aus dem Browser-Cache verarbeitet werden, sparen viel Bandbreite und verkürzen die Ladezeiten bei wiederholten Aufrufen
Der nächste Schritt bestand darin, diese besucherspezifischen Daten vollständig aus dem HTML-Code zu entfernen und von einem separaten Endpunkt abzurufen, der zu diesem Zweck vom Client aufgerufen wurde, nachdem der HTML-Code empfangen wurde.
Wir haben diese Daten und Cookies sorgfältig auf einen neuen Endpunkt migriert, der bei jedem Seitenaufbau aufgerufen wird, aber ein schlankes JSON-Format zurückgibt, das nur für den Hydrationsprozess erforderlich ist, um eine vollständige Seiteninteraktivität zu erreichen.
Dadurch konnten wir das Browser-Caching des HTML-Codes aktivieren, was bedeutet, dass Browser die HTML-Antwort jetzt für wiederholte Besuche speichern und den Server nur aufrufen, um zu überprüfen, ob sich der Inhalt geändert hat. Dazu wird HTTP ETag verwendet, im Grunde eine Kennung, die einer bestimmten Version einer HTML-Ressource zugewiesen ist. Wenn der Inhalt immer noch der gleiche ist, wird die Antwort 304 Not Modified von unseren Servern ohne Text an den Client gesendet.
Außerdem ist unser HTML-Code durch diese Änderung nicht mehr besucherspezifisch und enthält keine Cookies. Sie können also praktisch überall im Cache gespeichert werden, sodass Sie CDN-Anbieter nutzen können, die an Hunderten von Standorten weltweit eine viel bessere geografische Präsenz haben.
DNS, SSL und HTTP/2
Mit aktiviertem Caching wurden die Wartezeiten verkürzt und andere wichtige Teile der Erstverbindung wurden größer. Durch die Optimierung unserer Netzwerkinfrastruktur und das Monitoring konnten wir unsere DNS-, Verbindungs- und SSL-Zeiten verbessern.
HTTP/2 wurde für alle Nutzerdomains aktiviert, wodurch sowohl die Anzahl der erforderlichen Verbindungen als auch der Aufwand für neue Verbindungen reduziert werden. Diese Änderung ließ sich relativ einfach bereitstellen und nutzte gleichzeitig die Vorteile von Leistung und Robustheit, die mit HTTP/2 einhergehen.
Brotli-Komprimierung (im Vergleich zu GZIP)
21–25 %
Reduzierung des Medianwerts für die Dateiübertragung
Traditionell wurden alle unsere Dateien mit der gzip-Komprimierung komprimiert, der am häufigsten verwendeten HTML-Komprimierungsoption im Web. Dieses Komprimierungsprotokoll wurde vor fast 30 Jahren implementiert.
Die neuere Brotli-Komprimierung führt Komprimierungsverbesserungen ohne Kompromisse ein und wird langsam immer beliebter, wie im jährlichen Kapitel zur Web Almanac-Komprimierung beschrieben. Es wird schon seit einiger Zeit von allen gängigen Browsern unterstützt.
Wir haben die Brotli-Unterstützung auf unseren nginx-Proxys an den Edge-Punkten für alle Clients aktiviert, die sie unterstützen.
Durch die Umstellung auf die Brotli-Komprimierung konnte der Medianwert für die Dateiübertragungsgröße um 21% bis 25% reduziert werden. Dies führte zu einer geringeren Bandbreitennutzung und kürzeren Ladezeiten.
Content Delivery Networks (CDNs)
Dynamische CDN-Auswahl
Bei Wix verwenden wir schon immer CDNs, um den gesamten JavaScript-Code und die JavaScript-Bilder auf Nutzerwebsites bereitzustellen.
Vor Kurzem haben wir eine Lösung unseres DNS-Anbieters integriert, um automatisch das leistungsstärkste CDN je nach Netzwerk und Ursprung des Clients auszuwählen. Auf diese Weise können wir die statischen Dateien vom besten Speicherort für jeden Besucher aus bereitstellen und Verfügbarkeitsprobleme auf einem bestimmten CDN vermeiden.
Demnächst... Von CDNs bereitgestellte Nutzerdomains
Der letzte Teil des Puzzles besteht darin, den letzten und wichtigsten Teil über ein CDN bereitzustellen: den HTML-Code der Nutzerdomain.
Wie oben beschrieben, haben wir eine eigene Lösung erstellt, um die websitespezifischen HTML- und API-Ergebnisse im Cache zu speichern und bereitzustellen. Die Wartung dieser Lösung in so vielen neuen Regionen verursacht auch Betriebskosten. Das Hinzufügen neuer Standorte ist ein Prozess, den wir verwalten und kontinuierlich optimieren müssen.
Wir arbeiten derzeit mit verschiedenen CDN-Anbietern zusammen, um die Bereitstellung der gesamten Wix-Website direkt über die CDN-Standorte zu unterstützen. So können wir die Verteilung unserer Server auf der ganzen Welt verbessern und so die Antwortzeiten weiter verbessern. Dies stellt eine Herausforderung dar, da wir eine große Anzahl von Domains bereitstellen, die eine SSL-Beendigung am Edge erfordern.
Durch die Einbindung in CDNs sind Wix-Websites näher als je zuvor zum Kunden und bieten weitere Verbesserungen beim Laden, einschließlich neuerer Technologien wie HTTP/3 ohne zusätzlichen Aufwand für uns.
Ein paar Worte zur Leistungsüberwachung
Wenn Sie eine Wix-Website betreiben, fragen Sie sich wahrscheinlich, wie sich dies auf die Leistungsergebnisse Ihrer Wix-Website auswirkt und wie wir im Vergleich zu anderen Website-Plattformen abschneiden.
Der größte Teil der oben genannten Arbeit wurde im vergangenen Jahr bereitgestellt, einige wird noch eingeführt.
„Web Almanac“ von HTTPArchive hat vor Kurzem die Ausgabe von 2020 veröffentlicht, die ein hervorragendes Kapitel zur CMS-Nutzererfahrung enthält. Beachten Sie, dass viele der in diesem Artikel beschriebenen Zahlen aus der Mitte des Jahres 2020 stammen.
Wir freuen uns auf den aktualisierten Bericht im Jahr 2021 und sehen uns aktiv die CrUX für unsere Websites sowie unsere internen Leistungsmesswerte an.
Wir sind bestrebt, die Ladezeiten kontinuierlich zu verbessern und unseren Nutzern eine Plattform zur Verfügung zu stellen, auf der sie Websites ganz nach ihren Vorstellungen erstellen können, ohne dabei die Leistung zu beeinträchtigen.
DebugBear hat vor Kurzem einen sehr interessanten Website Builder Performance Review veröffentlicht, in dem einige der oben genannten Bereiche behandelt werden. Außerdem wird die Leistung sehr einfacher Websites untersucht, die auf den einzelnen Plattformen erstellt wurden. Diese Website wurde vor fast zwei Jahren erstellt und seitdem nicht geändert. Sie wird aber ständig verbessert. Außerdem verbessert sich die Leistung der Website und die Leistung der Website, was sich in den letzten eineinhalb Jahren in ihren Daten beobachten lässt.
Fazit
Wir hoffen, dass unsere Erfahrung Sie inspirieren, in Ihrem Unternehmen eine leistungsorientierte Unternehmenskultur zu entwickeln, und dass die obigen Informationen für Ihre Plattform oder Website hilfreich sind.
Zusammenfassend lässt sich sagen:
- Wählen Sie eine Reihe von Messwerten aus, die Sie mit von der Branche empfohlenen Tools konsistent verfolgen können. Wir empfehlen Core Web Vitals.
- Nutzen Sie Browser-Caching und CDNs.
- Migrieren Sie zu HTTP/2 (oder HTTP/3, wenn möglich).
- Verwende die Brotli-Komprimierung.
Danke, dass Sie unsere Geschichte gelesen haben. Wir laden Sie ein, Fragen zu stellen, Ideen auf Twitter und GitHub zu teilen und sich auf Ihren Lieblingskanälen an den Gesprächen zur Webleistung zu beteiligen.