Programmierung und Softwareentwicklung

Wie GitHub die Leistung seiner Website durch den Verzicht auf CSS-in-JS verbessert hat

GitHub hat die Migration seiner Website zu CSS Modules anstelle von CSS-in-JS abgeschlossen. Dadurch sanken die serverseitige Renderzeit um 55 % und die Zeit zur Initialisierung der Komponenten um 25 %. Die Erfahrung zeigt, wie Feature-Flags, visuelle Tests und Automatisierung eine umfassende Neustrukturierung ermöglichten, ohne die Website zu beschädigen.

2026-09-25
4 Min. Lesezeit
21 Aufrufe
certi.news Editorial Team
Wie GitHub die Leistung seiner Website durch den Verzicht auf CSS-in-JS verbessert hat

GitHub hat im Juni 2026 den Betrieb seiner Website vollständig mit CSS Modules abgeschlossen und damit die Abhängigkeit von CSS-in-JS beendet, einschließlich styled-components, styled-system und sx-Props. Nach Angaben des Unternehmens senkte dieser Wechsel die serverseitige Renderzeit um 55 % und verkürzte außerdem die für die Initialisierung der Komponenten auf der Seite benötigte Zeit um 25 %.

Der Schritt erfolgte als Reaktion auf die zunehmende Zahl von Komponenten auf einigen GitHub-Seiten seit 2023. Die vorherige Lösung erforderte die Initialisierung der Styles auf dem Client, erhöhte die Kosten für das Sammeln der Styles während des serverseitigen Renderings und erschwerte Aktualisierungen der Formatierung, je mehr Komponenten sich auf einer Seite befanden.

Warum hat GitHub CSS Modules gewählt?

CSS Modules ermöglicht es, Styles in CSS-Dateien neben dem Quellcode der Komponente zu schreiben, wobei Klassennamen standardmäßig lokal behandelt werden, um Konflikte zu verringern. Entscheidend war in diesem Fall, dass dadurch kein Laufzeitverhalten auf dem Client oder Server erforderlich ist: Die Styles werden in CSS-Dateien gebündelt, die zusammen mit dem HTML der Seite ausgeliefert werden.

Die Migration begann beim Designsystem Primer. Das Team fügte für jede Komponente CSS-Modules-Dateien hinzu, verknüpfte die Komponenten mit Feature-Flags, die den Wechsel zwischen dem alten und dem neuen Ansatz ermöglichten, und verwendete anschließend visuelle Regressionstests, um die Übereinstimmung der Ergebnisse zu überprüfen. Danach wurde die Umstellung schrittweise vom Primer-Team auf die GitHub-Mitarbeiter und anschließend auf alle Nutzer ausgeweitet.

Bis Dezember 2024 waren alle Primer-Komponenten zu CSS Modules migriert. Das reichte jedoch nicht aus, da große Teile der GitHub-Codebasis weiterhin die Eigenschaft sx verwendeten, um Komponenten über eingebettete Objekte anzupassen. Obwohl diese Methode eine gute Integration mit TypeScript und den Design-Tokens bot, erhöhte ihr dynamischer Charakter die Laufzeitkosten und erschwerte die Skalierung mit wachsender Komponentenanzahl.

Die Migration im großen Maßstab verwalten

Um bestehende Verwendungen nicht zu beschädigen, entwickelte GitHub eine Zwischenbibliothek namens @primer/styled-react. Diese Bibliothek ermöglichte die weitere Verwendung von sx mit Komponenten, die zu CSS Modules migriert worden waren. Routen, die sx nicht benötigten, konnten hingegen direkt aus @primer/react importieren.

Die Entfernung von sx begann im April 2025, als es etwa 7.760 Verwendungen dieser Eigenschaft gab. Mithilfe einer internen VS-Code-Erweiterung und eines Codemod-Tools migrierte eine Gruppe aus acht Ingenieuren innerhalb von sechs Monaten 6.419 Verwendungen. Dabei wurden auf einigen Seiten Verbesserungen der serverseitigen Renderzeit zwischen 1 % und 22 % erzielt. Im April 2026 sank die Zahl innerhalb von drei Wochen von 895 auf null, unter Beteiligung von zwei Ingenieuren und unter Verwendung von Programmieragenten in GitHub Copilot.

Die visuellen Themes blieben eine zusätzliche Herausforderung. GitHub unterstützt sieben Themes, jeweils mit einem Modus für hohen Kontrast, und Teile dieses Systems waren an styled-components gebunden. Daher migrierte das Team auch die Verwendungen von JavaScript und der Theme-Tools, während die Farbvariablen weiterhin in CSS definiert wurden.

Was bedeutet diese Erfahrung für Entwickler?

Die Zahlen von GitHub zeigen, dass der Verzicht auf Laufzeitlogik für Styles messbare Vorteile bringen kann, wenn Benutzeroberflächen stark anwachsen. Der wichtigste Wert dieser Erfahrung liegt jedoch nicht in der Wahl von CSS Modules an sich, sondern in der Art der Umsetzung: schrittweise Kompatibilität, Feature-Flags, visuelle Tests, schrittweise Veröffentlichung und überprüfbare Automatisierung.

Gleichzeitig zeigt der Prozess, dass der Wechsel von CSS-in-JS nicht nur darin besteht, die Schreibweise der Styles zu ersetzen. Er erforderte die Entfernung der sx-Eigenschaften, die Entkopplung der Themes von styled-components und die Aufrechterhaltung der Komponentenkompatibilität über einen langen Zeitraum. Daher belegen die Ergebnisse nicht, dass jedes Projekt dieselben Vorteile erzielen wird; sie hängen von der Größe GitHubs, der Struktur seiner Komponenten und der Art ab, wie es dynamische Formatierung verwendet.

Nachrichtenquelle
c
Autor

certi.news Editorial Team

Aus derselben Kategorie

Das könnte Sie interessieren

Alle Nachrichten anzeigen