Trotz all seiner Vorteile bringt die Anwendung von JAMstack auf eCommerce-Websites mit großen Katalogen und häufigen Updates viele Herausforderungen mit sich. Wenn Sie eine E-Commerce-Website auf einer Backend-Plattform wie Salesforce Commerce Commerce Cloud, Magento oder SAP-Hybris betreiben, stehen Ihnen wahrscheinlich bereits einige davon zur Verfügung.
In diesem artikel werden die wichtigsten Herausforderungen beim Aufbau großer E-Commerce-JAMstack-Sites erläutert und wie Layer (jetzt Edgio) Ihnen bei der Lösung dieser Probleme helfen kann.
Die vollständige Version der Präsentation von Layer0 CTO Ishan Anand auf der JAMstack Conference 2020 finden Sie auf dem offiziellen YouTube-Kanal von Layer0.
Was ist Layer0 (jetzt Edgio)?
Layer0 bringt die Vorteile von JAMstack in eCommerce, indem es die Geschwindigkeit der Site beschleunigt und Entwicklungsabläufe vereinfacht. Durch Streaming zwischengespeicherter Daten vom Edge in den Browser, bevor sie angefordert werden, kann Edgio Websites 5 Sekunden vor dem Abtippen der Kunden halten. Sharper Image, REVOLVE und Shoe Carnival sind nur Beispiele für Websites, die die Layer0 JAMstack-Plattform nutzen, um die Entwicklerproduktivität zu steigern und ihre Websites in weniger als einer Sekunde bereitzustellen.
Welche Herausforderungen stellt sich bei der skalierten Verwendung von JAMstack für eCommerce dar?
Die Verwendung von JAMstack und Headless für eCommerce, insbesondere auf Websites mit großen Katalogen, häufigen Updates oder solchen auf monolithischen eCommerce-Plattformen, ist in der Regel mit den folgenden Herausforderungen verbunden:
- Lange Bauzeiten
- Häufige Updates
- Schwierige Site-Migrationen
- Dynamische Daten
- Personalisierung
- A/B-Prüfung
- Unvollständige APIs
- Data Pipeline-Architektur
- Durch APIs verlorene Anpassungen
- Grenzwerte für Datenbankverbindungen
- Teamfähigkeit
- CMS-Integration
- In CMS-Inhalte eingebettete Stile
- Integration von Backoffice-Workflows
Bauen Sie zeitliche Reibung und andere Herausforderungen im Maßstab auf
JAMstack verfügt über eine integrierte Skalierbarkeit mit hohem Datenverkehr. Der Build-Schritt führt jedoch eine neue Skalierungsbemaßung ein, da das typische statische Rendering während des Builds stattfindet. Wenn Sie Ihre Website erweitern oder häufiger Änderungen vornehmen, verlassen Sie den Sweet Spot, an dem JAMstack schnell und agil ist. Das Ergebnis ist Reibung während der Aufbauzeit. Es ist leicht, das Problem unter den Teppich zu kehren, wenn Sie auf einer kleinen Website arbeiten, aber das ist nicht der Fall bei einer typischen E-Commerce-Website.
Eine weitere wichtige Sache ist, dass Websites genauso von nicht-Entwicklern wie von Entwicklern erstellt werden. Da Inhalte, Marketing und Merchandising die Dinge ständig verändern, können Zeitreibungen schnell zu einem Problem für das gesamte Unternehmen werden.
All dies bedeutet, dass „at Scale“ mehr geschieht, als man denken würde, und das ist nicht auf den elektronischen Geschäftsverkehr beschränkt. Sehen Sie sich diesen Vergleich zwischen Einzelhändlern und News-Websites an. Bei E-Commerce-Websites ist die Anzahl der SKUs ein Proxy für die Anzahl der Seiten.
E-Commerce-Websites mit vielen Produkten (SKUs), Publisher mit vielen Artikeln
Verlage mit vielen Artikeln
Vielleicht denken Sie, dass nur Websites wie Amazon Millionen von SKUs haben, aber das stimmt nicht. Websites für Autoteile sind ein gutes Beispiel: Sie enthalten Millionen von Produkten, die auf den Suchkriterien für Jahr/Modell/Marke/Fahrzeug (YMMV) basieren. Beispielsweise verkauft TruPar.com ausschließlich Gabelstaplerteile mit 8M-SKUs.
Glücklicherweise helfen Ihnen einige statische und dynamische Rendering-Techniken bei der Lösung von JAMstack-Problemen.
„Statische“ Techniken
- Optimierung der Herstellungszeiten
- Client-seitiges Rendering
- Inkrementelle statische (Re-)Generierung
„Dynamische“ Techniken
- Serverloses serverseitiges Rendering + CDN
- Paralleles statisches Rendering
„Gemischte“ Wiedergabetechniken
- Auswahl der besten Rendering-Technik für jede Seitenklasse
- Auswahl eines Frameworks und einer Plattform, mit der Sie Techniken nach Bedarf kombinieren können
In den folgenden Abschnitten werden wir die Bedeutung dieser Techniken besprechen.
Statische Techniken
Optimierung der Herstellungszeiten
Es gibt mehrere Methoden zur Optimierung der Build-Zeiten für dynamische JavaScript-Seiten.
Inkrementelle Builds
Mit inkrementellen Builds können Sie Build-Artefakte speichern und nur die Änderungen neu generieren. Wenn nur eine einzelne Seite geändert wird, generieren Sie diese einzelne Seite neu.
Parallele Builds
Das Framework teilt den Build auf mehrere Prozesse oder Threads auf. Dies ist für die Bildverarbeitung hilfreich.
Alternative Stromaggregate am Standort
Nativ betriebene SSGs sind eine neue Methode und haben sich als bessere Herstellungszeiten erwiesen. Beispiele sind Hugo (GO) und Nift (C++). Viele nativ geschriebene statische Seitengeneratoren funktionieren jedoch nicht gut mit Javascript-schweren Websites. Relativ neuer Toast versucht, das anzugehen.
Der Vorbehalt besteht darin, dass die Unterstützung von Framework- und Cloud-Providern für parallele und inkrementelle Builds unterschiedlich ist. Nicht alle von ihnen unterstützen sie, und diejenigen, die nur begrenzte Unterstützung anbieten.
Potenzielle Mehrkosten für Seiten mit seltenen Besuchen
Es gibt auch die Frage der potenziellen Überschusskosten. Wenn Sie eine große Website mit Zehntausenden von SKUs oder mehr haben, folgt der Großteil Ihres Datenverkehrs einer Energieverteilung und Sie verbringen zusätzliche Rechenzeit damit, Seiten neu zu erstellen, die nie besucht werden. Je mehr Sie die Website aktualisieren, desto höher steigen die Kosten. Denken Sie daran, wenn Sie über einige dieser Techniken nachdenken.
Laut willit.build (eine Gatsby Build-Benchmark-Seite, die historische Build-Zeiten von Websites enthält, die auf Gatsby Cloud erstellt wurden) beträgt die Build-Zeit für Contentful- und WordPress-Sites etwa 200 ms pro Seite, was bedeutet, dass für eine Site mit 10.000 Seiten eine vollständige Site-Erstellung 25 Minuten dauern könnte. Inkrementelle Builds können Sie auf wenige Minuten reduzieren und die Leistung inkrementeller Builds anzeigen. Diese Technik kann hilfreich sein, wenn Sie keine vollständigen Builds durchführen.
Client-seitiges Rendering
Client-seitiges Rendering, auch bekannt als App-Shell oder SPA-Fallback-Modell, ist CDN-Routing. Wenn Ihre Site eine Million Produkte hostet, werden diese alle von dieser CDN-Schicht in die index.html weitergeleitet und werden zu einer statischen Datei mit einer App-Shell und wird clientseitig gerendert. Wenn der Browser diese Seite lädt, ruft der Client-Site-Router den Seiteninhalt im Browser ab und rendert ihn.
Mit Client-seitigem Rendering können Sie effektiv eine unendliche Anzahl von Seiten hosten, aber es gibt einige wichtige Überlegungen:
CSR kann sich negativ auf SEO auswirken
Der Vorbehalt beim Client-seitigen Rendering ist, dass es die Leistung beeinträchtigen kann, da die Seite erst rendern kann, wenn Javascript geladen wird. Ab Mai 2021 wird Google Websites basierend auf drei-Geschwindigkeiten-Metriken, CLS, LCP und FID, zusammengefasst als Core Web Vitals, klassifizieren. Clientseitiges Rendering kann sich negativ auf all diese Aspekte auswirken, insbesondere auf kumulative Layoutverschiebungen. Das ist nicht unmöglich, und es ist einfach schwierig, mit dem App-Shell-Modell ein gutes CLS zu erhalten. Dazu müssen Sie benutzerdefinierte Versionen der App Shell für jeden Seitentyp erstellen.
Clientseitig gerenderte Seiten können von (einigen) Bots nicht gelesen werden
Einige Bots können keine clientseitigen wiedergegebenen Inhalte lesen. Google behauptet, dass ihre Bots Javascript rendern und interpretieren können, aber wir wissen, dass die meisten anderen Bots dies nicht können, einschließlich der der meisten sozialen Plattformen, was für viele Websites eine wichtige Quelle für den Datenverkehr darstellt.
CSR erfordert Unterstützung für Rewrite- und Umleitungsregeln
Der dritte Vorbehalt bei der Implementierung von CSR besteht darin, dass Ihr CDN-Anbieter die Unterstützung für Rewrite- und Redirect-Regeln benötigt, und einige tun dies eleganter als andere. Sie müssen dies beispielsweise auf AWS CloudFront über die 404-Seiten-Unterstützung oder Lambda@Edge Handler verwenden.
Glücklicherweise bieten die führenden JAMstack-Plattformen Netlify, Vercel und Layer0 eine relativ einfache Möglichkeit, CSR zu aktivieren.
In Netlify gibt es eine Umleitungsdatei. Mit den 200 Modifikatoren ist es ein Umschreiben, aber es ist eine versteckte Umleitung, die der Benutzer nie sieht.
Vernetzen
Vercel bietet Unterstützung für Rewritings in vercel.json und lässt sich auch sehr eng in Next.js integrieren.
Vercel
Die CDN-AS-JavaScript-Befehlsshell in Layer0 bietet Next.js-Rewrite und unterstützt andere Frameworks.
Layer0 (Edgio)
Inkrementelle statische Generierung
Diese Technik wurde von Next.js als Pionier entwickelt und umfasste die Erstellung neuer statischer Seiten auf Abruf als Reaktion auf den eingehenden Datenverkehr. Der Browser fordert eine neue Seite an, die noch nicht besucht wurde, und für jede Seite gibt das CDN – unabhängig davon, welche Seite es ist – schnell eine universelle Fallback-Seite zurück, die nur Platzhalterdaten und keinen Inhalt enthält.
Während die Fallback-Seite angezeigt wird, wird der statische Erstellungsprozess der Seite im Hintergrund ausgeführt. Wenn dieser Build abgeschlossen ist, lädt die Fallback-Seite die statischen JSON-Daten und zeigt die letzte Seite an. Von da an erhalten zukünftige Besuche das statisch erstellte HTML.
Inkrementelle statische Regeneration
Es gibt eine Version der inkrementellen statischen Erzeugung, die als inkrementelle statische Regeneration bezeichnet wird, was im Wesentlichen der gleiche Prozess ist. Dennoch muss eine vorhandene statische Seite als Reaktion auf Datenverkehr aktualisiert werden. Wenn sich also die zugrunde liegenden Daten ändern, wird der Build-Prozess erneut ausgeführt, inspiriert von veralteter Revalidierung, einem beliebten, aber nicht allgemein geschätzten Cache-Protokoll. Dadurch wird eine veraltete Version der Seite anstelle des Fallbacks bereitgestellt, während die Seite neu erstellt wird, und diese wird dann gegen die neue Version ausgetauscht, sobald der Build-Prozess abgeschlossen ist.
Inkrementelle statische Regeneration:
- Aktualisiert vorhandene statische Seiten als Reaktion auf Datenverkehr,
- Dient als veraltete Version der Seite statt als Fallback.
Die inkrementelle statische Regenerierung hat geringe Auswirkungen auf SEO und Kompatibilität, insbesondere auf der ersten Seite. Die Fallback-Seite ist vollständig CSR und enthält keine Daten. Daher ist unklar, wie Bots darauf reagieren.
Dynamische Techniken
Zusätzlich zu statischen Techniken können E-Commerce-Websites auch von dynamischen Techniken profitieren, wie:
- Serverloses serverseitiges Rendering + CDN
- Paralleles statisches Rendering
Serverloses serverseitiges Rendering + CDN
Durch die Verwendung von SSR in Verbindung mit dem CDN können Sie als Reaktion auf Datenverkehr Seiten nach Bedarf erstellen, was Ihnen einige Vorteile bietet. Diese Technik ist auch besser mit der Art und Weise kompatibel, wie herkömmliche eCommerce-Plattformen hergestellt werden. Sie unterstützt viele Seiten – Sie können sie bei Bedarf dynamisch generieren – und gewährleistet eine hohe Kompatibilität mit älteren Plattformen.
Diese Technik ist jedoch auch ein wenig umstritten. Die JAMstack-Community ist tendenziell sehr dogmatisch, was JAMstack ist, und behauptet, dass JAMstack eine statische Generierung erfordert.
Serverloses serverseitiges Rendering ist effektiv JAMstack-artig, wenn zwei Bedingungen erfüllt sind:
- Keine DevOps und Server zu verwalten. Es ist serverlos, und Entwickler müssen keine Skalierbarkeit vornehmen. Es ist dasselbe serverlose System, das viele JAMstack-Plattformen für die Stromversorgung ihrer APIs verwenden, was besagt, dass Sie es für die Stromversorgung von HTML-Daten und über SSR verwenden können.
- HTML wird vom CDN bereitgestellt. Dies ist ein kritischer Zustand. Nach dem ersten fehlgeschlagenen Cache ist die CDN-servierte Site genauso schnell wie eine statisch generierte JAMstack Site. Beachten Sie, dass dies eine ordnungsgemäße Cacheverwaltung erfordert und für mehrseitige Sites schwieriger ist.
Paralleles statisches Rendering/SSR-Vorladen
Mit Layer0 können Sie die Gruppe von URLs angeben, die während des Deployments an der Edge vorgerendert und gecacht werden sollen, um sicherzustellen, dass Benutzer beim Zugriff auf Ihre Site eine Erfahrung in weniger als einer Sekunde erhalten.
Beim statischen Pre-Rendering werden Anforderungen an Ihren Anwendungscode gesendet und das Ergebnis direkt nach der Bereitstellung Ihrer Site zwischengespeichert. Auf diese Weise erstellen Sie einfach Ihre App, um serverseitiges Rendering zu implementieren und die Geschwindigkeitsvorteile einer statischen Website für einige oder alle Ihre Seiten zu nutzen. Diese Funktion ist besonders nützlich für große, komplexe Sites mit zu vielen URLs, die ohne außergewöhnlich lange Build-Zeiten erstellt werden können.
Das SSR-Vorladen ist eine weitere Technik, mit der Layer0 die Seitengeschwindigkeit beschleunigt. Sie ähnelt der regulären SSR-Pipeline, basiert jedoch auf der Analyse der Datenverkehrsprotokolle nach der Bereitstellung. Die Seiten mit hohem Datenverkehr werden parallel zur Bereitstellung vorgeladen. Wir lassen die Bereitstellung sofort und asynchron die Seiten mit hohem Datenverkehr erstellen. Auf diese Weise entkoppeln Sie das Deployment vom Build. So erhalten Sie sofortige Bereitstellungen und maximieren gleichzeitig die Cachetreffer.
Wenn eine Anforderung für eine Seite mit hohem Datenverkehr vorliegt, kommt es wahrscheinlich zu einem Cachetreffer. Dies ist der beste Weg, um die bestmöglichen Cache-Treffer in dieser Umgebung zu erhalten.
Paralleles statisches Rendering ermöglicht Folgendes:
- Analysieren Sie Protokolle für Seiten mit hohem Datenverkehr
- HTML für Seiten mit hohem Datenverkehr asynchron nach dem Deployment abrufen und speichern
- Sofortige Bereitstellung bei Maximierung der Cachetreffer
Statisches Vorbereiten
Gemischte Rendering-Techniken
Sie müssen nicht zwischen statischen und dynamischen Rendering-Techniken wählen. Sie können wählen, was für jede Seitenklasse auf Ihrer Website am besten geeignet ist. Sie können „über uns“, „Rückgaberichtlinien“ oder „Blogs statisch“ und andere Seiten wie Warenkorb, Produkt und Kategorien als dynamisch deklarieren. Wir empfehlen Ihnen, einen Plattformanbieter zu wählen, der es Ihnen ermöglicht, die Techniken nach Bedarf flexibel zu kombinieren, insbesondere wenn Sie dies in großem Umfang tun.
Wählen Sie die beste Rendering-Technik für jede Seitenklasse aus, z. B.: Deklarieren Sie einige Seiten statisch (z. B. Blog, über uns usw.) und andere Seiten dynamisch (z. B. Warenkorb, Produkte, Kategorien usw.)
Wählen Sie einen Framework- und Plattformanbieter, mit dem Sie Techniken nach Bedarf flexibel kombinieren können
JAMstack im Maßstab mit Layer0
Die heutigen CDN-Cache-Images, JavaScript und CSS, aber keine JSON- oder HTML-Dateien, und das ist es, was Ihre Seitenladezeiten hindert. Layer0 CDN-AS-JavaScript macht es möglich, diese Daten an der Peripherie selbst in einer dynamischen, serverlosen SSR-Umgebung zu zwischenspeichern.
JAMstack nimmt den Server aus der Gleichung heraus und ermöglicht es dem CDN, den Datenverkehr effektiv zu verwalten, was unabhängig von Datenverkehrsschwankungen problemlos möglich ist. Layer0 macht das Gleiche, aber anders. Anstatt beim Build zu rendern, rendern wir auf Anfrage, speichern aber jeden Build an der Edge, sodass nach einem Build kein Build mehr erforderlich ist.
Das Rendern jeder Seite beim Erstellen ist für kleinere Standorte in Ordnung, aber die Build-Zeit wird fast unerträglich, sobald Sie größer sind. Aufgrund der fehlenden Anpassung/Personalisierung oder der zu deren Bereitstellung erforderlichen Problemumgehungen ist der Fokus von JAMstack auf die Build-Zeit für große datenbankbasierte Websites wie eCommerce und Travel weniger relevant.
CDN-AS-JavaScript
Layer0 CDN-AS-JavaScript bietet Ihnen eine leistungsstarke Edge-Kontrolle über Cache-Schlüssel, Header, Cookies und vieles mehr und funktioniert auch mit Ihrem Code. Es versteht Ihren Code und das Routing Ihres Frameworks und kann lokal oder in Pre-Production-Umgebungen emuliert werden.
Edge-Regeln werden in Ihrem Code gespeichert, genau wie im klassischen JAMstack, und geben Ihnen vollständige Kontrolle über die Edge mit Live-Protokollen, Versionierung und Rollbacks mit einem Klick.
Im Layer0/Edgio Cookbook finden Sie detaillierte Beispiele für Routing-Muster in CDN-AS-JavaScript.
Leistungsmonitor
Um die Cache-Trefferraten zu maximieren, ist es wichtig, zuerst zu wissen, welche Raten diese Raten sind, aber diese Informationen sind in der Regel tief in den Zugriffsprotokollen Ihres CDN vergraben.
Layer0 verfügt über eine integrierte Leistungsüberwachung, die es einfacher macht, zu verstehen, wann Seiten-Cache zuschlägt und nicht zutrifft, und diese Informationen dem Entwickler auf sehr freundliche Weise zugänglich zu machen. Der Leistungsmonitor in Layer0 ermöglicht Ihnen Folgendes:
- Verstehen Sie den Datenverkehr anhand von Routen und nicht anhand von URLs, denn so denken Entwickler über ihre App. Darüber hinaus verfolgt es jede Bereitstellung, sodass Entwickler jede Regression erkennen können.
- Messen von Leistungsproblemen im gesamten Stack und in Lastszenarien (API, SSR, Edge usw.)
Layer0 hat auch ein Tool entwickelt, mit dem diagnostiziert werden kann, ob die Antwort vom Rand des Ursprungs stammt: Devtools. Devtools hilft Ihnen zu bestimmen, ob die Antwort von der Kante des Ursprungs stammt. Das folgende Beispiel zeigt, wie es auf einer App-Shell funktioniert, die mit React Storefront erstellt wurde, und zeigt an, wann eine Anforderung zutrifft. Die Antwort in diesem Beispiel erfolgt über das Layer0 (jetzt Edgio) Edge-Netzwerk.
Layer0-Devtools ermöglichen es Ihnen, zu diagnostizieren, ob Antworten vom Rand oder vom Ursprung stammen
Das Verständnis, ob eine Antwort von der Kante oder vom Ursprung kommt, ist für das Vorabholen bei Skalen von entscheidender Bedeutung, was auch Layer0 für Sie tut.
Vorabruf im Maßstab
Prefetching ist für die Leistung wichtig, da es sofortige Seitengeschwindigkeiten ermöglicht. Herkömmliche Seitengeschwindigkeitstests, wie sie mit Lighthouse getestet werden, konzentrieren sich darauf, was passiert, nachdem der Kunde klickt. Aber Sie können viel tun, bevor der Kunde auf die Daten tippt, und erhalten keine Latenz und nahezu unbegrenzte Bandbreite.
Layer0-Devtools ermöglichen es Ihnen, zu diagnostizieren, ob Antworten vom Rand oder vom Ursprung stammen
Websites auf Layer0 sind blitzschnell, da sie erweiterte Prefetching-Funktionen und Layer0 CDN-AS-JavaScript verwenden, wodurch sie 5 Sekunden vor dem Abtippen der Käufer bleiben. Dies geschieht, indem gecachte dynamische Daten vom Edge an die Browser der Benutzer gestreamt werden, bevor auf etwas geklickt wird – je nachdem, was sie als nächstes anklicken. Mit anderen Worten, Ihr Geschäft kann JSON-Daten für die verschiedenen Produkte, die Sie anbieten, deren Preise und Informationen in einem Bruchteil der Zeit bereitstellen.
Inkrementelle Migration
Layer0 bietet eine iterative (schrittweise, progressive) Migration, mit der Sie einen Abschnitt der App nach dem anderen iterativ migrieren können. Dabei folgt Martin Fowlers Strangler-Muster. Auf diese Weise werden bestimmte Funktionalitäten schrittweise „stranguliert“ und durch neue Anwendungen und Dienste ersetzt. Es ist, als würde man einen Berg Stein für Stein bewegen.
Inkrementelle Migration erfordert geroutete Kontrolle an der CDN-Kante oder am CDN-Ursprung. Hier ist ein Beispiel dafür, wie Sie dies auf Layer0 mithilfe von CDN-AS-JavaScript tun.
Personalisierung und Segmentierung
Eine schrittweise, schrittweise und progressive Migration ist für große Standorte wichtig. Aber es ist nicht nur auf Personalisierung beschränkt! Sie umfasst auch Sprache, Geografie usw. Und das ist sinnvoll, da große Websites in der Regel geografisch voneinander abweichen und in der Lage sein müssen, die Inhalte den Benutzern beim Besuch der Website anzupassen.
Die allgemeine Richtlinie lautet: Wenn sich dieser Inhalt unterhalb der Falzung befindet, empfehlen wir das späte Laden und das Rendering auf Clientseite. Wenn es sich um personalisierte Inhalte handelt, die über dem Falten liegen, möchten Sie sie in einer servergerendeten Ausgabe verwenden.
Über der Faltung personalisiert = Personalisierung zum Cache-Schlüssel hinzufügen
Auf Layer0 können Sie einen benutzerdefinierten Cacheschlüssel deklarieren und ihn beispielsweise basierend auf Währung oder Verhalten personalisieren. Sie können die Werbeaktionen und die Sortierreihenfolge auf den Kategorieseiten anpassen – je nachdem, ob jemand ein häufiger Besucher oder ein neuer Besucher ist – mit nur wenigen Zeilen in CDN-as-JavaScript.
A/B-Prüfung und Layer0
A/B-Tests und Personalisierung verleihen der Erstellung von JAMstack-Sites eine neue Komplexität. Tests sind sehr wichtig für große Standorte und große Unternehmen, wo Entscheidungen auf dem ROI basieren und nachweislich die Konversionsraten verbessern können.
Im herkömmlichen JAMstack stehen Ihnen jedoch nur clientseitige A/B-Tests zur Verfügung, die im Browser ausgeführt werden. Das Problem besteht darin, dass dies die Leistung beeinträchtigen und Ihre Tests auf zweierlei Weise zunichte machen kann. Es kann die Leistung Ihrer Varianten beeinträchtigen und jede Art von Verbesserung löschen. Und manchmal werden A/B-Tests wirksam, nachdem das Auge die getesteten Elemente bestanden hat. Möglicherweise befindet sich der A/B-Test in der Kopfzeile, und der Benutzer hat diesen Header bereits durchsucht, nachdem JavaScript ausgeführt und dieses Element geändert hat.
Die Probleme mit den clientseitigen A/B-Tests
- Normalerweise die einzige Option für statische Standorte
- Sie wird erst ausgeführt, wenn JavaScript ausgeführt wird
- Schlechte Leistung, die den Test möglicherweise zunichte macht
Layer0 Edge Experiments lösen diese Probleme, indem A/B-Tests an der Edge aktiviert werden. Auf dem XDN sind neue Erlebnisse immer nativ, gecacht und im Subsekundenbereich. Dies erstreckt sich über A/B-Tests hinaus auf jede Variante Ihrer Website.
Randexperimente
Layer0 verfügt außerdem über eine leistungsstarke Edge Experiments Engine. Das Modul ist Teil von CDN-AS-JavaScript und kennt alle Ihre Varianten, um sicherzustellen, dass jede Variante separat an der Edge zwischengespeichert wird. Dadurch haben Sie die Kontrolle darüber, welche Besucher welche Variante sehen.
Kantenexperimente ermöglichen Folgendes:
- Leiten Sie den Live-Datenverkehr an jede bereitgestellte Zweigstelle an der Netzwerkperipherie weiter
- A/B-Tests, kanarische Bereitstellungen oder Feature-Flags ausführen
- Schreiben Sie Routing-Regeln basierend auf Wahrscheinlichkeiten oder Header-Werten und sogar
- IP-Adressen
Mit Edge Experiments können Sie Tests ganz einfach aufteilen, ohne die Leistung Ihres Standorts zu beeinträchtigen. Splits werden an der Kante über eine benutzerfreundliche und dennoch leistungsstarke Schnittstelle ausgeführt. Edge-Experimente können für A/B- und multivariate Tests, canary-Bereitstellungen, blau-grüne Tests, iterative Migration von einer älteren Website, Personalisierung und vieles mehr verwendet werden.
Wie unsere Kunden von Layer0 profitieren
Layer0 bietet einen reibungslosen Übergang zu JAMstack und Headless und bietet einen großen Vorteil für Websites mit großen Katalogen, häufigen Updates oder für Websites mit älteren eCommerce-Plattformen. Shoe Carnival und Turnkey Vacation Rentals sind zwei Beispiele für Entwicklerteams auf großen Websites, die JAMstack und Headless für eCommerce auf Layer0 verwenden.
Schlüsselfertig
Turnkey Vacation Rentals ist eine Full-Service-Ferienwohnung-Management-Firma für Premium- und Luxuswohnungen in Top-Reisezielen im ganzen Land. Im Gegensatz zu Websites wie Airbnb bietet Turnkey nur vorab geprüfte Angebote an. Darüber hinaus werden Verwaltungsdetails zentral mithilfe standardisierter technischer Tools verarbeitet.
Ursprüngliche Einrichtung
Turnkey führte eine App in Docker auf AWS Elastic Beanstalk aus und suchte nach einer Lösung, die ihnen mehr Kontrolle und Einblicke in die Leistung bietet.
Sie haben einige JAMstack-Lösungen in Betracht gezogen, wollten aber eine Plattform, die Next.js nativ unterstützt, wie Layer0. Einer der entscheidenden Faktoren war, dass Layer0 eine Neuausrichtung der Codebasis und Datenpipeline vermeiden konnte.
Layer0 hat Turnkey mit einigen unten aufgeführten Funktionen zur Steigerung der Agilität beigetragen.
Umgebungen
In der Vergangenheit verwendete Turnkey eine kundenspezifische Pipeline, die in Jenkins gebaut wurde. Das Team wurde von einer Stammfiliale aus bereitgestellt, ohne dass es sich dabei um das Vertrauen in die Produktion kümmern konnte.
Mit Layer0 verfügen die Zweigstellen über individuelle Umgebungen, und das Team von Turnkey kann makellose Umgebungen einrichten. Sie werden erst dann in die Staging-Umgebung integriert, wenn sie wissen, dass etwas die QS bestanden hat. Dadurch entfällt die psychische Belastung, die mit der Qualitätssicherung verbunden ist.
Protokolle
Das Durchforsten von Serverprotokollen auf Beanstalk kann ein Albtraum sein: Sie müssen genau herausfinden, nach welchen Protokollen Sie suchen, auf welchem Server sie sich befinden, ob sie mit Lastausgleich ausgestattet sind usw. Mit Layer0 können Sie Protokolle direkt von Ihrem Build streamen, sodass Sie den Build finden, den Sie beheben möchten, auf Play drücken und das Protokoll ansehen können.
Inkrementelle Migration
Turnkey hatte Seiten, nicht auf React/Next.js, und lief auf der alten Architektur. Mit Layer0 konnten sie die bereits migrierten Daten auf den XDN übertragen und die Migration schrittweise fortsetzen.
Layer0 gab dem Team von Turnkey Tools die Möglichkeit, sich auf die Leistung zu konzentrieren.
Schuh Karneval
Shoe Carnival Inc. Ist ein US-amerikanischer Schuhhändler. Das Unternehmen betreibt derzeit einen Online-Shop neben 419 stationären Geschäften im mittleren westen, Süden und Südosten der USA.
Im Folgenden finden Sie einige der Funktionen von Layer0, die das Team von Shoe Carnival besonders nützlich fand.
Flexibilität
Shoe Carnival nutzt die Salesforce Commerce Cloud, die nicht dazu gedacht ist, kopflose Frontends wie die von Shoe Carnival zu betreiben. Auf der Backend-Seite gab es also viel Engineering und Verständnis, um die Daten an das Frontend zu übertragen. Diese Herausforderungen könnten aufgrund der Flexibilität gelöst werden, die das Layer0-Backend zwischen Salesforce und React Frontend bot. Das Team von Shoe Carnival konnte mit React frei aufbauen und die Einschränkungen von Salesforce ignorieren.
Es ist Zeit, die Produktion zu steigern
Die Produktionszeit des Shoe Carnivals stieg dramatisch an. Das Team kann von den Salesforce Entwicklungszyklen getrennt werden und sehr schnelle Änderungen bei der Bereitstellung vornehmen.
Standortgeschwindigkeit
Die Geschwindigkeit bis zur Produktion ist ein großer Vorteil, aber die Leistung der Website ist im Allgemeinen schwer zu ignorieren, da der Shoe Carnival von durchschnittlich 5-6 Sekunden auf weniger als Sekunden stieg. Sie können Inhalte auf sehr detaillierter Ebene zwischenspeichern und verfügen über die Tools, die sicherstellen, dass die Kunden, die sie suchen, immer verfügbar und auf dem neuesten Stand sind.
Inkrementelles Deployment
Durch die inkrementelle Bereitstellung kann das Team die Bereitstellung in der Produktion wesentlich schneller durchführen als eine vollständige Anwendung für die Bereitstellung.
Was die Auswirkungen der Migration auf Layer0 angeht, so haben die Headless-Kunden, als Shoe Carnival die Ursprungsseite gegen die Headless-Site für Conversions 50/50 auf CDN-Ebene testete, immer gewonnen, die Ursprungsseite übertroffen und Geschwindigkeit und Sichtbarkeit verbessert.
Zusammenfassung
Bei Layer0 sind wir der Meinung, dass JAMstack die Zukunft der Webentwicklung ist. Layer0 bringt die Vorteile von JAMstack für Front-End-Entwicklerteams auf großen, dynamischen E-Commerce-Websites, auf denen herkömmliche statische Techniken normalerweise nicht angewendet werden. Wir nennen es gern dynamischen JAMstack. Dadurch können SPA-Websites sofort geladen und leichter entwickelt werden.
Layer0 verfügt über ein anwendungsfähiges CDN-as-JavaScript, das Ihr aktuelles CDN erweitern oder sogar ersetzen kann und alle Web-Sicherheitsfunktionen an den Rand bringt, die Sie benötigen. Layer0 verfügt außerdem über eine Reihe entwicklungsorientierter Technologien, die den gesamten Prozess der Entwicklung, Bereitstellung, Vorschau, Experimentierung, Überwachung, und das einfache Ausführen Ihres Headless-Frontends, einschließlich automatisierter Vorschau-URLs mit vollem Stapel, einem serverlosen JavaScript-Backend für Frontend, erweiterter Cache-Überwachung und mehr.
Layer0 ist eine All-in-One-Entwicklungsplattform, mit der Sie:
- Verwenden Sie JAMstack für eCommerce sowohl vor als auch nach Just-in-Time-Rendering
- Ermöglichen Sie eine latenzfreie Netzwerkverbindung durch Vorabruf von Daten aus Ihren Produktkatalog-APIs
- Konfigurieren Sie Edge nativ in Ihrer App (CDN-AS-JavaScript)
- Kantenregeln lokal und im Vorfeld ausführen
- Erstellen Sie Vorschau-URLs aus GitHub, GitLab oder Bitbucket mit jedem neuen Zweig und Push
- Führen Sie Splits an der Peripherie für leistungsstarke A/B-Tests, kanarische Bereitstellungen und Personalisierung aus
- Serverloses JavaScript, das viel einfacher und zuverlässiger ist als AWS Lambda
