Skip to main content
Sie koennen verschiedene Performance-Analyse-Tools verwenden, um die Effizienz Ihrer Website zu bewerten. Lesen Sie die folgenden Richtlinien von Kameleoon, um basierend auf Ihren Ergebnissen notwendige Verbesserungen zu identifizieren und umzusetzen.

​
Pruefen, wann das Snippet laedt

Pruefen Sie das Timing des engine.js-Tags (frueher kameleoon.js genannt) nach dem Neuladen der Seite, wie im untenstehenden Screenshot gezeigt. Wenn die Metrik started at 1 Sekunde überschreitet, fuegen Sie das Kameleoon-Skript weiter oben im <head>-Tag ein und setzen Sie fetchpriority="high". Diese Aenderungen stellen sicher, dass das Kameleoon-Skript in weniger als 1 Sekunde laedt.
Beim ersten Laden der Seite dauert das Kameleoon-Skript laenger, in der Regel unter 60 Millisekunden, da der Browser es direkt vom CDN herunterlädt. Bei nachfolgenden Neuladevorgängen lädt der Browser das Skript aus dem Cache.
performance

​
Performance-Score ueber die Chrome-Erweiterung von Kameleoon pruefen

Fuehren Sie je nach dem in der Erweiterung angezeigten Performance-Score (siehe Screenshot unten) eine oder alle dieser Aktionen aus:
  • Stoppen Sie alle Experimente oder Personalisierungen, die seit mehr als 2 Monaten laufen, und uebertragen Sie den Code basierend auf dem Ergebnis des Experiments oder der Personalisierung in den Quellcode Ihrer Website.
  • Archivieren Sie alle Experimente oder Personalisierungen, die Sie gestoppt haben.
  • Entfernen Sie alle ungenutzten Ziele, einschliesslich ihres Codes, wenn es sich um benutzerdefinierte Ziele handelt.
  • Entfernen Sie alle ungenutzten Segmente.
  • Entfernen Sie alle ungenutzten benutzerdefinierten Daten.
  • Optimieren Sie das globale benutzerdefinierte Skript, um allen ungenutzten/veralteten Code zu entfernen.
Weitere Informationen finden Sie in diesem Artikel zur Hilfe mit der Kameleoon-Debug-Assistant-Erweiterung.
chrome

​
Performance mit PageSpeed Insights verfolgen

Die Registerkarte Performance in den Entwickler-Tools des Browsers hilft, die Leistung einer Webseite zu analysieren, indem wichtige Daten wie Seitenladezeiten, Speichernutzung und Ressourcenverbrauch aufgezeichnet und visualisiert werden. Sie liefert detaillierte Einblicke in Rendering-, Scripting- und Layout-Prozesse in Form von Zeitleisten und Flame Charts. Die Auswertung dieser Erkenntnisse kann helfen, Engpässe, langsam ladende Skripte und andere geschwindigkeitsbeeinflussende Faktoren zu identifizieren. Google PageSpeed Insights analysiert den Inhalt einer Webseite und bietet Leistungseinblicke sowie Verbesserungsvorschlaege. Es vergibt einen Score und Vorschlaege basierend auf den Core Web Vitals wie Ladezeit, Interaktivitaet und visueller Stabilitaet. Der Bericht zeigt seine Ergebnisse mit Metriken wie “FCP”, “LCP”, “INP” und “CLS” an.
tab
tab2

​
First Contentful Paint

First Contentful Paint (FCP) misst die Zeit zwischen dem Beginn des Seitenladens und dem Moment, in dem der Browser den Seiteninhalt auf dem Bildschirm anzeigt.
  • Moegliche Auswirkung: Anti-Flicker koennte den FCP beeinflussen, da es die Anzeige des ersten Elements auf der Seite verzoegert
  • Aktion: Entfernen Sie in den meisten Fällen den Anti-Flicker-Code und verwenden Sie stattdessen das asynchrone Tag ohne Anti-Flicker. Ohne Anti-Flicker können Besucher die ursprüngliche Seite sehen, bevor eine Variation erscheint, was die Genauigkeit Ihrer Ergebnisse verringern kann.

​
Largest Contentful Paint

Largest Contentful Paint (LCP) misst die wahrgenommene Ladegeschwindigkeit. Er markiert den Punkt in der Seitenladezeitleiste, an dem der Hauptinhalt der Seite wahrscheinlich geladen wurde.
  • Moegliche Auswirkung: Anti-Flicker koennte den LCP beeinflussen, da es die Anzeige des groessten Elements auf der Seite verzoegert
  • Aktion: Gleich wie beim FCP.

​
Interaction to Next Paint

Interaction to Next Paint (INP) misst die Reaktionsfaehigkeit der Seite. Streben Sie einen INP von weniger als 200 Millisekunden an, um eine positive Nutzererfahrung zu bieten.
  • Moegliche Auswirkung: Wenn Kameleoon frueh laedt, sollte es keine negativen Auswirkungen geben. Tests, die das Verhalten einer Interaktion aendern, koennten diese Metrik jedoch beeinflussen.
  • Aktion: Sie koennen die Kameleoon Chrome-Erweiterung oder den folgenden Code in der Konsole verwenden, um zu pruefen, welche Experimente / Personalisierungen auf der betreffenden Seite aktiv sind, um die moegliche Quelle der Auswirkung zu finden. Das folgende Beispiel-Code-Snippet zeigt, wie das erreicht werden kann:

​
Cumulative Layout Shift

Cumulative Layout Shift (CLS) misst die groesste Positionsaenderung eines Elements waehrend des Lebenszyklus der Seite. Beachten Sie, dass Layout-Verschiebungen nur auftreten, wenn vorhandene Elemente ihre Startposition aendern. Wenn ein neues Element zum DOM hinzugefuegt wird oder ein vorhandenes Element seine Groesse aendert, zaehlt dies nicht als Layout-Aenderung, solange die Aenderung keine Aenderung der Startposition anderer sichtbarer Elemente bewirkt.
  • Moegliche Auswirkung: Der Kameleoon-Tag hat keinen Einfluss auf diesen Index. Experimente / Personalisierungen koennen hingegen einen negativen Einfluss haben, wenn sie eine Aenderung der Startposition eines Elements verursachen.
  • Aktion: Gleich wie beim INP.

​
Speed Index (ContentSquare-Metrik)

Der Speed Index misst den Zeitpunkt, zu dem der Browser die Mehrheit der grafischen Elemente im initialen Viewport anzeigt.
  • Moegliche Auswirkung: Anti-Flicker koennte den Speed Index beeinflussen, da es die Anzeige der Elemente im initialen Viewport verzögern kann. Wenn Sie zudem Experimente/Personalisierungen ausfuehren, die Aenderungen am oberen Seitenbereich vornehmen, wird der Speed Index negativ beeinflusst (er steigt).
  • Aktionen: Gleich wie beim FCP und INP.

​
Eigenschaften des Kameleoon-Skripts auf einen Blick

  • Asynchrones Snippet: Kameleoon laedt sein Skript asynchron von einem zuverlaessigen CDN (Cloudflare), um ein nicht blockierendes erstes Seitenladen zu gewaehrleisten, und nutzt das Browser-Caching fuer schnellere nachfolgende Seitenladevorgaenge. Kameleoon haelt ein Service Level Agreement (SLA) von ueber 99,99 % ein.
Stellen Sie sicher, dass das Kameleoon-Skript mit dem async-Attribut auf Ihrer Website installiert ist. Siehe das folgende Snippet:
  • Geringe Skriptgroesse: Die mit TypeScript erstellte Anwendungsdatei von Kameleoon hat eine Groesse von nur 29 KB (mit Brotli komprimiert), was die Ladezeit beim ersten Seitenaufruf minimiert.
  • Praeprozessor-Ansatz: Das Kameleoon-Skript wird nur aus den Komponenten generiert, die fuer Ihre spezifische Einrichtung erforderlich sind, basierend auf den Funktionen und Optionen, die Sie verwenden.
  • Einzigartige Anti-Flicker-Engine: Die Engine von Kameleoon erfasst DOM-Ereignisse in Echtzeit und veraendert die Anzeige der an einer Experiment-Variation beteiligten Komponenten, bevor sie vollstaendig gerendert werden.
  • Reduzierte Netzwerkaufrufe: Kameleoon fasst mehrere Tracking-Ereignisse in einem einzigen Beacon-Aufruf zusammen, was die Gesamtzahl der erforderlichen Netzwerkaufrufe erheblich reduziert.
  • Einzelnes Skript-Laden: Im Gegensatz zu anderen Plattformen, die mehrere Dateien benoetigen, laedt Kameleoon ein einziges konsolidiertes Skript, was die Anzahl der HTTP-Anfragen reduziert.
  • Verzoegertes Laden von Experimenten: Kameleoon ermoeglicht es Ihnen, im Einzelfall auszuwaehlen, welche Experimente zum Zeitpunkt des ersten Seitenaufrufs in die Anwendungsdatei engine.js (frueher kameleoon.js genannt) aufgenommen werden sollen, und nicht essentielle Experimente nach dem ersten Laden zu verschieben.
  • Echtzeit-Update: Um haeufigere Updates zu ermoeglichen, ohne durch Browser-Caching behindert zu werden, aktualisiert die Funktion Live Update Experiments von Kameleoon jedes mit “LIVE-UPDATE” markierte Experiment innerhalb einer Minute.

​
Best Practices fuer langfristige Leistung

Neben der Leistungsanalyse sollten Sie die Best Practices von Kameleoon befolgen, um nachhaltige und skalierbare Experimente sicherzustellen:

​
FAQ

Nein. Das Skript von Kameleoon nutzt modernste Technologie, um asynchron ausgeführt zu werden (bei Verwendung des asynchronen Installations-Snippets), und bleibt 90 Minuten lang vollständig im Browser-Cache. Es blockiert das Laden der Seite niemals, selbst bei seltenen CDN-Störungen (99,99 % Verfügbarkeit). Im Durchschnitt lädt das Skript in weniger als 70 ms über eine 4G-Verbindung oder schnellere Netzwerkbedingungen.Kameleoon reduziert die Auswirkungen zusätzlich durch fortschrittliche Komprimierungsverfahren, die TypeScript und Brotli kombinieren, wodurch eine Basis-Skriptgröße von nur 28,4 KB entsteht.

​
CDN-Bereitstellung und Skalierbarkeit

Das Skript engine.js wird über das Cloudflare CDN bereitgestellt. Es skaliert deshalb automatisch, unabhängig vom Traffic Ihrer Website. Bei keinem Traffic-Niveau kommt es zu Lade- oder Verlangsamungsproblemen. Das globale Netzwerk von Cloudflare übernimmt die Auslieferung, sodass weder Spitzen noch dauerhaft hoher Traffic die Skriptleistung für Ihre Besucher beeinträchtigen.

​
Caching

Standardmäßig speichert der Browser engine.js 90 Minuten lang im Cache, was die Ladezeiten für wiederkehrende Besucher minimiert. Wenn Ihr Anwendungsfall eine kürzere Cache-Dauer erfordert, lässt sich diese auf Anfrage auf bis zu 1 Minute verkürzen. Kontaktieren Sie den Kameleoon-Support, um diese Einstellung für Ihr Konto anzupassen.

​
Wichtige Hinweise

Die Skriptgröße kann je nach Anzahl und Inhalt (CSS/JavaScript) Ihrer Experimente zunehmen.Verwenden Sie für Experimente oder Personalisierungskampagnen, die nicht sofort geladen werden müssen, den Tag „DELAYED“. Damit wird das Laden nicht essenzieller Experimente bis nach dem ersten Seitenaufruf verzögert. Kameleoon verwaltet diese Experimente intelligent: Die Konfiguration wird erst nach 10 Sekunden Inaktivität heruntergeladen oder wenn ein Besucher angesprochen und einer anderen Variation als der Kontrollvariante zugewiesen wird. So bleiben die Auswirkungen auf die Ladeleistung minimal, während priorisierte Experimente vollständig funktionieren.

​
Tracking-Anfragen und Ratenbegrenzungen

Kameleoon bündelt Tracking-Ereignisse in einer einzigen Anfrage, statt eine Anfrage pro Ereignis zu senden. Dadurch bleibt die Zahl der Netzwerkaufrufe gering. Informationen dazu, wie engine.js Ereignisse in die Warteschlange stellt und sendet, finden Sie unter Code-Ablauf: Tracking. Informationen dazu, wie SDKs Anfragen bündeln und wie die Data API Ratenbegrenzungen anwendet, finden Sie unter Ratenbegrenzungen.

​
Ratenbegrenzungen der Data API

Kameleoon wendet Ratenbegrenzungen auf die Data API an, um die Zuverlässigkeit des Dienstes zu schützen. Die Limits basieren auf Ihren vertraglich vereinbarten monatlich einzigartigen Besuchern (MUV) und der IP-Adresse des Anforderers. Wenn Sie diese Limits überschreiten, gibt die API HTTP 429 zurück.Diese Limits gelten für alle Anfragen, die die Data API erreichen, einschließlich der Tracking-Aufrufe, die engine.js automatisch sendet, und der gebündelten Tracking-Anfragen, die Feature Experimentation SDKs senden. In Umgebungen, in denen viele Besucher eine einzige IP-Adresse teilen (zum Beispiel in Büros oder Unternehmensnetzwerken), können IP-basierte Limits auch dann gelten, wenn Ihre gesamten MUV innerhalb des Vertrags bleiben.Kameleoon erkennt bekannten Bot-Traffic automatisch und schließt ihn von der Berechnung dieser Ratenbegrenzungen aus. Anfragen, die als von Bots stammend identifiziert werden, zählen nicht zu den oben beschriebenen Limits.Bei serverseitigen Integrationen können Sie IP-basierte Limits aufheben, indem Sie Ihre Anfragen authentifizieren. Wenn Ihr Anwendungsfall höhere Limits erfordert, wenden Sie sich an den Kameleoon-Support, um die Optionen zu besprechen.Ratenbegrenzungen gelten für Ihr gesamtes Kundenkonto, nicht für einzelne Projekte. Wenn ein Projekt übermäßig viele Anfragen erzeugt (beispielsweise weil eine fehlerhafte Implementierung eine Schleife erstellt, die Custom-Data-Events wiederholt sendet), verbraucht dieses Projekt das gemeinsame Konto-Limit und kann HTTP 429-Fehler in all Ihren anderen Projekten verursachen.Um das Projekt zu identifizieren, das unerwarteten Traffic erzeugt, verwenden Sie die Live events-Seite (Insights > Live events). Wählen Sie jedes Projekt nacheinander aus und vergleichen Sie die Ereignisanzahl der letzten Stunde oder 24 Stunden mit dem erwarteten Volumen. Ein Projekt, das deutlich mehr Ereignisse erzeugt, als sein Besuchervolumen rechtfertigt (beispielsweise mehrere Millionen Ereignisse bei einem Vertrag mit 100.000 MUV), ist wahrscheinlich die Ursache. Filtern Sie die Ereignisse nach Typ, um die Ursache einzugrenzen: Custom-Data-Events sind die häufigste Ursache, oft weil eine fehlerhafte Schleife dieselbe Custom-Data-Variable oder alle Custom-Data-Variablen bei jedem Seitenaufruf sendet.

​
Skalierbarkeit der Plattform

Die Plattform von Kameleoon nutzt horizontale Skalierung, Auto-Scaling-Infrastruktur, Lastverteilung sowie regelmäßige Last- und Stresstests. Weitere Details finden Sie unter Wie unterstützt die Plattform von Kameleoon Skalierbarkeit und Elastizität?.
Ja, Sie können nicht essenzielle Experimente bis nach dem ersten Seitenladevorgang verzögern. Um ein Experiment zu verzögern, fügen Sie den Tag DELAYED den Experimenten hinzu, die Sie aufschieben möchten. Weitere Informationen finden Sie in der Dokumentation zur Verwaltung von Tags.Kameleoon verwaltet als „DELAYED“ markierte Experimente intelligent. Die Konfiguration wird erst nach 10 Sekunden Inaktivität heruntergeladen oder wenn der Besucher angesprochen und einer anderen Variation als der Kontrollvariante zugewiesen wird. Sorgen Sie für das beste Nutzererlebnis, indem Sie ressourcenintensive Tests verschieben.
Die Plattform von Kameleoon bietet hohe Skalierbarkeit und Elastizität und gewährleistet optimale Leistung, wenn die Datenmengen wachsen. Die Plattform bewältigt eine durchschnittliche Last von 20.000 Abfragen pro Sekunde mit Spitzen von bis zu 100.000 Abfragen. Zu den Schlüsselfaktoren gehören:
  • Skalierbare Architektur: Eine verteilte und modulare Architektur ermöglicht horizontale Skalierung.
  • Auto-Scaling-Infrastruktur: Die cloudbasierte Infrastruktur skaliert Rechenressourcen automatisch.
  • Lastverteilung: Fortgeschrittene Techniken verteilen den Traffic gleichmäßig auf die Server.
  • Datenaufnahme und -verarbeitung: Robuste APIs und ein Data Broker verwalten große Datenmengen effizient.
  • Skalierbarkeitstests: Regelmäßige Last- und Stresstests stellen sicher, dass das System extreme Bedingungen bewältigt.
  • Elastische Datenspeicherung: Mehrstufiger Speicher ermöglicht schnellen Datenzugriff und langfristige Skalierbarkeit.