Die zwei Familien von UI-Performance-Testing-Tools
Labor, synthetisch
Lädt eine Seite unter kontrollierten Bedingungen und bewertet sie.
Wiederholbar und vergleichbar. Misst eine saubere Umgebung mit sauberen Daten.
Feld, echte Nutzer
Sammelt Messwerte aus realen Sitzungen.
Ehrlich zur Realität. Meldet es erst, nachdem es jemandem bereits passiert ist.
Was dazwischen liegt
Labortools laufen gegen eine Testumgebung, also gegen einen kleinen Datenbestand. Feldtools sehen reale Datenmengen, melden sich aber erst, wenn ein echter Nutzer darunter gelitten hat. Eine Ansicht, die mit zehn Zeilen schnell und mit zweitausend unbenutzbar ist, besteht also den Labortest und taucht dann im Feld auf – die denkbar schlechteste Reihenfolge.
Diese Lücke zu schließen erfordert keine neue Tool-Kategorie. Es braucht einen vorbefüllten Account in der Größe eines großen Kunden und dieselben Abläufe, die vor dem Release dagegen ausgeführt werden.
Die Auswahl innerhalb der jeweiligen Familie
Labortools: Bevorzugen Sie solche, die die Interaktionslatenz messen, nicht nur den ersten Ladevorgang. Laden ist ein einmaliger Aufwand pro Sitzung, Interaktion passiert ständig.
Feldtools: Prüfen Sie, ob sich nach Account-Größe segmentieren lässt. Ein Durchschnitt über alle Kunden verdeckt genau die Kunden, die leiden.
Beide: Vergleichen Sie mit Ihrer eigenen Historie statt mit einem absoluten Score. Übernommene Schwellenwerte lassen sich selten von einem Produkt auf ein anderes übertragen.
Felddaten so segmentieren, dass sie etwas aussagen
Real-User-Monitoring ist die ehrlichere der beiden Familien – und lässt sich leicht wertlos machen, indem man auf die falsche Aggregation schaut.
Ein Durchschnitt über alle Nutzer vermischt einen Kunden mit fünfzig Datensätzen und einen mit fünfzigtausend, und der zweite ist das gesamte Signal. Genauso verhält es sich, wenn Sie Geräte vermischen, Regionen vermischen oder Ihre internen Nutzer mit Ihren Kunden vermischen. Die Gesamtzahl kann sich verbessern, während Ihre größten Accounts stetig schlechter werden – und genau dieses Fehlermuster kostet Vertragsverlängerungen.
Segmentieren Sie nach der Dimension, in der Ihr Produkt tatsächlich variiert; bei den meisten Business-Anwendungen ist das die Account-Größe und nicht Gerät oder Netzwerk. Kann das Tooling nicht so segmentieren, misst die Zahl, die es meldet, nicht das, worauf es Ihnen ankommt.
Die Voraussetzung, die niemand aufführt
Eine Ansicht, die sofort rendert, weil der Request still fehlgeschlagen ist, erzielt in einem Labortool einen hervorragenden Wert. Korrektheit ist das Fundament unter jeder Performance-Zahl, und sie zu prüfen ist günstiger als jedes der oben genannten Tools.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Dasselbe Setup finden Sie im TestSprite-Dashboard, falls Sie lokal nichts installieren möchten. Der restliche CLI-Funktionsumfang findet sich im CLI-Repository.
Wo welches Tool läuft
Labortools in der Pipeline, bei jedem Pull Request, im Vergleich zu Ihrer Baseline. Feld-Monitoring dauerhaft aktiv. Funktionale Verifizierung gegen einen realistisch dimensionierten Account, ebenfalls bei jeder Änderung, denn genau das ist die Lücke, die die beiden anderen offenlassen.
Der Auslöser zählt mehr als der Mechanismus. Koppeln Sie ihn an Ihr Deployment-Event, wird jede Änderung geprüft, ohne dass es jemand entscheiden muss; die GitHub App übernimmt das aus dem Dashboard heraus, und ein GitHub Actions Step übernimmt es direkt in Ihrem Workflow.
Wo TestSprite zwischen Labor und Feld einzuordnen ist
In der Lücke, die beide offenlassen: echte Abläufe gegen eine Umgebung mit realistischen Daten ausführen, und zwar vor dem Release. Die Abdeckung wird aus Ihrem Produkt generiert und läuft bei jeder Änderung, sodass eine Ansicht, die mit zehn Zeilen funktioniert und mit zweitausend bricht, über das Verhalten gefunden wird statt über ein Perzentil.
Zugleich liefert es die Voraussetzung, die keine der beiden Familien prüft. Eine Seite, die sofort rendert, weil der Fetch fehlgeschlagen ist, ist schnell und falsch, und ein Labor-Score sagt Ihnen das nicht.
Labortools messen weiterhin Lade- und Interaktionszeiten, Feld-Monitoring meldet weiterhin, was Nutzer erlebt haben. Der Gewinn hier: Der Fehler, der erst bei der Datenmenge Ihres größten Kunden auftritt, wird gefunden, bevor dieser Kunde ihn findet.
Gehört TestSprite in diese Kategorie?
Nein. Es verifiziert, dass Abläufe sich korrekt verhalten – die Voraussetzung dafür, dass eine Performance-Zahl überhaupt etwas bedeutet.
Brauchen wir Labor- und Feldtools gleichermaßen?
Ja. Das Labor gibt Ihnen ein wiederholbares Signal vor dem Release, das Feld sagt Ihnen, was tatsächlich passiert ist. Für sich genommen reicht keines von beidem.
Was ist mit synthetischem Monitoring?
Ein Labortool, das nach Zeitplan auf die Produktion gerichtet wird. Nützlich für die Verfügbarkeit, und es läuft nach wie vor gegen die Daten, die dieser Account eben hat.
Wie groß sollte ein vorbefüllter Testaccount sein?
So groß wie Ihr größter realer Kunde. Alles darunter bedeutet, dass Sie einen Fall testen, den es in der Produktion nicht gibt.
Sollten Performance-Scores Merges blockieren?
Eine große Regression gegenüber Ihrer eigenen Baseline: ja. Ein absoluter Score-Schwellenwert: meist nicht, denn er verfolgt den Benchmark statt Ihr Produkt.
Das Labor ist zu sauber, das Feld kommt zu spät.
UI-Performance-Testing-Tools sind entweder Labor oder Feld, und beide übersehen die Verschlechterung bei realen Datenmengen. Befüllen Sie einen Account in der Größe eines großen Kunden, führen Sie Abläufe vor dem Release dagegen aus und prüfen Sie zuerst die Korrektheit.