Layout síncrono forzado: leer geometría después de escribir en el DOM

Qué ocurre

Normalmente el layout ocurre después de que tu JavaScript termina, una vez por frame. Pero si cambias el DOM y de inmediato lees una propiedad de layout — offsetWidth, scrollHeight, getBoundingClientRect(), getComputedStyle() — el navegador debe detenerse y calcular el layout ahí mismo, de forma síncrona, dentro de tu tarea, porque la respuesta depende de tu cambio pendiente.

Un layout forzado es barato en una página pequeña. En un DOM grande, o repetido en un bucle (lo que se convierte en layout thrashing), añade cientos de milisegundos al manejador.

Cómo reconocerlo

• Processing time largo en el desglose de INP, con bloques de Layout anidados dentro de la tarea de script en DevTools Performance (aviso “Forced reflow”).
• La Long Animation Frames API informa un forcedStyleAndLayoutDuration grande para tu script.
• El manejador a la vez muta el DOM y mide elementos.

Cómo solucionarlo

• Lee toda la geometría antes de la primera escritura en el DOM dentro de la tarea.
• Cachea las medidas que no cambian (tamaños de elementos, ancho del contenedor) en lugar de releerlas en cada evento.
• Si debes medir después de un cambio, aplaza la lectura al requestAnimationFrame del siguiente frame, o usa ResizeObserver / IntersectionObserver en vez de sondear la geometría.

Problema

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

Solución

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