Le thread principal du navigateur, une ressource coûteuse
Original : The Browser's Main Thread Is Expensive
Pourquoi c'est important
Optimiser le thread principal est crucial pour les interfaces riches en interactions temps réel.
Le thread principal du navigateur concentre JavaScript, le rendu, les événements et les callbacks réseau. Sur un écran à 60Hz, le budget disponible est d'environ 10 ms par frame. Dépasser ce seuil provoque des blocages visibles : scroll saccadé, inputs retardés.
Le thread principal du navigateur est une ressource unique qui supporte à la fois l'exécution de JavaScript (handlers d'événements, timers, callbacks réseau, internals des frameworks) et le pipeline de rendu graphique (calcul des styles, layout/reflow, paint). Seule la dernière étape de compositing est déléguée à un thread dédié.
Sur un écran 60Hz, chaque frame dispose d'environ 16,6 ms, mais le budget pratique se réduit à ~10 ms après déduction du coût interne du navigateur. Sur un écran 120Hz, ce budget est divisé par deux.
Lorsque ce thread est bloqué, les symptômes sont subtils mais perceptibles : scroll saccadé, bouton qui répond avec retard, lettres qui s'affichent en décalé dans un champ de recherche. L'article identifie plusieurs stratégies pour gérer cette ressource : le splitting (découper les tâches longues), le batching (regrouper les opérations), la priorisation, le différé (deferring), le transfert vers le compositor thread (animations CSS, transform/opacity), le recours aux Web Workers pour les calculs lourds, et enfin la suppression pure du travail inutile. L'auteur souligne que le problème n'est généralement pas la lenteur du code, mais le fait qu'il occupe le thread principal au mauvais moment.