GitHub-Website läuft in Safari langsam

• In den letzten Monaten ist die Geschwindigkeit der GitHub-Website im Safari-Browser schrittweise gesunken
• Bei großen PRs oder Codedateien mit Tausenden von Zeilen ist das Rendern des Bildschirms praktisch unmöglich geworden
• Es treten 100 % Auslastung des Rendering-Prozesses im Browser, leere Bildschirme beim Scrollen sowie starke Verzögerungen bei Suche und Kommentaren auf
• CSS-Änderungen und der Einsatz von transform kollidieren mit einem Performance-Bug in Safari und verursachen das Problem; andere Browser wie Chrome sind vergleichsweise weniger betroffen
• In WebKit wurden einige Performance-Patches umgesetzt, doch bis zum nächsten Safari-Release ist laut GitHubs Frontend-Team ein provisorisches Gegensteuern nötig

---

Hintergrund und Hauptprobleme

• Beim Zugriff auf die GitHub-Website mit dem Safari-Browser fällt in letzter Zeit insgesamt ein deutlicher Performance-Abfall auf
• Besonders beim Prüfen von Pull Requests (PRs) mit Änderungen von mehreren Tausend Zeilen oder beim Durchsuchen großer Codedateien erreicht das Problem ein Niveau, bei dem das Rendern selbst kaum noch möglich ist
• Im Activity Monitor belegt der Rendering-Prozess 100 % CPU, und das Seiten-Rendering ist so langsam, dass beim Scrollen nur leere Bereiche erscheinen
• Interaktive Funktionen wie Suche und Kommentare reagieren stark verzögert, und selbst das Anklicken von Checkboxen bei PR-Reviews dauert mehrere Sekunden
• Dasselbe Verhalten tritt auch auf aktuellen MacBook Pro mit leistungsstarkem Apple Silicon auf, während Chrome oder andere Browser eine deutlich bessere Erfahrung bieten

Ursache und Analyse des Problems

• Gemeinsame Beschwerden von Nutzern der Safari-Version 18.6 (sowie Beta- und Tech-Preview-Versionen)
• Einige Nutzer erwähnen, dass die schwerwiegenden Performance-Einbrüche nur bei GitHub und nicht allgemein in Safari auftreten
• Der umfangreiche Einsatz von CSS-Selektoren und transform: translateY wird als direkter Konflikt mit Safaris Grenzen bei der Verarbeitung von GPU-Layern beschrieben
  • Da GitHubs Frontend jede Textzeile mit transform: translateY positioniert, erzeugt Safari Tausende von GPU-Layern
  • Chrome optimiert die Layer-Erzeugung, wenn solche Animationen nicht vorhanden sind, und zeigt daher vergleichsweise weniger starke Verlangsamungen
  • Als vorläufige Maßnahme beschleunigt ein Skript zum Entfernen der transform-Eigenschaft die Darstellung, allerdings nicht mit perfekter Positionsgenauigkeit

Nutzererfahrung und verschiedene Berichte

• Mehrere Nutzer beklagen, dass in PRs jede Interaktion wie das Hinzufügen von Reviewern und Labels oder das Bearbeiten der PR-Beschreibung um mehrere Sekunden verzögert ist
• In Safari werden der Code-Browser und die Autovervollständigungs-UI (Suchleiste, Command Palette usw.) sehr langsam
• Es gibt Fälle, in denen auf iOS Safari auch Browserfunktionen wie der native Zurück-Button nicht korrekt funktionieren
• Auch bei der Barrierefreiheit mit VoiceOver ist der Performance-Abfall so stark, dass die Nutzung für sehbehinderte Anwender nahezu unmöglich wird

Diskussion zu Lösung und Gegenmaßnahmen

• Auf WebKit-Seite (Safari-Engine) wurden zuletzt einige Patches für dieses CSS-/Compositor-Performance-Problem umgesetzt, eine sofortige Lösung vor dem nächsten Safari-Release ist jedoch schwierig
• Für GitHub-Ingenieure wurde die Notwendigkeit erwähnt, vor dem nächsten Safari-Release Bug-Gegenmaßnahmen vorzuschlagen und Performance-Probleme frühzeitig zu kommunizieren
• Verschiedene Änderungen an der Frontend-UI (z. B. die Dateiansicht in PRs, neue Funktionen usw.) gelten als direkt mit dem Performance-Abfall verbunden
• Einige Nutzer weichen auf Graphite.dev, GitLab oder Custom-Protocol-Router (z. B. Finicky, Velja usw.) aus beziehungsweise nutzen alternative UIs

Weitere Anmerkungen und praktische Tipps

• Als vorübergehender Workaround wird empfohlen, in Safari nach dem Erstellen eines Issues/PR die tabellenbasierte Funktion zum Hinzufügen von Labels zu verwenden
• Es gibt Stimmen, die vor zu komplexem CSS, Änderungen in der Engineering-Struktur und einer einseitigen Ausrichtung auf Chrome warnen und breitere Browser-Unterstützung fordern
• Einige Nutzer äußern sich kritisch oder humorvoll zu dem Performance-Problem (unnötig emotionale Debatten sollten in Diskussionen vermieden werden)
• Intern und extern wird gefordert, Frontend-Entwicklung mit Blick auf Performance-Optimierung zu überdenken und Multi-Browser-Tests stärker zu gewichten

Fazit

• Die jüngsten Änderungen an GitHubs UI-Struktur und der Einsatz von CSS kollidieren mit Safaris speziellen Rendering-Eigenschaften und verursachen auf einer branchenweit genutzten Kollaborationsplattform gravierende Browser-Probleme
• Sowohl WebKit als auch GitHub müssen aktiv Verbesserungen vorantreiben; kurzfristig ist eine Reaktion mit Fokus auf Safari- und Barrierefreiheitsnutzer nötig
• Das Performance-Problem ist so gravierend, dass es die Entwicklungsarbeit behindert und in der Community große Zustimmung und Verärgerung auslöst

[GN⁺]

Hacker-News-Kommentare

• Die Github-Website ist generell überall eher langsam. Weder bei Performance noch bei UX/UI kann man sie als gute Software bezeichnen, und sie wirkt wie das Ergebnis, in das die KPIs und Planungen vieler Leute eingeflossen sind. Dass sie überhaupt ein soziales Netzwerk für Entwickler ist, scheint der „innovativste“ Teil zu sein, und für die tägliche Entwicklungsarbeit ist sie so mittelmäßig, dass Gitlab deutlich besser wirkt. Das Problem liegt nicht an Rails, und es ist nicht richtig, das Wesentliche zu umgehen, indem man es als Technikproblem tarnt

  • Das Problem von Github ist nicht Rails, sondern der Umstieg auf React. Früher war Github mit SSR wirklich schnell, und auch große PRs ließen sich problemlos prüfen
  • Nachdem ich Github einige Jahre nicht benutzt hatte und es dieses Jahr wieder ausprobiert habe, war ich wirklich schockiert, wie langsam es geworden ist. Wegen der Langsamkeit bei jeder Interaktion musste ich meine gesamte Nutzungsweise ändern. Es fühlt sich ständig so an, als stimme etwas nicht, und wenn mehrere Sekunden lang keine Reaktion kommt, hat man fast Angst, der Server sei stehen geblieben
  • Nach 10 Jahren mit Phabricator ist der Wechsel zu Github wegen des großen Qualitätsunterschieds ziemlich befremdlich, und ich kann kaum glauben, dass das der Standard sein soll. Schade, dass Phabricator inzwischen nur noch im Maintenance-Modus ist Phabricator-Wiki
  • Früher war Github wirklich angenehm schnell, aber seit der Umstellung auf eine SPA ist es unerquicklich geworden
  • Ich habe früher erlebt, wie ein CTO die Performance-Probleme einer Legacy-App pauschal Rails angelastet und gefordert hat, alles in Java neu zu schreiben. In Wahrheit war die eigentliche Ursache das kumulierte Ergebnis unfähiger Planer, des Managements und unerfahrener Entwickler. Wenn ein Projekt über mehr als 10 Jahre falsch gemanagt wurde, ist das Ergebnis bei jedem Stack dasselbe

• Das WebKit-Team hat in den letzten zwei Tagen Verbesserungen für das Github-Performance-Problem eingespielt passender Link. Im Team wurden auch große PRs erstellt (mehr als 1000 Dateien), und die Kollegen sagen dann nur: „Wenn es geladen ist, gebe ich es frei“

  • Alle sagen, JS und React seien das Problem, aber tatsächlich betrifft dieser Patch die CSS-Performance
  • Da Chrome und abgeleitete Browser die Rendering-Engines faktisch beherrschen und Firefox zuletzt kaum noch wächst, ist es erfreulich, dass Apple Safari auf macOS/iOS weiterhin konkurrenzfähig hält
  • Ich frage mich, was für eine konkrete Arbeit in einem PR mit mehr als 1000 Dateien steckt
  • Tatsächlich war es ein Bug in Safari WebKit, der sichtbar wurde, weil Github es übermäßig belastet hat. Als Entwickler oder Nutzer neigen wir leicht dazu, die Ursache nur Github zuzuschreiben
  • Ich frage mich, wie lange es dauert, bis echte Nutzer einen WebKit-Patch bekommen. Muss man bei Safari auf ein OS-Update warten, oder geht das mit Updates eher schnell wie bei Chrome/Firefox?

• Direkt nachdem Microsoft Github übernommen hatte, wechselte Github fast sofort auf JavaScript-Rendering als SPA. Früher konnte man selbst auf einem Mac Mini von 2011 mit deaktiviertem JavaScript noch durch Github navigieren, heute ist Github selbst mit aktiviertem JS wegen der Kompatibilität alter Browser nicht mehr nutzbar. Es ist schwer zu sagen, welche Seite problematischer ist, aber ich denke, beide tragen Verantwortung. Man könnte natürlich auf neuere Geräte wechseln, aber in einer Atmosphäre, in der die Unterstützung alter Hardware bewusst aufgegeben und statt künftiger Funktionalität geplante Obsoleszenz erzwungen wird, verliert man sogar das Vertrauen in Webstandards

  • Falls man das heute zum ersten Mal hört: Mit OpenCore Legacy Patcher kann man macOS sogar auf einem Mac von 2007 auf die neueste Version bringen OpenCore Legacy Patcher-Link
  • Ich frage mich, wie es wäre, einfach Chrome oder Firefox zu installieren und zu nutzen
  • Ich frage mich, warum sich Turing completeness wie eine Lüge anfühlt. Geplante Obsoleszenz spielt eine Rolle, aber moderne Software-Umgebungen haben auch viel zu viele Abstraktionen. Wenn alle Software in C geschrieben werden müsste, sähe die Welt heute ganz anders aus. Es wirkt, als hätten wir uns in zu hohe Abstraktion verrannt, aber nun sind wir schon so weit gekommen, dass ein Zurück schwer ist. Mit Turing completeness selbst hat das fast nichts zu tun; eher führt das Ergebnis dazu, dass noch mehr Ressourcen verbraucht werden
  • Ich betone, dass Turing completeness nichts mit Performance zu tun hat. Theoretisch könnte man auf heutigen Geräten sogar neuere Geräte emulieren
  • Manche beschweren sich darüber, dass der OS-Support für den Mac Mini von 2011 eingestellt wurde, aber mit einem Browser, der seit über 8 Jahren keine Updates mehr bekommt, ins Internet zu gehen, ist aus Sicherheitsgründen fast so, als würde man alle Türen des Hauses offen lassen

• Es gibt viel Kritik an React, aber bei diesem Problem geht es um CSS transforms. Ich würde empfehlen, den verlinkten Inhalt tatsächlich zu lesen

• Ich empfehle eine Migration zu Forgejo, Codeberg oder SourceHut. Im Vergleich zu Github und Gitlab sind sie blitzschnell Forgejo / Codeberg / SourceHut

  • Ich habe einen Forgejo-Server mehrere Wochen lang über eine kaputte Leitung betrieben, die nur Kilobit pro Sekunde schaffte, und er hat sich erstaunlich gut gehalten. Push/Pull funktionierte irgendwie, aber Actions waren schwierig, weil dafür mehr als 100 MB übertragen werden mussten

• Ich frage mich, wie sich solche Probleme in großen Organisationen immer wiederholen können. Bei den Tests in den wichtigsten Browsern müssten Performance-Probleme doch klar aufgefallen sein, daher verstehe ich nicht, wie jemand das trotzdem durchwinken konnte

  • Die heutige IT-Branche besteht aus drei Gruppen: 1) PMs, die aggressiv auf Releases drängen und nur auf Tempo schauen. 2) Entwickler, die sich dagegen stemmen, dabei ständig politisches Kapital verbrennen und ausbrennen. 3) Eine Gruppe von Entwicklern, denen alles egal ist und die ihre Aufgaben nur mechanisch erledigen. Letztlich ist die Kultur selbst das Problem, und ohne umfassende Reformen auf C-Level wird sich nichts ändern. Die meisten Führungskräfte haben keinen Willen, das zu ändern
  • In großen Organisationen ist bei der Wahl des Tech-Stacks das wichtigste Kriterium, „wie leicht man einstellen und entlassen kann“. React-Entwickler gibt es viele, Rails-Leute sind schwerer zu finden. Die Meinung der Entwickler wird ignoriert, die Bedürfnisse der Organisation haben Vorrang, und das führt zu langsamen Services und schlechter Qualität. Die Entwickler kennen das Problem zwar, aber Überleben geht vor
  • Früher sagte man: „Mit IBM wird man nicht gefeuert“, heute herrscht eher die Stimmung: „Wenn du nicht React nutzt, wirst du gefeuert.“ Weil alle React verwenden, wird sogar Github langsam, und das geht immer weiter. Schlechte Entwickler folgen dem, was alle anderen tun, gute Entwickler wählen nach dem KISS-Prinzip das einfachste Werkzeug
  • In großen Organisationen werden „Ownership“ unklar, Fluktuation und kurzfristige Ziele dominieren, und deshalb wiederholen sich solche Probleme ständig. Der Druck, Features zu ergänzen, und die technische Schuld häufen sich, während das Verantwortungsgefühl verschwindet. Wenn man Probleme anspricht, entstehen eher Konflikte, und man landet schnell in einem Performance-Improvement-Plan

• Als React-Entwickler spüre ich beim Lesen dieses Threads den Hass der Welt. Es gibt viele Fallen bei unrealistischen Zeitplänen und SPAs, in die sogar Backend-Logik auf das Frontend geladen wird. Ich frage mich, ob React selbst die falsche Wahl ist oder ob es wirklich gut gemachte React-Apps gibt

  • Ich war lange ein begeisterter Fan von React/SPAs, aber allmählich merke ich, dass Entwicklung heute sogar schwieriger geworden ist als damals, als ich C++-MFC-Desktop-Apps gebaut habe. Man sagte, deklaratives Markup würde die kognitive Last verringern, aber tatsächlich machen die Komplexität deklarativer UIs zusammen mit Event- und State-Management alles schwieriger als früher bei prozeduraler Entwicklung. Alter C++-Code war oft leichter zu verstehen als React hooks
  • Es gibt viel Kritik an SPAs, aber es gibt auch wirklich gut gemachte React-/Angular-Apps. Beispiel: Clockify. Bei problematischen Apps würde sich die UX auch nicht plötzlich verbessern, nur weil sie per SSR gerendert werden. Die eigentliche Ursache ist die Organisationskultur, in der schnelle Feature-Releases wichtiger sind als Qualität
  • Solche Technologien fallen nur dann besonders auf, wenn die Performance schlecht ist. Weil alle täglich Webtechnologien nutzen, lässt sich leicht darüber schimpfen. Vor allem werden sie von vielen Einsteigerentwicklern genutzt und deshalb noch stärker kritisiert. Das ist ein extremes Beispiel für Boundary Erosion
  • Das Problem liegt nicht an React selbst, sondern daran, dass die Entwickler es falsch einsetzen. Man kann unzählige Optimierungen haben und trotzdem bei falscher Verknüpfung auf 1,3 Sekunden Klickreaktion kommen
  • React an sich ist nicht schlecht, problematisch ist oft die Struktur von SPAs. React ist nur ein Werkzeug, das die Nutzung von SPAs erleichtert

• Generell fühlt sich in der Computerwelt alles langsamer an. Selbst mit einem aktuellen Mac Studio M4 Max und 64 GB RAM ist jede Website langsamer als früher auf meinem MacBook Pro von 2011

  • Vor 15 Jahren war das Internet natürlich auch langsam, aber damals hat man im Web keine komplexen Tabellenkalkulationen oder Design-Tools genutzt. Macs mit M-Serie sind die schnellsten Computer, die ich je benutzt habe (abgesehen von Linux-Desktops)
  • Ich finde, Webentwickler sollten beim Entwickeln Geräte nutzen, die eher den unteren 10 % der Nutzergeräte entsprechen. Oder man könnte Performance selbst zu einem WCAG-Kriterium machen

• Auf HN hört man oft, Github sei langsam geworden, seit die UI auf React migriert wurde, aber ich frage mich, ob das wirklich stimmt. Bei kleinen Projekten merke ich keinen Effekt, daher hätte ich gern belastbare Hinweise

  • Ein Blogbeitrag, den ich kürzlich gelesen habe, erklärt die Ursache gut. Kurz gesagt: In der PR-Ansicht werden mehr als 100.000 DOM-Knoten gerendert, und ein erheblicher Teil davon sind unsichtbare SVG-Knoten. Wegen des SPA-Routings sei auch die Navigation deutlich langsamer geworden passender Blog / HN-Diskussion
  • Die PR-Diff-Seite wurde kürzlich neu gestaltet, und dadurch scheint der DOM noch weiter aufgebläht worden zu sein

• Nicht nur in Safari, auch in Firefox ist Github extrem langsam. Überall sieht man Lade-Spinner, und Seitenwechsel dauern länger als früher. Ich verstehe wirklich nicht, anhand welcher Metriken man das zuvor perfekt funktionierende SSR überhaupt in eine SPA umgestellt hat

  • In letzter Zeit gibt es ähnliche Probleme auch in Chrome. In allen drei Browsern funktioniert es selbst bei nicht besonders großen PRs nicht richtig