Garder Figma rapide

• À mesure que le projet gagnait en complexité, les ressources nécessaires aux tests de performance ont fortement augmenté, rendant nécessaire un nouveau système de test.
• L’objectif était un système de test idéal capable d’exécuter des tests pour chaque modification de code, de les terminer en moins de 10 minutes et d’analyser les résultats en détail.
• Les performances de Figma dépendaient principalement du CPU et du GPU, et après avoir évalué les avantages et les inconvénients de plusieurs approches, le système a été structuré en deux grands volets.
• Système basé sur le cloud
  • Utilisation de VM équipées de GPU exécutant Headless Chromium pour lancer les tests en parallèle et les terminer en moins de 10 minutes.
  • En raison de la nature des VM, facilement affectées par des facteurs externes, une marge d’environ 20 % a été prévue.
• Système basé sur du matériel
  • Tous les tests sont planifiés puis exécutés séquentiellement sur un système composé de vieux ordinateurs portables (anciens MacBook, portables Windows, Chromebook, etc.).
  • Les tests prennent plus de temps, mais permettent de suivre en détail les variations de performance subtiles observées sur des appareils réels.
• Après avoir mis en place ces deux systèmes de test et travaillé à l’amélioration des performances, des résultats positifs ont été obtenus.
• Amélioration des performances de rendu
  • Efforts visant à améliorer les performances de rendu lorsque le GPU est présent dans un environnement dépourvu de CPU récent.
  • Une enquête détaillée via des tests de charge a montré que certaines fonctionnalités entraînaient un surcoût important sur certains matériels.
  • En découpant finement le temps de rendu et en implémentant un nouvel algorithme donnant la priorité au travail local, les performances ont pu être efficacement améliorées sur du matériel ancien.
• Amélioration des performances de FigJam
  • Écrire des tests était difficile, mais au lieu de corriger les problèmes uniquement après avoir consulté les demandes clients ou les métriques, il est désormais possible d’identifier les problèmes à l’avance grâce aux tests.
  • Même des problèmes difficiles à détecter, comme de subtiles différences de performance en CSS, ont pu être découverts et corrigés en répétant les tests des dizaines de fois.
  • Il a été particulièrement utile de pouvoir suivre précisément les modifications de code à l’origine des régressions de performance.
• L’amélioration des performances est un domaine délicat, mais comme ce que l’on imagine diffère souvent de la réalité, les tests et la mesure des performances sont essentiels.

[kuroneko]

• Fil HN

C’est bien qu’ils aient amélioré les performances grâce à des tests, mais... j’ai toujours l’impression que Figma est terriblement lent.
Dans les commentaires HN aussi, il y a pas mal de plaintes disant que c’est extrêmement lent. -_-

J’ai surtout l’impression que c’est devenu énormément plus lent depuis le rachat par Adobe (avant, c’était plus rapide que ce que je pensais...)
C’est peut-être juste une impression ?

[kuroneko]

Résumé IA du fil HN

• skhameneh : salue Evan Wallace, ancien CTO de Figma, pour son travail pionnier avec WebAssembly et pour avoir partagé son parcours d’exploration sur GitHub.
• imslavko : partage d’anciens billets de blog d’Evan et Jamie détaillant la transition de Figma vers WebAssembly, les tests de performance et les améliorations au fil du temps.
• fhub : mentionne qu’Evan Wallace a cofondé Figma en 2012 et a occupé le poste de CTO pendant dix ans avant de partir en 2021.
• antoineMoPa : exprime sa surprise que Figma ait réussi à atteindre à la fois le succès commercial et l’excellence technique, alors qu’on suppose souvent qu’une entreprise doit faire des compromis sur ce dernier point.
• tobyjsullivan : explique que Figma est une exception, alors que la plupart des startups privilégient les fonctionnalités à la qualité, et que seules quelques-unes parviennent à innover sur de nouvelles technologies puis à les commercialiser.
• tmpz22 : critique les attentes étroites envers le logiciel, façonnées par des produits récents, en affirmant que la norme actuelle devrait être la réussite du passage en intégration continue.
• yellow_lead : se demande comment d’autres gèrent des environnements de test de performance bruités, étant donné la marge d’erreur de 20 % chez Figma.
• imslavko : explique en détail le système de test reposant sur du matériel auxiliaire chez Figma et la manière de calculer des références de base pour corriger la variabilité des machines virtuelles.
• koenbok : partage l’expérience de Framer, confronté à une variabilité de 15 % malgré un Mac Mini de test dédié, et conclut que la surveillance des utilisateurs reste finalement la plus fiable.
• chrisdbanks : signale des problèmes de temps de chargement en Europe et des images qui ne se chargent pas rapidement, et se demande si Figma effectue des tests corrects en dehors des États-Unis.