Layout synchrone forcé : lire la géométrie après une écriture dans le DOM

Ce qui se passe

Normalement, la mise en page se produit après la fin de votre JavaScript, une fois par frame. Mais si vous modifiez le DOM puis lisez immédiatement une propriété de mise en page — offsetWidth, scrollHeight, getBoundingClientRect(), getComputedStyle() — le navigateur doit s'arrêter et calculer la mise en page sur place, de façon synchrone, dans votre tâche, car la réponse dépend de votre modification en attente.

Une mise en page forcée est peu coûteuse sur une petite page. Sur un grand DOM, ou répétée dans une boucle (ce qui devient du layout thrashing), elle ajoute des centaines de millisecondes au gestionnaire.

Comment le reconnaître

• Processing time long dans la décomposition de l'INP, avec des blocs Layout imbriqués dans la tâche de script dans DevTools Performance (avertissement « Forced reflow »).
• La Long Animation Frames API signale un forcedStyleAndLayoutDuration élevé pour votre script.
• Le gestionnaire à la fois mute le DOM et mesure des éléments.

Comment corriger

• Lisez toute la géométrie avant la première écriture DOM dans la tâche.
• Mettez en cache les mesures qui ne changent pas (tailles d'éléments, largeur du conteneur) au lieu de les relire à chaque événement.
• Si vous devez mesurer après un changement, différez la lecture au requestAnimationFrame du frame suivant, ou utilisez ResizeObserver / IntersectionObserver au lieu de sonder la géométrie.

Problème

grid.style.width = next + "px"            // write: layout is now dirty
const rect = cell.getBoundingClientRect()  // read → forced synchronous layout

Correctif

const rect = cell.getBoundingClientRect()  // read first, layout is clean
grid.style.width = next + "px"             // write after; browser lays out
                                           // once, before the next paint