00:00:00GitHub hat soeben ein extrem leistungsstarkes Add-on für Storybook veröffentlicht, das die
00:00:05Art und Weise, wie wir die Performance von Komponenten testen, grundlegend verändert.
00:00:07Es enthält ein sehr detailliertes Performance-Panel voller wertvoller Einblicke, wie etwa
00:00:12Frame-Timing, Eingabereaktionszeit, Layoutstabilität, React-Profiling, Speicherdruck
00:00:18und vieles mehr.
00:00:19In diesem Video schauen wir uns genauer an, was dieses Add-on zu bieten hat.
00:00:23Es wird sehr spannend, also tauchen wir direkt ein.
00:00:31Eine kurze Frage, bevor wir anfangen.
00:00:32Wissen Sie, was "Shift-Left"-Performance-Tests sind?
00:00:35Es ist ein Entwicklungsparadigma, das vorschreibt, dass die Performance Ihrer App-Komponenten
00:00:40früher im Entwicklungsprozess getestet werden sollte und nicht erst im Nachhinein.
00:00:45Und dieses Tool wurde speziell entwickelt, um Entwicklern bei diesen frühen Entscheidungen zu helfen,
00:00:50indem es zeigt, wie sich Ihre Komponenten verhalten, bevor sie jemals in die Produktion gehen.
00:00:55Das Storybook-Performance-Panel bietet also einen hochpräzisen Blick darauf, wie Ihre Komponenten
00:01:00mit der Rendering-Engine des Browsers interagieren.
00:01:02Es verfolgt zum Beispiel das Frame-Timing, um Jitter zu identifizieren – diese winzigen Lücken
00:01:07zwischen den Frames, durch die sich Animationen ruckelig anfühlen.
00:01:10Es überwacht auch den Haupt-Thread auf DOM-Churn und Thrashing.
00:01:15DOM-Churn passiert, wenn Ihr Code unnötigerweise Elemente in einer engen Schleife erstellt,
00:01:20löscht oder aktualisiert, während Thrashing auftritt, wenn der Browser gezwungen ist, das Layout
00:01:25mehrfach in einem Frame neu zu berechnen, weil Stile direkt hintereinander gelesen und geschrieben werden.
00:01:30Und dieses Add-on passt sich an jedes Framework an, das Sie verwenden.
00:01:33Wenn Sie React nutzen, kann es Metriken wie Render-Kaskaden hervorheben – jene kleinen
00:01:38Zustandsänderungen, die versehentlich eine riesige Welle von Re-Rendern in der gesamten App auslösen.
00:01:44Es trackt auch die P95-Dauer, die das Worst-Case-Szenario für Ihre langsamsten Nutzer zeigt,
00:01:50anstatt nur einen Durchschnittswert zu liefern.
00:01:52Und falls Sie kein React verwenden: Der Universal-Modus funktioniert perfekt für Vue, Svelte oder
00:01:58Web Components.
00:01:59Für beste Ergebnisse wird empfohlen, dieses Add-on in Chrome oder Edge auszuführen.
00:02:04Es gibt auch ein Live-Playbook, in dem wir diese Metriken in Aktion sehen können.
00:02:08Im Beispiel mit der animierten Box können wir genau verfolgen, wie viele Inline-Stil-Mutationen
00:02:13während einer Animation stattfinden.
00:02:16In diesem Fall sieht alles gesund aus.
00:02:18Die Framerate und das Frame-Timing bleiben absolut stabil, was bedeutet, dass der Browser
00:02:23die Stil-Updates mühelos bewältigt.
00:02:25Das Beispiel mit der schweren Liste erzählt jedoch eine andere Geschichte.
00:02:29Beim Filtern dieser großen Liste sehen wir einige Warnsignale.
00:02:32Erstens springt der Cumulative Layout Shift auf einen sehr hohen Wert, was darauf hindeutet,
00:02:38dass Elemente beim Laden stark springen, was für den Nutzer irritierend ist.
00:02:43Wir sehen auch eine Spitze beim DOM-Churn, was bedeutet, dass der Browser Überstunden macht,
00:02:49um eine riesige Anzahl von Knoten gleichzeitig abzubauen und neu aufzubauen.
00:02:52Dies führt auch zu Frame-Drops, was die wahrgenommene Geschwindigkeit und Geschmeidigkeit
00:02:57der Benutzeroberfläche beeinträchtigt.
00:02:58Im Beispiel für Element-Timing wird jedes DOM-Element mit dem entsprechenden Attribut
00:03:04auf seine exakte Renderzeit gemessen.
00:03:06Das ist unglaublich nützlich, weil es Ihnen hilft, den genauen Moment zu identifizieren, in dem
00:03:11Ihr Hauptinhalt oder Call-to-Action sichtbar wird, was ein genaueres Bild der wahrgenommenen
00:03:17Performance liefert als generische Seitenlademetriken.
00:03:21Und im Beispiel für teures Rendering führt ein Klick auf den Re-Render-Button dazu,
00:03:26dass die P95-Dauer sprunghaft ansteigt.
00:03:29Das passiert, weil der Haupt-Thread von der schweren JavaScript-Ausführung blockiert wird,
00:03:34wodurch sich die UI sehr träge anfühlt.
00:03:36Wir sehen hier auch Frame-Jitter-Warnungen, die auf inkonsistentes Rendering hindeuten,
00:03:41bei dem die Zeit zwischen den Frames stark schwankt.
00:03:44Außerdem gibt es eine hohe Total Blocking Time (TBT).
00:03:47Die TBT ist ein wichtiges Warnsignal, da sie anzeigt, dass der Haupt-Thread so lange
00:03:52blockiert war, dass der Nutzer nicht mehr mit der Seite interagieren konnte, etwa durch
00:03:57Klicken eines Buttons oder Scrollen.
00:03:58Eine ähnliche Aufschlüsselung sehen wir im Beispiel zur Verschwendung durch Memoization.
00:04:03Hier zeigt die Demo, dass das unnötige Re-Rendering jedes einzelnen Elements zu massiven
00:04:08Verzögerungen führt.
00:04:09Im Gegensatz dazu zeigt das korrekt memoisierte Beispiel, wie viel Arbeit gespart wird,
00:04:15wenn wir unsere Komponenten optimieren.
00:04:16Durch das Überspringen redundanter Render-Vorgänge halten wir den Haupt-Thread frei,
00:04:21sodass wir butterweiche 60 Frames pro Sekunde erreichen.
00:04:25Im Beispiel zur Render-Kaskade sehen wir genau, was passiert, wenn man set state innerhalb
00:04:30von use layout effect verwendet.
00:04:31Jede einzelne Erhöhung löst eine Kaskade aus, da use layout effect synchron nach allen
00:04:37DOM-Mutationen ausgeführt wird, aber bevor der Browser die Chance zum Zeichnen hat.
00:04:42Durch das Auslösen des State-Updates zwingen Sie React, den Komponentenbaum erneut zu
00:04:47verarbeiten und den Browser, das Layout ein zweites Mal zu berechnen, noch bevor der Nutzer
00:04:52das erste Ergebnis sieht.
00:04:53Das ist schlecht, weil es die Arbeit für jeden einzelnen Frame effektiv verdoppelt und zu
00:04:58Render-Verzögerungen führt, die selbst einfache Interaktionen schwerfällig wirken lassen.
00:05:02Dann gibt es noch das Beispiel zum Style-Churn, das ebenfalls eine kritische Beobachtung zeigt.
00:05:07Was passiert, wenn wir die Inline-Styles von 600 verschiedenen Knoten gleichzeitig ändern?
00:05:13Wir sehen sofort diese Stall-Warnungen im Thrashing-Bereich, was darauf hindeutet, dass
00:05:18der Browser in eine Reflow-Schleife gezwungen wird.
00:05:21Er versucht, die Positionen von 600 Elementen gleichzeitig zu berechnen, während das JavaScript
00:05:26immer noch Änderungen vornimmt.
00:05:27Dies führt zu sehr ungesunden Werten für unsere Frame-Metriken, da der Haupt-Thread
00:05:33vollständig ausgelastet ist.
00:05:34Ich hoffe, all diese Beispiele zeigen Ihnen, wie Sie dieses Storybook-Add-on nutzen können,
00:05:38um Engpässe in einer viel präziseren Umgebung zu identifizieren.
00:05:41Sicher, man kann Tools wie Lighthouse verwenden, aber Lighthouse ist eher ein grober Pinsel.
00:05:46Es bietet nicht die chirurgische Präzision, um genau zu sehen, wie eine einzelne Komponente
00:05:51die Performance Ihrer App beeinflusst.
00:05:53Ich ermutige Sie wirklich, dieses Add-on herunterzuladen, es zu Storybook hinzuzufügen und
00:05:58einfach damit herumzuspielen.
00:05:59Es gibt so viele wertvolle Erkenntnisse zu gewinnen, sobald man das volle Bild davon sieht,
00:06:03wie Ihre Komponenten unter der Haube tatsächlich arbeiten.
00:06:06Da haben Sie es also, das ist das neue GitHub Storybook Performance Panel Add-on
00:06:10kurz zusammengefasst.
00:06:11Was halten Sie davon?
00:06:13Und wie messen Sie die Performance in Ihrer Anwendung?
00:06:16Lassen Sie es uns unten in den Kommentaren wissen.
00:06:18Leute, wenn euch diese Art von technischen Analysen gefällt, lasst es mich wissen, indem ihr
00:06:22auf den Like-Button unter dem Video klickt und vergesst nicht, unseren Kanal zu abonnieren.
00:06:28Das war Andres von Better Stack, und wir sehen uns in den nächsten Videos.