Le site web de GitHub fonctionne lentement dans Safari

• Ces derniers mois, le site web de GitHub est devenu progressivement plus lent dans le navigateur Safari
• Sur les gros PR ou les fichiers contenant des milliers de lignes de code, le rendu de l’écran devient pratiquement impossible
• Le processus de rendu du navigateur utilise 100 % et, lors du défilement, des zones blanches s’affichent ; les fonctions de recherche et de commentaires subissent aussi de très fortes latences
• Des modifications CSS et l’usage de transform entrent en conflit avec un bug de performance de Safari et provoquent le problème ; d’autres navigateurs comme Chrome s’en sortent relativement mieux
• Quelques correctifs de performance ont été appliqués dans WebKit, mais il est indiqué qu’une réponse temporaire de l’équipe frontend de GitHub sera nécessaire jusqu’à la prochaine version de Safari

---

Contexte et principaux problèmes

• Ces derniers temps, la dégradation globale des performances est particulièrement visible lorsqu’on accède au site web de GitHub avec le navigateur Safari
• En particulier, lorsqu’on consulte des Pull Requests (PR) avec des modifications de plusieurs milliers de lignes ou qu’on parcourt de gros fichiers de code, on atteint un niveau où le rendu lui-même devient impossible
• Dans Activity Monitor, le processus de rendu monopolise 100 % du CPU, et la page se rend si lentement que l’écran apparaît vide pendant le défilement
• Les fonctions interactives comme la recherche ou les commentaires sont gravement ralenties, et lors d’une revue de PR, même cliquer sur une case à cocher peut prendre plusieurs secondes
• Le même phénomène se produit même sur les derniers MacBook Pro haut de gamme équipés d’Apple Silicon, alors que Chrome ou d’autres navigateurs offrent une expérience bien meilleure

Cause du problème et analyse

• Des plaintes communes ont été signalées chez les utilisateurs de Safari 18.6 (ainsi que des versions bêta / Technology Preview)
• Certains utilisateurs indiquent que cette forte dégradation des performances se produit surtout sur GitHub, et non dans Safari de manière générale
• Il est expliqué que l’usage massif de sélecteurs CSS et de transform: translateY entre directement en conflit avec les limites de gestion des couches GPU de Safari
  • Le frontend de GitHub positionne toutes les lignes de texte avec transform: translateY, ce qui amène Safari à créer des milliers de couches GPU
  • Chrome, lorsqu’il n’y a pas ce type d’animation, optimise la création des couches et montre donc des performances relativement moins mauvaises
  • Comme solution temporaire, l’application d’un script supprimant la propriété transform accélère l’affichage, mais la précision du positionnement n’est pas parfaite

Expérience utilisateur et signalements variés

• Plusieurs utilisateurs se plaignent que toutes les interactions dans les PR, comme l’ajout de reviewers ou de labels, ou la modification de la description du PR, subissent des retards de plusieurs secondes
• Lors d’un accès via Safari, l’interface du navigateur de code ainsi que les fonctionnalités d’autocomplétion (barre de recherche, palette de commandes, etc.) deviennent très lentes
• Sur Safari iOS, il existe aussi des cas où des fonctions du navigateur comme le bouton natif retour ne fonctionnent pas correctement
• Du point de vue de l’accessibilité (VoiceOver), la dégradation des performances est également sévère, au point de rendre l’usage presque impossible pour les utilisateurs malvoyants

Discussions sur les solutions et la réponse

• Côté WebKit (moteur de Safari), quelques correctifs récents sur ce problème de performances lié au CSS / au compositeur ont été apportés, mais une résolution immédiate reste difficile avant la prochaine version de Safari
• Il est mentionné qu’il faut proposer aux ingénieurs de GitHub une réponse au bug avant la prochaine version de Safari et communiquer en amont sur les problèmes de performances
• Divers changements dans l’interface frontend (par exemple l’UI des fichiers modifiés dans les PR, de nouvelles fonctionnalités, etc.) sont considérés comme directement liés à cette dégradation des performances
• Certains utilisateurs contournent le problème ou utilisent une interface alternative via Graphite.dev, GitLab, ou des routeurs de protocole personnalisés (par ex. Finicky, Velja)

Autres commentaires et astuces d’usage

• Comme solution de contournement temporaire, il est conseillé dans Safari d’utiliser la fonctionnalité d’ajout de labels en mode tableau après avoir créé une issue ou une PR
• Des voix soulignent aussi la nécessité de prendre en charge divers navigateurs, tout en exprimant des inquiétudes face à une CSS trop complexe, à l’évolution de l’architecture d’ingénierie et à une standardisation excessive autour de Chrome
• Certains utilisateurs ont ajouté des commentaires critiques ou humoristiques sur les problèmes de performances (avec un rappel à éviter les débats émotionnels inutiles dans la discussion)
• Des avis internes et externes appellent à repenser les pratiques de développement frontend nécessitant une optimisation des performances, ainsi qu’à renforcer l’importance des tests multi-navigateurs

Conclusion

• Les récents changements de structure UI de GitHub et sa manière d’utiliser le CSS entrent en conflit avec les caractéristiques propres du rendu de Safari, provoquant des gênes critiques sur une plateforme de collaboration considérée comme standard dans l’industrie
• Une volonté d’amélioration active est nécessaire à la fois de la part de WebKit et de GitHub, avec à court terme une réponse centrée sur les utilisateurs de Safari et sur l’accessibilité
• Il s’agit d’un problème de performance suffisamment grave pour perturber le travail de développement, suscitant une forte empathie et une grande colère au sein de la communauté

[GN⁺]

Avis Hacker News

• Le site de GitHub est plutôt lent partout. On ne peut pas vraiment dire que c’est un bon logiciel, ni en performance ni en UX/UI, et ça donne l’impression d’un produit façonné par les KPI et les plans de toute une série d’intervenants. Le fait même que ce soit un réseau social pour développeurs est probablement sa partie la plus « innovante », et pour le travail de développement au quotidien, c’est tellement banal qu’on en vient à trouver GitLab bien meilleur. Ce problème n’est pas dû à Rails, et je ne pense pas qu’il soit juste d’esquiver le fond du sujet en l’enrobant de considérations techniques

  • Le problème de GitHub, ce n’est pas Rails mais le passage à React. L’ancien GitHub basé sur le SSR était vraiment rapide et permettait de relire sans problème des PR volumineuses
  • Après plusieurs années sans utiliser GitHub, j’y suis revenu cette année et j’ai été vraiment choqué par sa lenteur. J’ai dû changer complètement ma façon de l’utiliser à cause des ralentissements à chaque interaction. On a constamment l’impression que quelque chose ne tourne pas rond, et quand il ne se passe rien pendant quelques secondes, on finit par craindre que le serveur soit bloqué
  • Après 10 ans sur Phabricator, arriver sur GitHub est déroutant tant l’écart de qualité est grand, et j’ai du mal à croire que ce soit devenu la norme. C’est dommage que Phabricator ne soit plus qu’en maintenance wiki Phabricator
  • GitHub était vraiment agréable à utiliser avant, mais depuis le passage au SPA c’est devenu pénible
  • J’ai déjà eu un CTO qui attribuait systématiquement les problèmes de performance d’une application legacy à Rails et voulait tout réécrire en Java. En réalité, la cause profonde était l’accumulation de décisions de mauvais chefs de produit, de dirigeants incompétents et de développeurs peu expérimentés. Quand un projet est mal géré pendant plus de 10 ans, le résultat est le même quelle que soit la stack

• L’équipe WebKit a déployé ces deux derniers jours des améliorations pour les problèmes de performance de GitHub dans Safari lien associé. Quelqu’un dans l’équipe a même créé une PR massive de plus de 1 000 fichiers, et ses collègues disaient en plaisantant : « quand elle s’ouvrira, je l’approuverai »

  • Tout le monde dit que JS et React sont en cause, mais ce patch concerne en réalité les performances CSS
  • Comme Chrome et ses dérivés dominent de fait le marché des moteurs de rendu, il est rassurant de voir Apple continuer à rendre Safari compétitif sur macOS/iOS, surtout maintenant que la croissance de Firefox ralentit
  • Je me demande à quoi correspond concrètement une PR avec plus de 1 000 fichiers
  • En réalité, c’était un bug révélé parce que GitHub surchargeait excessivement Safari WebKit. En tant que développeurs ou utilisateurs, on a tendance à rejeter la faute uniquement sur GitHub
  • Je me demande combien de temps il faut pour qu’un correctif WebKit arrive jusqu’aux utilisateurs finaux. Est-ce qu’il faut attendre une mise à jour de l’OS pour Safari, ou est-ce que les mises à jour sont plutôt rapides comme pour Chrome/Firefox ?

• Dès que Microsoft a racheté GitHub, GitHub est presque immédiatement passé à un rendu JavaScript de type SPA. Avant, il était possible de naviguer sur GitHub sur un Mac Mini de 2011 avec JavaScript désactivé, alors qu’aujourd’hui le service est inutilisable sur d’anciens navigateurs même avec JS activé. Il est difficile de dire quel côté pose le plus problème, mais je pense que les deux portent une part de responsabilité. On peut toujours remplacer son matériel par un plus récent, mais dans un climat où l’on abandonne volontairement le support des anciens appareils et où l’on impose l’obsolescence programmée au détriment des capacités futures, on finit même par perdre confiance dans les standards du web

  • Si vous l’apprenez aujourd’hui, sachez qu’avec OpenCore Legacy Patcher on peut mettre à jour macOS jusqu’à la dernière version sur des Mac allant jusqu’au modèle 2007 lien OpenCore Legacy Patcher
  • Je me demande ce que ça donnerait d’installer et d’utiliser Chrome ou Firefox
  • Je me demande pourquoi la notion de Turing completeness paraît si mensongère. Il y a l’obsolescence programmée, mais aussi un environnement logiciel moderne saturé d’abstractions. Si tous les logiciels devaient être écrits en C, le monde actuel serait très différent. On s’est sans doute trop enfermé dans des abstractions de haut niveau, mais il est difficile de revenir en arrière. La Turing completeness a en réalité peu à voir avec ça, si ce n’est qu’elle s’accompagne d’une consommation de ressources encore plus importante
  • J’insiste sur le fait que la Turing completeness n’a rien à voir avec les performances. En théorie, on pourrait même émuler une machine plus récente sur le matériel actuel
  • Certains se plaignent de la fin du support OS d’un Mac Mini 2011, mais naviguer sur Internet avec un navigateur vieux de plus de 8 ans revient, du point de vue sécurité, à laisser toutes les portes de sa maison grandes ouvertes

• Il y a beaucoup de critiques contre React, mais dans ce cas précis il s’agit d’un problème de transform CSS. Je recommande de lire réellement le contenu du lien associé

• Je recommande de migrer vers Forgejo, Codeberg ou SourceHut. C’est d’une rapidité fulgurante comparé à GitHub et GitLab Forgejo / Codeberg / SourceHut

  • J’ai fait tourner un serveur Forgejo pendant plusieurs semaines sur une ligne dégradée, de l’ordre de quelques kilobits par seconde, et ça a plutôt bien tenu. Les push/pull fonctionnaient tant bien que mal, mais les actions étaient difficiles à utiliser car elles nécessitaient plus de 100 MB de transfert

• Je me demande comment ce type de problème peut se répéter dans de grandes organisations. Ils ont forcément dû voir les problèmes de performance dans les tests sur les principaux navigateurs, donc j’ai du mal à comprendre que quelqu’un ait pu donner son feu vert

  • L’industrie IT actuelle se divise en trois groupes : 1) les PM qui poussent agressivement à sortir vite et ne jurent que par la vitesse ; 2) les développeurs qui résistent à ces demandes, y brûlent leur capital politique et finissent en burn-out ; 3) les développeurs qui se contentent mécaniquement du travail qu’on leur donne, sans plus s’en soucier. Au final, le vrai problème est culturel, et rien ne changera sans réforme en profondeur au niveau C-level. La plupart des dirigeants n’ont aucune volonté de changer cela
  • Dans les grandes organisations, le critère le plus important pour choisir une stack technique est de savoir à quel point il est facile d’embaucher et de licencier. Il y a beaucoup de développeurs React, alors que les profils Rails sont plus difficiles à trouver. L’avis des développeurs est ignoré, les besoins de l’organisation passent d’abord, et cela produit des services lents et de mauvaise qualité. Les développeurs connaissent eux aussi le problème, mais leur priorité reste de survivre
  • Autrefois, on disait « on ne se fait pas virer pour avoir acheté IBM » ; aujourd’hui, l’ambiance ressemble plutôt à « on se fait virer si on n’utilise pas React ». Comme tout le monde utilise React, même GitHub finit par devenir lent. Les mauvais développeurs suivent ce que font les autres, les bons choisissent les outils les plus simples selon le principe KISS
  • Dans les grandes structures, la notion de « propriété » devient floue, le turnover et les objectifs de court terme dominent, et ce genre de problème se répète sans cesse. La pression pour ajouter des fonctionnalités et l’accumulation de dette technique augmentent, tandis que le sens des responsabilités disparaît. Et si on soulève le problème, on crée au contraire des tensions et on risque de finir dans un plan d’amélioration des performances

• En tant que développeur React, ce fil me fait ressentir toute la haine du monde. Il y a énormément de pièges dans les SPA, entre délais irréalistes et logique backend qu’on finit aussi par empiler côté frontend. Je me demande si React est vraiment un mauvais choix en soi, ou s’il existe de vraies applications React bien conçues

  • J’ai longtemps été un fervent partisan de React/SPA, mais je me rends compte peu à peu que le développement est devenu encore plus difficile qu’à l’époque des applications desktop en C++ MFC. On disait que le markup déclaratif réduisait la charge cognitive, mais en réalité la combinaison UI déclarative + gestion des événements et de l’état a encore accru la complexité, au point de devenir plus compliquée que le développement procédural d’autrefois. Mon ancien code C++ était parfois plus facile à comprendre que des hooks React
  • Il y a beaucoup de critiques sur les SPA, mais il existe aussi de très bonnes applications React/Angular. Exemple : Clockify. Et je ne pense pas qu’une application problématique verrait soudainement son UX devenir bonne simplement parce qu’elle serait rendue en SSR. La vraie cause, c’est une culture d’entreprise focalisée sur la livraison rapide de fonctionnalités au détriment de la qualité
  • Ce genre de technologie ne ressort vraiment que quand les performances sont mauvaises. Comme tout le monde utilise les technologies web au quotidien, c’est facile de les critiquer. Et comme ce sont des technologies très utilisées par les développeurs débutants, elles attirent encore plus de reproches. C’est un cas typique de brouillage des frontières
  • Le problème n’est pas React en soi, mais la façon dont les développeurs l’utilisent. On peut disposer d’innombrables optimisations et quand même se retrouver avec un temps de réponse au clic de 1,3 seconde si tout est mal assemblé
  • React n’est pas mauvais en soi, et c’est souvent la structure SPA qui pose des problèmes. React n’est qu’un outil qui a rendu l’usage des SPA plus facile

• J’ai l’impression que tout l’écosystème informatique est devenu plus lent. Même avec un Mac Studio M4 Max récent et 64 GB de RAM, tous les sites web me paraissent plus lents qu’à l’époque de mon MacBook Pro 2011

  • Quand on utilisait Internet il y a 15 ans, c’était clairement plus lent, mais on n’utilisait pas encore sur le web des tableurs complexes ou des outils de design. Les Mac à puce M sont les ordinateurs les plus rapides que j’aie jamais utilisés, à part les desktops Linux
  • Je pense que les développeurs web devraient développer en utilisant du matériel correspondant au bas des 10 % du parc utilisateur. Sinon, on pourrait aussi faire de la performance un critère WCAG à part entière

• Sur HN, j’ai souvent lu que GitHub était devenu lent à cause de la migration de son interface vers React, mais je me demande si c’est réellement le cas. Sur de petits projets, l’impact ne se voit pas, donc j’aimerais trouver des éléments concrets

  • Un billet de blog lu récemment explique bien la cause. En résumé, la vue de PR rend plus de 100 000 nœuds DOM, dont une grande partie sont des nœuds SVG invisibles. L’analyse explique aussi que la navigation est beaucoup plus lente à cause du routage SPA blog associé / discussion HN
  • Il semble que la récente refonte de la page de diff des PR ait encore alourdi le DOM

• GitHub est extrêmement lent non seulement dans Safari mais aussi dans Firefox, avec des spinners de chargement visibles un peu partout et des transitions de page plus longues qu’avant. Je ne comprends vraiment pas sur quels indicateurs ils se sont appuyés pour remplacer un SSR qui fonctionnait parfaitement par un SPA

  • Récemment, il y a aussi des problèmes similaires dans Chrome. Dans les trois navigateurs, même les PR pas très grosses finissent par ne plus fonctionner correctement