Den Odell, zuletzt Frontend-Entwickler bei Canva, hat zehn verbreitete Designsysteme an einer Länderauswahl und an 100 Checkboxen gemessen. Ionics Auswahlliste brauchte 1.266 Millisekunden zum Öffnen, Fluent kam mit 61 aus. Nur das Team hinter einer der zehn Bibliotheken lässt bei jeder Codeänderung automatisch einen Performance-Test laufen.
Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügenStellen Sie sich vor, ein Kunde öffnet im Bestellformular die Länderauswahl und die Seite reagiert über eine Sekunde lang auf keinen Klick. Genau das maß Odell bei Ionic mit allen 249 Ländern der ISO-Liste. Sein Beitrag vom 27. Oktober fordert, Designsysteme beim Tempo so streng zu prüfen wie bei der Barrierefreiheit.[1]
Das Wichtigste in Kürze
- Odell testete zehn quelloffene Designsysteme, darunter Ionic, Material UI, Carbon von IBM und UI5 von SAP.
- Die Ursachen lagen im Code der Bibliotheken, nicht in den Produkten, die darauf aufbauen.
- Odells Testsammlung für Playwright ist auf GitHub frei verfügbar.
Wie schnell reagieren die zehn Designsysteme?
Beim Öffnen der Länderauswahl lagen Fluent mit 61 ms und Carbon mit 63 ms vorn, Ionic brauchte 1.266 ms. Beim Markieren von 100 Checkboxen war Fluent mit 29 ms am schnellsten, Ant Design mit 421 ms am langsamsten.
Odell maß in Chrome mit vierfach gedrosselter CPU, wie lange der Hauptthread des Browsers nach dem Klick beschäftigt blieb. Carbon und Spectrum Web Components bauen beide auf Lit, die Länderauswahl von Spectrum Web Components brauchte trotzdem mehr als doppelt so lange.
Automatische Performance-Tests laufen nur bei Spectrum Web Components. Ant Design, Material UI und Fluent überwachen lediglich die Dateigröße des ausgelieferten Codes. Diese Zahl beeinflusst die Ladezeit, nicht die Reaktion auf einen Klick.
Woran liegt die Verzögerung?
Mit den Chrome-Entwicklerwerkzeugen fand Odell vier verschiedene Ursachen, alle im Code der Bibliotheken.
Bei Ionic ersetzt das Framework Stencil eine Browserfunktion durch eine eigene Fassung, die für jede neue Option alle vorhandenen dreimal durchsucht. Die Wartezeit wächst deshalb mit jeder Zeile: 203 ms bei 50 Ländern, 1.266 ms bei 249. Laut Stencil-Dokumentation sollen solche Korrekturen mit Version 5 zum Standard werden.[3] Odells Fehlerberichte an Ionic und Stencil stammen vom 27. Oktober.[4]
Ant Design zeigt nur die sichtbaren Einträge und lädt beim Scrollen nach, Material UI erzeugt dagegen alle rund 250 Elemente auf einmal. React Spectrum lädt ebenfalls nur die sichtbaren Einträge, berechnet aber für jede sichtbare Option das Layout neu. Bei Ant Designs Checkboxen kosteten Farbanimationen den Großteil der Zeit.
Öffnen der Länderauswahl in Millisekunden
Was hinter den Zahlen steckt
Ein Designsystem, das niemand mit 249 Ländern testet, vererbt seine Trägheit jedem Produkt, das darauf aufbaut.
Markus Seyfferth, Chefredakteur Dr. Web
Was sollten Agenturen und Inhouse-Teams jetzt prüfen?
Teams sollten ihre Komponenten mit realistischen Datenmengen messen und ein Zeitbudget festlegen, das ein automatischer Test bei jeder Änderung prüft.
Für barrierefreie Onlineshops gilt in Deutschland seit Juni 2025 das BFSG. Beim Tempo setzt Google den Maßstab: Seit März 2024 zählt Interaction to Next Paint (INP) zu den Core Web Vitals,[5] bis 200 ms gilt eine Reaktion als gut, über 500 ms als schlecht.[6] Odells Laborwerte stammen nicht von echten Besuchern, taugen aber als Frühwarnung. Auch bei UI5 von SAP fror die Seite mit 249 Ländern länger als 100 ms ein.
Wie viel ein schneller Unterbau bringt, zeigte GitHub im Juni: Mit umgebauten Grundkomponenten brauchte der Server 55 % weniger Zeit, um eine Seite zu rendern.
Odells Tests liegen samt Workflow für GitHub Actions bereit,[2] Teams kopieren einen Ordner und tauschen die Komponenten aus. Der frühere Canva-Entwickler rät zudem, in der Dokumentation festzuhalten, mit wie vielen Einträgen eine Komponente geprüft ist. Im Live-Betrieb messen Werkzeuge aus unserem Vergleich der Website-Monitoring-Tools. Wie stark Gestaltung die Ladezeit bestimmt, zeigt ein Praxisfall mit gemessenen Werten.
Quellen
6 Quellen anzeigenQuellen ausblenden
- Den OdellDesign Systems Should Be Fast by Default
- Den Odell auf GitHubdesign-system-performance-tests
- StencilExtras, Abschnitt experimentalSlotFixes
- Stencil auf GitHubbug: appendChildSlotFix makes each appended child element slower to add than the element added just before it
- web.devInteraction to Next Paint is officially a Core Web Vital
- web.devInteraction to Next Paint (INP)
Mehr Newshunger?
- Ein Designsystem ist, was es tut: Ex-USWDS-Entwickler warnt vor shadcn/ui für Behörden
- Fluid Functionalism: 28 shadcn-Komponenten, deren Hover dem Mauszeiger folgt
- Ladezustand im Ladezustand: Warum Marcin Wichary bei Figma Tipps im Ladebildschirm ablehnte
- Der „Disability Dongle“: Ein blinder Autor fordert sauberen Code statt teurer Prototypen
- WordPress-Performance: Welche Rolle das Hosting beim PageSpeed spielt
- Schnelle Software ist die beste Software
