L’histoire de la reconstruction de la stack technique de Facebook

Le parcours et les leçons tirées par Facebook, parti d’un simple PHP, pour passer à React + Relay (GraphQL) en l’adaptant à ce nouveau design

Application des principes de base d’une application rapide à chacun des volets CSS, JS, données et navigation

1. Transmettre uniquement les ressources nécessaires, le plus vite possible

2. Une expérience d’ingénierie au service de l’expérience utilisateur

CSS

• Réduction de 80 % du CSS avec l’Atomic CSS, et modification pour éviter de télécharger du CSS inutile

• Utilisation de rem pour l’accessibilité, avec conversion automatique px → rem dans l’outil de build afin de réduire les bugs liés à une conversion manuelle

• Utilisation de variables CSS pour le theming (mode sombre)

• Utilisation de SVG inline pour éviter le scintillement (au lieu de mettre un fichier SVG dans img). Cela permet aussi de changer les couleurs à l’exécution

JS

• Envoi du JS découpé en 3 niveaux de code-splitting, étape par étape

Tier 1. Layout de base pour afficher rapidement le squelette de l’interface au chargement

Tier 2. JS nécessaire pour rendre complètement tout le contenu visible à l’écran. L’application doit être entièrement utilisable, et même si du code se charge après le Tier 2, la composition de l’écran ne doit pas changer

Tier 3. Tout ce qui est nécessaire après l’affichage de l’écran : code de logging, abonnements aux mises à jour en temps réel, etc.

• 500 KB de JS répartis en 50 KB pour le Tier 1, 150 KB pour le Tier 2 et 300 KB pour le Tier 3 → effet très net sur la rapidité de chargement et d’affichage initial

• Grâce à ce découpage, il devient aussi possible, lors d’un test A/B, de configurer chaque variante pour ne recevoir que le code dont elle a besoin

• Utilisation des fonctions de Relay, qui aide à créer des applications React pilotées par les données, afin de ne charger que les composants nécessaires selon les données à récupérer

• Mise en place d’un système de budget JS par produit. Le budget est défini en fonction des objectifs de performance, des contraintes techniques et des considérations produit. Cela évite que le code n’augmente avec le temps.

Données

• Avec Relay, standardisation de tous les fetchs de données via GraphQL

• Grâce à Relay, téléchargement en parallèle dès l’étape de requête de page des données nécessaires en priorité, afin d’afficher l’écran plus rapidement

• Utilisation de @stream, une extension interne de GraphQL, pour envoyer progressivement les données d’éléments comme le fil d’actualité en une seule requête, sans multiples allers-retours

• @defer + React Suspense pour charger plus tard les données qui ne sont pas immédiatement nécessaires

Navigation

• Construction d’une Route Map pour réduire le temps de chargement des ressources et les allers-retours lors de la navigation SPA vers une nouvelle page

• Chargement fragmenté des informations de route dans la Route Map, aussi vite que possible au moment opportun

• Préfetch des ressources le plus tôt possible (préfetch au survol, récupération du code et des données au mouse down, puis changement d’état React au clic)

• Au lieu d’afficher un écran vide pendant la navigation, utilisation des transitions React Suspense pour continuer à afficher la route actuelle avant que la nouvelle route soit récupérée

• Utilisation des EntryPoints (petits fichiers encapsulant un point de branchement du code et une requête de données) pour paralléliser le téléchargement du code et des données

[xguru]

Ce que j’ai appris du CSS du nouveau design de Facebook : https://fr.news.hada.io/topic?id=1819

L’article mérite aussi d’être consulté.

[xguru]

Relay - Le client GraphQL prêt pour la production pour React https://relay.dev/