Contexte et enjeux
Le client GitHub Copilot propose, au sein de l’IDE, une vue détaillée des pull requests (PR). Lorsque le nombre de fichiers modifiés dépasse quelques centaines, le rendu complet du diff devient lent, consomme beaucoup de mémoire et bloque l’interface. L’équipe d’ingénierie a donc cherché à réduire le temps d’affichage et à éviter les gelées du thread principal, tout en conservant la précision du diff fourni par le backend GitHub.
Architecture de rendu initiale
La version antérieure affichait le diff complet dès le chargement de la PR. Le processus s’appuyait sur une requête GraphQL qui renvoyait l’ensemble des changements, puis un composant React parcourait la totalité du texte pour le transformer en blocs HTML. Cette approche entraînait une surcharge du thread JavaScript, car chaque ligne était transformée et insérée dans le DOM, provoquant des temps de réponse de plusieurs dizaines de secondes pour les PR contenant des milliers de fichiers.
Optimisations mises en œuvre
Pour découpler le calcul du rendu du thread UI, l’équipe a introduit deux mécanismes majeurs : la virtualisation et le traitement en arrière‑plan. La virtualisation, implémentée via une bibliothèque de rendu différé, ne crée dans le DOM que les blocs visibles à l’écran, en chargeant dynamiquement les suivants au fur et à mesure du défilement. Cette technique réduit le nombre d’éléments DOM actifs de plusieurs milliers à quelques dizaines, limitant ainsi le coût de mise à jour du layout.
Parallèlement, le calcul du diff a été déplacé dans un Web Worker. Le worker reçoit les données brutes du backend, exécute l’algorithme de différenciation et renvoie les résultats sous forme de fragments déjà découpés. Le thread principal ne reçoit que les fragments prêts à l’affichage, ce qui élimine le blocage pendant le calcul intensif.
Enfin, un système de mise en cache locale mémorise les fragments déjà rendus. Lors d’une navigation répétée dans la même PR, le client récupère les fragments depuis le cache plutôt que de recalculer le diff, ce qui accélère les interactions ultérieures.
Bilan et limites
Les mesures internes montrent que le temps de première peinture passe de plusieurs dizaines de secondes à quelques secondes pour des PR contenant plusieurs milliers de fichiers. La consommation mémoire diminue proportionnellement, car le nombre d’éléments DOM actifs est fortement limité. Cependant, la solution repose sur la disponibilité du navigateur pour exécuter des Web Workers ; les environnements qui désactivent les workers (par exemple certaines extensions de sécurité) peuvent voir les performances se dégrader. De plus, la virtualisation implique que le texte complet n’est jamais présent dans le DOM, ce qui peut compliquer certaines extensions qui s’appuient sur l’arbre DOM complet pour l’analyse statique.
En résumé, la combinaison de virtualisation, de calcul asynchrone via Web Workers et de mise en cache locale constitue une réponse technique robuste aux problèmes de rendu des PR massives dans GitHub Copilot, tout en introduisant de nouvelles contraintes liées à la compatibilité des navigateurs et à l’interaction avec des outils tiers.
