Quedan dos frentes de la línea base y este es el que domina la tabla: la fila 5 sigue en 310 ms por render y la fila 9 en 7.812 nodos, con el Bottom-Up de 09-01 señalando que 600 llamadas a pintarTarjeta cuestan 186 ms de tiempo propio y que hay 41 recálculos de estilo donde debería haber uno. Ese trabajo no es JavaScript lento —ya lo optimizaste en 09-02— ni memoria retenida —ya la liberaste en 09-03—: es el coste de hablar con el DOM. Esta lección explica por qué ese diálogo es caro: el pipeline de renderizado del navegador y qué operaciones despiertan cada una de sus fases; qué es exactamente un reflow y qué lo fuerza de forma síncrona, cerrando el aviso que quedó abierto en 06-02; cómo se reconoce y se elimina el layout thrashing, que es de donde salen esos 41 recálculos; cuánto aporta de verdad agrupar inserciones con DocumentFragment y replaceChildren (06-05) y actualizar con reconciliar en vez de redibujar (06-06), con una valoración honesta de cada cosa; por qué solo transform y opacity se animan gratis; qué hacen will-change, contain y content-visibility; y, por fin, la virtualización: pintar solo las filas que se ven, implementada dos veces —con IntersectionObserver y con una ventana calculada—, con sus contrapartidas reales sobre la mesa. Al terminar, las filas 5 y 9 estarán cerradas.

1. Por qué el DOM es caro
2. El pipeline de renderizado, fase a fase
3. Qué operación despierta qué fase
4. Reflow, repaint y el cálculo de estilo síncrono forzado
5. La lista negra: qué lecturas fuerzan un reflow
6. Layout thrashing: el bucle que alterna lectura y escritura
7. El patrón read-then-write, medido sobre las 600 tarjetas
8. Agrupar inserciones: DocumentFragment y replaceChildren
9. Actualizar en vez de redibujar: qué aporta de verdad reconciliar
10. Escribir solo lo que cambia
11. Animar barato: transform y opacity
12. Aislar el trabajo: will-change, contain y content-visibility
13. Sincronizar con requestAnimationFrame (y no con setTimeout)
14. Virtualización I: centinelas con IntersectionObserver
15. Virtualización II: la ventana calculada con altura fija
16. Las contrapartidas de virtualizar
17. Delegación de eventos, ahora con números
18. Las filas 5 y 9, cerradas
19. Síntoma → causa probable → solución
20. Errores Comunes y Consejos
21. Ejercicios
22. Conclusión

Hay una frase que se repite mucho y que, dicha así, es falsa: «el DOM es lento». El DOM no es lento; es otra cosa. Y confundir ambas ideas lleva a optimizaciones equivocadas.

Cuando escribes li.textContent = 'Rediseñar la sala polivalente' no estás asignando una propiedad de un objeto JavaScript. Estás cruzando una frontera: tu motor de JavaScript (V8) le está pidiendo algo al motor de renderizado (Blink), que mantiene su propia representación del documento en C++, con sus propios árboles de estilo y de diseño. Esa llamada tiene tres costes distintos que conviene separar:

La clave, y es la idea central de la lección, es que invalidar y recalcular están desacoplados. El navegador no recalcula nada cuando tú escribes: apunta que hay trabajo pendiente y sigue ejecutando tu código. Recalculará una sola vez, justo antes de pintar el siguiente fotograma, por muchas escrituras que hayas hecho. Es un mecanismo de agrupación automática, y es excelente.

Todo lo que hace lenta la manipulación del DOM consiste, en el fondo, en romper esa agrupación: obligar al navegador a recalcular en mitad de tu código, una y otra vez, cuando podría haberlo hecho una sola vez al final.

La diferencia entre los dos bucles es una sola línea. Entender por qué esa línea cuesta tanto exige mirar el pipeline.

Para convertir HTML, CSS y JavaScript en píxeles, el navegador ejecuta una secuencia fija de fases. Se llama pipeline de renderizado y se ejecuta, como mucho, una vez por fotograma.

Qué hace exactamente cada fase:

1 · JavaScript. Tu código se ejecuta y modifica el árbol del DOM, las clases, los estilos en línea o el contenido. También pueden desencadenar cambios el CSS (una animación, un :hover) o la Web Animations API, sin que haya JavaScript por medio.

2 · Estilo (Recalculate Style). El navegador decide, para cada elemento afectado, qué reglas CSS le aplican y cuál es el valor final de cada propiedad. El coste crece con el número de elementos invalidados y con la complejidad de los selectores. En DevTools aparece en morado.

3 · Layout (también reflow). Con los estilos ya resueltos, el navegador calcula la geometría: posición y tamaño de cada caja. Es la fase más cara porque es global por naturaleza: cambiar el ancho de un elemento puede desplazar a todos sus hermanos, a su padre y a media página. También en morado.

4 · Pintado (Paint). Se rellenan los píxeles: fondos, textos, bordes, sombras. No se dibuja directamente en pantalla, sino en una o varias capas (layers). En DevTools, verde.

5 · Composición (Composite). Las capas se apilan en el orden correcto y se envían a la pantalla. Esta fase la hace la GPU y es baratísima. También verde.

Y aquí está la observación que gobierna la mitad de las decisiones de esta lección: el pipeline se puede entrar por la mitad. No todos los cambios obligan a recorrer las cinco fases.

Cuantas menos fases entren en juego, más barato es el cambio. Esa es toda la teoría de la optimización visual, y de ella se derivan las reglas prácticas de los apartados 11 y 12.

Traducido a operaciones concretas de tu código, la tabla queda así. Vale la pena tenerla a mano.

Tres consecuencias que ya se pueden aplicar a Nómada Tareas hoy mismo:

• Cambiar el texto de una tarjeta es caro, porque el texto puede cambiar de ancho y eso es geometría. Actualizar .tarea__meta en 600 tarjetas cuando solo han cambiado dos es trabajo tirado.
• Construir fuera del árbol es gratis. Todo lo que hagas sobre un <li> recién creado y todavía no insertado no cuesta nada: ni estilo, ni layout, ni pintado. Es el argumento de fondo de DocumentFragment (06-05).
• display: none y visibility: hidden no son lo mismo. El primero saca el elemento del layout (y el cambio es caro, pero luego ese elemento deja de costar); el segundo lo mantiene ocupando sitio y solo evita el pintado.

Fijemos el vocabulario, porque se usa mal constantemente:

• Reflow (o layout): recalcular la geometría. Es la fase 3.
• Repaint: rellenar píxeles de nuevo sin recalcular geometría. Es la fase 4 sin la 3.
• Cálculo de estilo síncrono forzado (forced synchronous layout): que el navegador tenga que ejecutar las fases 2 y 3 en mitad de tu JavaScript, porque le has pedido un dato que solo puede darte si están al día.

El tercero es el que nos interesa. Vuelve al mecanismo del apartado 1: cuando escribes, el navegador solo invalida. Pero cuando lees una propiedad geométrica, el navegador tiene un contrato que cumplir: debe devolverte el valor correcto en ese instante. Si hay invalidaciones pendientes, no le queda otro remedio que detenerlo todo, recalcular estilo y diseño, y entonces responderte.

DevTools lo señala de forma explícita: en el diagrama de llamas aparece un bloque morado dentro de tu bloque amarillo, con un triángulo de aviso y el texto «Forced reflow is a likely performance bottleneck». Si lo ves, tienes un problema del apartado 6.

Un matiz importante que ahorra falsos diagnósticos: un recálculo forzado aislado no es un problema. Medir una vez la altura de una columna para colocar un menú cuesta unos 1–2 ms en el portátil de referencia con CPU 4×, y no lo vas a notar. El problema aparece cuando ese recálculo se ejecuta dentro de un bucle, porque cada vuelta invalida lo que la vuelta anterior acababa de calcular. Eso tiene nombre propio, y es el apartado 6.

Esta es la lista que cierra el aviso de 06-02. No hace falta memorizarla entera; hace falta reconocer la familia: todo lo que devuelve una medida, una posición o un estilo ya resuelto.

Tres avisos que casi nadie tiene presentes:

getComputedStyle es peor de lo que parece. No fuerza el reflow al llamarlo, sino al leer una propiedad del objeto devuelto, y fuerza tanto el recálculo de estilo como el de diseño si la propiedad depende de la geometría. Peor aún: en la práctica es imposible predecir qué propiedades lo necesitan, así que la regla segura es tratarlo entero como una lectura cara.

focus() es una lectura disfrazada de escritura. El navegador necesita saber si el elemento es visible y dónde está para poder desplazar hasta él. En 06-06 se restauraba el foco tras el render; si eso ocurre en mitad de un bucle de escrituras, tienes un recálculo forzado por vuelta.

textContent no fuerza; innerText sí. innerText devuelve el texto tal como se ve, así que necesita saber qué está oculto por CSS: eso es estilo, y a veces diseño. textContent devuelve el texto del árbol y no consulta nada. Es un motivo más, además de los de 06-02, para usar textContent por defecto.

Ya tenemos el mecanismo. Vamos al caso real de Nómada Tareas, que es de donde salen los 41 recálculos de estilo y los 38 layout del Bottom-Up de 09-01.

En el tablero de 600 tareas hay 40 vencidas. La tarjeta de una tarea vencida lleva una insignia con el texto «vencida hace N días», y si el título es largo la insignia se sale de la caja. La solución que se puso en su día fue medir el título y, si no cabía, reducir la tarjeta a una línea. Este es el código, tal cual, en la TableroVista de 09-03:

Míralo con el modelo del apartado 4. Vuelta 1: se lee offsetHeight, el navegador recalcula (no hay nada pendiente la primera vez, así que es barato) y responde. Después se escribe una variable CSS y se cambia una clase: invalidado. Vuelta 2: se lee offsetHeight otra vez, pero ahora sí hay trabajo pendiente, así que el navegador tiene que recalcular estilo y diseño de todo el subárbol invalidado antes de responder. Y así cuarenta veces.

Cuarenta lecturas forzadas, más una del scrollTop que se guarda para conservar el desplazamiento (06-06): 41 recálculos de estilo. Y 38 layout, tres menos porque en tres vueltas la escritura anterior no llegó a invalidar la geometría. Los números del Bottom-Up encajan exactamente:

Casi la mitad del render se va en cuarenta lecturas de offsetHeight. Y lo más importante: no es un problema de cuánto código ejecutas, sino de en qué orden lo ejecutas. La misma cantidad de trabajo, reordenada, cuesta una fracción.

Este es el patrón que en 06-02 se llamó layout thrashing y se remitió aquí. Ya sabes reconocerlo: una lectura de la lista negra del apartado 5 dentro de un bucle que también escribe.

La solución no es leer menos ni escribir menos: es separar las dos fases. Primero todas las lecturas, después todas las escrituras. El navegador recalcula una vez al principio del bloque de lecturas y una vez, por su cuenta, antes de pintar.

El cambio es puramente estructural: mismas lecturas, mismas escrituras, mismo resultado visual. La medición, con banco() de 09-01 (5 de calentamiento, 15 repeticiones, CPU 4×, 600 tareas de las cuales 40 vencidas):

Treinta y tres veces más rápido sin cambiar una sola operación. Y el efecto sobre la fila 5:

De 310 a 179 ms con una reordenación. Es, con diferencia, la mejor relación entre beneficio y esfuerzo de toda la lección.

Una advertencia honesta sobre este patrón: es frágil. Nada impide que dentro de seis meses alguien meta una lectura en la fase de escritura, y el rendimiento se desplomará sin que ninguna prueba falle. Hay tres defensas razonables:

Primera: un comentario que explique la razón, no lo que hace el código. // FASE 1 · LEER. Ninguna escritura aquí dentro. es exactamente eso.

Segunda: encapsular el patrón para que la separación no dependa de la disciplina de quien edite.

Tercera: una prueba que cuente los recálculos. No se puede contar directamente desde Jest con jsdom (que no hace layout), pero sí desde Cypress o Puppeteer, observando las entradas de rendimiento del navegador. Es materia del apartado 20, en los consejos.

En 06-05 aprendiste DocumentFragment con una promesa: «la medición seria es el tema de 09-04». Toca cumplirla, y la respuesta va a ser menos espectacular de lo que la mayoría de los tutoriales sugiere.

El argumento clásico es que insertar 600 elementos uno a uno provoca 600 reflows. Eso era cierto en 2008 y hoy es falso, por el mecanismo del apartado 1: el navegador invalida y agrupa. Midámoslo, con las tres variantes, sobre el pintado inicial de las 600 tarjetas:

Léelo con cuidado, porque las conclusiones son dos y van en direcciones distintas.

El fragmento aporta un 9 %. Real, medible y gratis, pero no es lo que arregla nada. Los navegadores modernos ya agrupan el trabajo de diseño, así que la diferencia entre 600 inserciones y una se reduce al coste de las propias llamadas y a algunas invalidaciones que se pueden fusionar mejor. Nueve por ciento no es despreciable, pero quien crea que DocumentFragment es «la» optimización del DOM está mirando al sitio equivocado.

La lectura en el bucle multiplica por dieciséis. La variante D es el mismo trabajo con una línea de más, y cuesta 2,1 segundos. Ahí está el orden de magnitud, y es el mismo del apartado 6: el enemigo no es tocar el DOM muchas veces, es intercalar lecturas.

Dicho todo esto, sigue habiendo dos motivos sólidos para usar replaceChildren(...):

• Legibilidad. Una línea que dice «el contenido de esta lista es exactamente esto» se lee mejor que un bucle con un append.
• Atomicidad visual. Vaciar y rellenar en dos operaciones separadas puede dejar, en casos raros con trabajo asíncrono en medio, un fotograma con la lista vacía. replaceChildren no.

Y un tercer motivo que sí es de rendimiento puro, aunque menos conocido: cuando el contenedor está fuera del árbol o dentro de un content-visibility: hidden (apartado 12), todo el trabajo de construcción es gratis, y ahí el fragmento sí es la herramienta natural.

En 06-06 construiste reconciliar(contenedor, datos, clave, pintar), que reutiliza los nodos existentes en lugar de destruirlos y recrearlos. Se justificó por corrección: conservar el foco, el desplazamiento y las transiciones. Ahora toca la pregunta de rendimiento: ¿cuánto ahorra?

La respuesta honesta es: depende enteramente de cuánto cambie, y la variabilidad es enorme.

Medición sobre las 600 tareas, comparando replaceChildren(...) (recrear todo) con reconciliar (reutilizar), en cuatro escenarios reales de Nómada Tareas:

Fíjate en la última fila: reconciliar puede ser más lento. Cuando cambia el orden de todos los elementos, la implementación sencilla de 06-06 hace un insertBefore por cada nodo —600 movimientos en el árbol vivo— más 600 actualizaciones de contenido, y eso cuesta más que construir la lista entera de cero fuera del árbol. Es exactamente el límite que 06-06 anunció: «no detecta movimientos de forma óptima».

La conclusión práctica no es «no uses reconciliar», sino algo más matizado:

reconciliar gana por goleada en el caso frecuente —cambios pequeños sobre una lista estable— y pierde en el caso raro de una reordenación completa. Como el caso frecuente es el que domina la experiencia percibida, sigue siendo la elección correcta. Y el caso raro deja de importar en cuanto solo haya 48 nodos en pantalla, que es lo que consigue la virtualización del apartado 15.

Ese último matiz es importante: las optimizaciones interactúan. Con virtualización, la reordenación completa afecta a 48 tarjetas en lugar de a 600, y la fila mala de la tabla desaparece sola.

Volvamos a la entrada que encabeza el Bottom-Up: pintarTarjeta, 600 llamadas, 186 ms de tiempo propio. Ya no queda thrashing, así que ese tiempo es trabajo real. ¿En qué se va?

Mira la función de 06-06 con ojos de rendimiento. Por cada tarjeta hace, sin condiciones:

• 4 escrituras en dataset
• 1 classList.remove(...) con tres clases y 3 classList.add/toggle
• 3 asignaciones de textContent
• 1 replaceChildren de la lista de etiquetas, que destruye y recrea los <li> de etiqueta
• 2 escrituras de disabled y 2 setAttribute('aria-label', ...)

Son 16 escrituras por tarjeta, 9.600 en total, para actualizar una lista en la que normalmente no ha cambiado nada. Y aunque el navegador agrupe, cada escritura invalida algo, y cada invalidación amplía el subárbol que habrá que recalcular después.

La corrección es la más aburrida y la más eficaz de la lección: comprobar antes de escribir.

Y pintarTarjeta reescrita con ellas, más una salida temprana que es la que de verdad manda:

Tres comentarios sobre este código:

• La huella es la clave. Es una cadena barata de construir (unos 0,004 ms) que resume todo lo que se ve. Compararla cuesta una fracción de lo que cuesta escribir dieciséis propiedades. Es, conceptualmente, la misma idea que el contador de versión de 09-02: una forma barata de saber si hace falta trabajar.
• disabled se asigna sin comprobar a propósito: asignar una propiedad booleana que ya tiene ese valor no invalida nada en los motores actuales, y la comprobación costaría más que el ahorro. La regla es proteger lo que invalida —texto, atributos, dataset con selectores CSS asociados—, no todo por sistema.
• classList.add de una clase ya presente tampoco invalida. classList es un DOMTokenList y comprueba la pertenencia antes de modificar. Esa es la razón de que en 06-02 se insistiera en usar classList en lugar de machacar className: además de más legible, es más barato.

Medición sobre el render completo, tras aplicar el apartado 7:

Y una fila que no está en la línea base pero que es la que más se nota en el uso diario: el render tras un cambio de una sola tarea pasa de 3,1 ms a 0,8 ms, porque 599 tarjetas salen por la puerta temprana.

Cambiemos de terreno. Hasta aquí hemos hablado de actualizar contenido; ahora, de moverlo. Nómada Tareas anima la entrada de una tarjeta nueva y el deslizamiento de una tarjeta al cambiar de columna. Así estaba hecha la entrada:

Cada fotograma de esa animación cambia height y margin-top, que están en la fila roja de la tabla del apartado 3: estilo, layout, pintado y composición. Y como el <li> está en un contenedor con display: grid, ese layout no afecta solo a la tarjeta: recoloca toda la columna.

La versión correcta expresa el mismo efecto visual con las dos únicas propiedades que la GPU puede animar por su cuenta:

La tabla de referencia, ampliando la del apartado 3 con las propiedades que más se animan:

Medición: animar la entrada simultánea de 24 tarjetas (lo que ocurre al quitar un filtro), grabando con el carril Frames de DevTools y CPU 4×:

La explicación de por qué la segunda sale gratis merece un párrafo. Cuando una animación afecta solo a transform y opacity, el navegador puede promover el elemento a su propia capa de composición: lo pinta una vez, y en cada fotograma se limita a decirle a la GPU «esta capa, desplazada 8 píxeles y con opacidad 0,7». No hay estilo que recalcular, no hay geometría que rehacer, no hay píxeles que rellenar. El hilo principal ni se entera: la animación sigue funcionando aunque tu JavaScript esté ocupado.

De ahí una consecuencia práctica que sorprende: una animación CSS bien hecha sobrevive a una tarea larga de JavaScript; una hecha con requestAnimationFrame, no. Si puedes expresar el efecto en CSS o con la Web Animations API (elemento.animate(...), de 07-06), hazlo, y reserva requestAnimationFrame para lo que exige cálculo por fotograma.

Y el truco que resuelve el 90 % de los casos en los que «necesito animar la posición y no puedo usar transform»: la técnica FLIP (First, Last, Invert, Play). Se mide la posición inicial, se aplica el cambio de golpe, se mide la final, y se anima con transform desde la diferencia hasta cero.

Ojo con una cosa: flip hace dos lecturas de geometría. Está bien para un nodo, y es exactamente el error del apartado 6 si lo llamas dentro de un bucle sobre 600 tarjetas. Para animar varias, primero se leen todas las posiciones iniciales, luego se aplica el cambio, luego se leen todas las finales, y solo entonces se anima. Read-then-write otra vez.

Estas tres propiedades CSS son herramientas de rendimiento puro: no cambian el aspecto de nada, sino cuánto trabajo puede ahorrarse el navegador.

Le avisa al navegador de que una propiedad va a cambiar pronto, para que prepare lo necesario —típicamente, promover el elemento a su propia capa— antes de que empiece la animación y no en el primer fotograma.

Y ahora las tres reglas que hacen que will-change ayude en lugar de perjudicar:

1. Úsalo con moderación extrema. Cada capa consume memoria de GPU. Poner will-change: transform en las 600 tarjetas puede consumir cientos de megabytes de vídeo y hacer la aplicación más lenta. Es el mal uso más frecuente.
2. Ponlo y quítalo. Lo correcto es añadirlo justo antes (con una clase, o al hacer :hover sobre el ancestro) y retirarlo al acabar. Dejarlo permanentemente en el CSS es exactamente lo que no hay que hacer.
3. No lo uses para «arreglar» animaciones lentas. Si tu animación toca height, will-change: height no la va a salvar: el problema es la propiedad, no la preparación.

Le promete al navegador que lo que pase dentro de un elemento no afecta a lo de fuera. Con esa promesa, el navegador puede limitar el alcance de un recálculo al subárbol en lugar de propagarlo a toda la página.

Con esto, actualizar el .tarea__meta de una tarjeta ya no puede desplazar a las 599 restantes, y el navegador lo sabe de antemano. En la medición del render tras un cambio de una tarea, contain: layout paint baja el Layout de 1,9 ms a 0,3 ms.

El aviso: contain: size es peligroso si no le das dimensiones al elemento, porque entonces el navegador lo tratará como si midiera cero y la tarjeta desaparecerá. Es el error clásico con esta propiedad.

Es la más potente de las tres y la que más se acerca a la virtualización sin escribir JavaScript. content-visibility: auto le dice al navegador: «si este elemento no está cerca del área visible, no hagas su estilo, su layout ni su pintado».

contain-intrinsic-size es obligatorio en la práctica: sin él, el navegador trata el elemento omitido como si midiera 0 px de alto, y la barra de desplazamiento salta y se encoge de forma grotesca a medida que desplazas. Con la palabra clave auto, el navegador recuerda el tamaño real una vez lo ha calculado y usa ese valor a partir de entonces, lo que elimina casi por completo el salto.

Medición sobre el render completo:

Dos lecturas, y la segunda es la importante.

Es un ahorro enorme por dos líneas de CSS. De 142 a 78 ms sin tocar JavaScript, sin romper nada, sin contrapartidas de accesibilidad. Si solo pudieras aplicar una técnica de esta lección, sería esta.

Pero no cierra la fila 9. Los 7.812 nodos siguen ahí: content-visibility evita trabajar con ellos, no los elimina. Y los nodos cuestan memoria (unos 2,4 MB en el montículo, medido con el panel Memory de 09-03), coste de recolección, y coste en cada querySelectorAll que los recorra. Para bajar de 7.812 a 1.500 hay que no crearlos, y eso ya es virtualización.

Comparación honesta de las tres, para tenerlas claras:

En 07-06 usaste requestAnimationFrame para animar. Aquí interesa por otro motivo: es el momento correcto para hacer trabajo visual, y usar setTimeout en su lugar produce dos defectos distintos.

requestAnimationFrame(callback) programa el callback para que se ejecute justo antes del siguiente pintado. Eso significa tres garantías que setTimeout no da:

El defecto más sutil de setTimeout para trabajo visual se llama fotograma doble: si tu callback se ejecuta a mitad de camino entre dos pintados, el navegador puede pintar el mismo estado dos veces y saltarse el siguiente cambio, produciendo el tirón característico de las animaciones hechas con temporizadores.

En Nómada Tareas hay un caso donde esto importa de verdad: el manejador de scroll que decide qué tarjetas hay que pintar en la ventana virtual del apartado 15. Con throttle(fn, 100) de 09-02 el desplazamiento va a saltos; con requestAnimationFrame, va suave. El patrón correcto es el llamado rAF coalescido:

Medición del desplazamiento de la columna de pendientes con 600 tareas, 5 segundos de scroll continuo, CPU 4×:

Fíjate en que porFotograma ejecuta más veces que el throttle de 100 ms y aun así pierde doce veces menos fotogramas. No es cuestión de ejecutar poco: es cuestión de ejecutar en el momento correcto.

Y la regla que resume el apartado, con su matiz:

requestAnimationFrame para trabajo visual, setTimeout/debounce para trabajo no visual. Filtrar el tablero al escribir es no visual (el resultado es un cálculo): debounce. Recolocar la ventana virtual al desplazar es visual: requestAnimationFrame.

Llegamos al asunto de fondo. Con 600 tareas hay 7.812 nodos en el documento, y en pantalla caben seis tarjetas por columna. Estamos manteniendo casi ocho mil nodos para mostrar dieciocho.

Virtualizar es pintar solo lo que se ve (más un pequeño margen) y fingir el resto. Hay dos familias de implementación, y conviene ver las dos porque resuelven problemas distintos.

La primera, más sencilla, es el desplazamiento infinito con centinela: se pintan las primeras N tarjetas y, cuando el usuario llega al final, se pintan otras N. Se implementa con el IntersectionObserver de 07-06, que avisa cuando un elemento entra en el área visible sin necesidad de escuchar scroll.

Cuatro detalles del código que merecen atención:

• rootMargin: '400px' hace que el centinela «entre» cuatrocientos píxeles antes de ser visible. Sin ese margen, el usuario ve el hueco vacío durante un instante. Es el mismo truco de precarga de 07-06.
• El centinela va al final y se inserta antes de él, no después: así siempre queda el último y el observador puede seguir usándolo.
• unobserve + remove al agotar los datos evita que el observador siga vivo sin motivo, y evita el nodo desprendido de 09-03.
• destruir() con disconnect() es obligatorio: un IntersectionObserver observando un nodo lo mantiene alcanzable.

Medición del pintado inicial con esta técnica:

La primera fila es excelente: la percepción mejora radicalmente porque las primeras tarjetas aparecen casi de inmediato. Pero mira la tercera: los nodos se acumulan. La lista progresiva reduce el coste inicial, no el coste sostenido. Para Marta, que se pasa la mañana desplazándose por el tablero, acabaremos otra vez en 7.812 nodos.

La fila 9 pide otra cosa.

La virtualización de verdad mantiene en el DOM solo los elementos de la ventana visible, creando los que entran y eliminando los que salen. El número de nodos se vuelve constante, independiente del tamaño de la lista.

La idea, cuando todas las filas miden lo mismo, es puramente aritmética:

Los dos espaciadores son la pieza clave: un <li> vacío arriba y otro abajo, con la altura exacta que ocuparían las tarjetas que no se han pintado. Gracias a ellos, la barra de desplazamiento tiene el tamaño correcto y la posición dentro de la lista es fiel, aunque solo existan dieciséis tarjetas.

Y el CSS que hace posible la aritmética:

Y el cableado en la vista, sustituyendo la llamada a reconciliar:

La medición, y aquí es donde se cierra la lección:

Los 1.194 nodos salen de una cuenta que conviene entender: 612 nodos de la carcasa de la página (cabecera, filtros, formulario, resumen, plantillas, las tres columnas con sus títulos y contadores) + 48 tarjetas × 12 nodos cada una = 576 + 6 espaciadores. Total, 1.194. La fila 9 pedía ≤ 1.500.

Y una propiedad que es la más valiosa de todas: ese número ya no depende del tamaño del tablero. Con 6.000 tareas serían los mismos 1.194 nodos y los mismos 31 ms. La virtualización no hace la aplicación un 20 % más rápida: cambia su complejidad de O(n) a O(1) en el número de elementos pintados, que es justo la clase de cambio que 09-02 identificó como la única que importa de verdad.

Sería deshonesto terminar el apartado anterior sin la letra pequeña. Virtualizar rompe cosas, y hay que saber cuáles y cómo se mitigan.

Las dos primeras merecen desarrollo, porque son las que más se subestiman.

Accesibilidad. Una lista virtualizada mal hecha es una regresión de accesibilidad seria. El mínimo imprescindible:

Con eso, un lector de pantalla anuncia «tarea 137 de 600» aunque en el DOM solo haya dieciséis. Y los espaciadores llevan aria-hidden="true" para que no se anuncien como elementos vacíos de la lista.

La alternativa más barata. Antes de virtualizar, pregúntate si content-visibility: auto te basta. La comparación completa:

Regla de decisión: usa content-visibility: auto por defecto; virtualiza solo cuando el número de nodos sea el problema, no el tiempo de pintado. En Nómada Tareas virtualizamos porque la fila 9 de la línea base lo exige explícitamente y porque el tablero seguirá creciendo. Si la línea base solo hubiera pedido bajar de 310 a 50 ms, content-visibility más los apartados 7 y 10 casi habrían bastado, con una décima parte del código.

Y ya que estamos siendo honestos: la implementación de ListaVirtual de arriba es deliberadamente sencilla. No soporta alturas variables, no maneja el desplazamiento suave hacia un elemento concreto, no repone el foco al salir y volver a entrar en la ventana. Cada una de esas cosas es un buen rato de trabajo. Es exactamente el tipo de problema que en el Módulo 10 verás resuelto de fábrica.

En 06-04 aprendiste delegación y se justificó por elegancia: un manejador en el contenedor que averigua el origen con closest('[data-accion]'). En 09-03 se justificó por memoria: un closure en lugar de 600. Falta la justificación de tiempo, y con la virtualización del apartado anterior se vuelve estructural.

Medición del pintado inicial de 600 tarjetas con tres acciones cada una:

La penúltima fila es la razón profunda por la que la delegación no es opcional cuando hay virtualización: las tarjetas entran y salen del DOM constantemente al desplazarse. Con manejadores individuales habría que registrar y retirar oyentes en cada fotograma de scroll, lo que sería tan absurdo como suena.

Y sobre la última fila: sí, cada clic delegado cuesta siete veces más que uno directo. Son doce microsegundos, ocurren una vez cada varios segundos, y a cambio ahorras 38 ms en el arranque y una familia entera de fugas. Es exactamente el tipo de comparación que 09-02 enseñó a hacer: comparar magnitudes absolutas, no factores.

Un último apunte técnico. Con la lista virtualizada, el manejador delegado sigue funcionando sin cambios porque closest sube por el árbol y el contenedor .tablero nunca se destruye:

Que una técnica elegida por claridad siga siendo correcta tras tres lecciones de optimización no es casualidad: es la misma observación de 09-02 sobre class Tarea. Las decisiones de diseño buenas suelen resultar también las rápidas.

Recapitulemos el camino completo, porque la suma es lo que da la medida real de la lección.

Y las filas de la línea base que quedan cerradas:

La fila 2 mejora de propina: el debounce de 09-02 había dejado el INP en 96 ms, de los cuales 78 eran el render. Con el render en 31 ms, la interacción completa —tecla, filtrado, render, pintado— baja a 42 ms, muy por debajo del umbral de los 100 ms de respuesta instantánea de 09-01.

Y dos cifras de contexto que no están en la tabla pero que importan:

• La memoria del montículo baja de 12,8 MB a 6,1 MB, porque 6.618 nodos que ya no existen no ocupan nada. Otra vez el efecto de 09-03: arreglar una cosa mejora otra.
• Todo esto es independiente del tamaño del tablero. Con 6.000 tareas, render() sigue costando 31 ms y el documento sigue teniendo 1.194 nodos. Lo único que crece es el filtrado y el ordenado, que son O(n) y O(n log n) sobre datos en memoria: unos 8 ms con 6.000 tareas.

Esta tabla es el resumen operativo de la lección. Cuando algo vaya mal en el DOM, empieza por aquí.

• Creer que «el DOM es lento». El DOM no es lento: recalcular estilo y diseño lo es, y solo cuando lo fuerzas fuera de tiempo. Cruzar la frontera JS↔DOM cuesta nanosegundos.
• Leer geometría dentro de un bucle que escribe. Es el error de la lección. Cuarenta lecturas de offsetHeight cuestan 137 ms; las mismas cuarenta, agrupadas, cuestan 4,3 ms.
• No reconocer getComputedStyle como lectura cara. Es la más traicionera de la lista negra, porque no parece una medida.
• Usar innerText por costumbre. Fuerza recálculo; textContent no. Salvo que necesites específicamente el texto visible, usa textContent.
• Llamar a focus() en mitad de un bucle de escrituras. Es una lectura disfrazada: fuerza el diseño para saber dónde está el elemento.
• Creer que DocumentFragment es la gran optimización. Aporta un 9 %. Lo que aporta un 1.600 % es no leer geometría en el bucle.
• Escribir siempre, sin comprobar. Asignar el mismo textContent que ya había invalida igual. Una huella barata evita 9.600 escrituras por render.
• Animar top, left, width o height. Cada fotograma pasa por layout. Usa transform y opacity, y FLIP cuando el cambio sea de posición real.
• Poner will-change en todo por si acaso. Cada elemento promovido consume memoria de GPU. Actívalo justo antes y retíralo al acabar.
• Usar contain: size sin dar dimensiones. El elemento se trata como de tamaño cero y desaparece.
• Usar content-visibility: auto sin contain-intrinsic-size. La barra de desplazamiento se vuelve loca. Con auto Xpx, el navegador recuerda el tamaño real.
• Usar setTimeout para trabajo visual. No se sincroniza con la pantalla, sigue corriendo en pestañas ocultas y produce fotogramas dobles. requestAnimationFrame.
• Usar throttle(fn, 100) en scroll. Mejor que nada, peor que requestAnimationFrame: ejecuta menos veces y pierde más fotogramas.
• Olvidar { passive: true } en scroll, wheel y touchstart. El navegador tiene que esperar a ver si llamas a preventDefault.
• Virtualizar sin arreglar la accesibilidad. Sin aria-setsize y aria-posinset, una lista de 600 se anuncia como de 16. Es una regresión seria.
• Virtualizar cuando bastaba content-visibility. Dos líneas de CSS frente a noventa de JavaScript con un modo de fallo nuevo. Mide antes de decidir.
• Virtualizar con alturas variables sin medirlas. La aritmética supone filas iguales; si no lo son, la barra de desplazamiento miente.
• Consejo: mide el número de nodos, no solo el tiempo. document.getElementsByTagName('*').length en la consola, o la curva Nodes del panel Performance. Es un indicador temprano que el tiempo no da.
• Consejo: busca el triángulo de aviso en el diagrama de llamas. DevTools te dice literalmente dónde está el recálculo forzado, con la pila de llamadas que lo provocó.
• Consejo: usa el panel Rendering de DevTools. Paint flashing colorea en verde lo que se repinta —si parpadea toda la pantalla al cambiar una tarjeta, tienes un problema de aislamiento—, y Layout Shift Regions señala los saltos de contenido, que serán protagonistas en 09-05.
• Consejo: escribe una prueba que cuente escrituras. En Jest con jsdom no hay layout, pero sí puedes espiar Element.prototype.setAttribute y afirmar que un render sin cambios no escribe nada. Es barata y protege el apartado 10.
• Consejo: los espaciadores de la lista virtual deben llevar aria-hidden="true". Si no, se anuncian como elementos vacíos de la lista.

Ejercicio 1 — Cazar el thrashing. Este código coloca una barra de progreso en cada columna del tablero, proporcional a las horas abiertas. Con las tres columnas y 600 tareas tarda 96 ms, y DevTools marca el aviso de recálculo forzado.

Responde: (1) qué líneas son lecturas de la lista negra y cuáles escrituras; (2) cuántos recálculos forzados provoca con tres columnas y por qué; (3) reescríbelo con read-then-write; (4) estima la mejora sabiendo que un recálculo forzado sobre este árbol cuesta unos 11 ms; y (5) señala una segunda mejora, independiente del orden, que reduzca todavía más el coste.

Ejercicio 2 — ¿content-visibility o virtualización? Para cada una de estas cuatro pantallas de Nómada Tareas, decide entre «no hacer nada», «content-visibility: auto» y «virtualizar», justificando con las contrapartidas del apartado 16.

1. El tablero canónico de Taller Nómada: 6 tareas en tres columnas.
2. El historial de cambios: 4.200 líneas de texto de una sola altura, que Marta consulta con Ctrl+F constantemente.
3. La vista de impresión del informe trimestral: 600 filas que hay que enviar a la impresora de una vez.
4. El selector de etiquetas: 6 elementos con altura variable según la longitud del nombre.

Ejercicio 3 — Animar el cambio de columna. Cuando Iván pulsa «Empezar», la tarjeta salta de la columna «Pendientes» a «En curso» sin transición. Escribe la animación correcta: (a) explica por qué no se puede resolver con una animación CSS de top y left; (b) implementa el movimiento con la función flip del apartado 11, integrada en el flujo estado → render → evento de 06-06; (c) indica cómo evitar el layout thrashing si cambian varias tarjetas a la vez; y (d) añade el respeto a prefers-reduced-motion y explica por qué la animación debe seguir funcionando aunque el hilo principal esté ocupado.

Solución 1

(1) Clasificación de las líneas:

(2) Recálculos forzados. Por cada vuelta hay dos bloques lectura→escritura→lectura: (a)(b) leen, (c)(d) invalidan, (e) vuelve a leer —forzado—, (f) invalida otra vez. En la siguiente vuelta, (a) lee con invalidaciones pendientes —forzado— y (b) puede aprovechar el recálculo recién hecho. Con tres columnas: la primera vuelta hace 1 recálculo natural + 1 forzado en (e); las vueltas 2 y 3 hacen 2 forzados cada una. Total: 5 recálculos forzados y unos 55 ms solo en eso. La estructura es la del apartado 6: el bucle alterna.

(3) Reescritura:

El cambio clave, más allá de separar fases, es que la línea (e) desaparece: la posición inferior de la barra se deduce de la altura ya medida en lugar de volver a preguntarla al DOM. La mejor lectura de geometría es la que no se hace.

(4) Mejora estimada. De 5 recálculos forzados a 1: se ahorran 4 × 11 ms = 44 ms, y el tiempo total pasa de 96 ms a unos 52 ms. Medido en el portátil de referencia con CPU 4×, el resultado real fue 96 → 49 ms, algo mejor de lo estimado porque el recálculo restante trabaja sobre un árbol menos invalidado.

(5) Segunda mejora, independiente del orden. Sustituir el estilo en línea por variables CSS y dejar que el CSS haga el cálculo. Así se escribe una sola propiedad personalizada por columna y el navegador resuelve anchos y posiciones sin que el JavaScript mida nada:

Con esto no queda ninguna lectura de geometría, y el coste cae a 1,2 ms. Es la lección de fondo de 06-02 llevada al extremo: deja que el CSS haga la geometría.

Solución 2

La regla que atraviesa las cuatro respuestas: la técnica correcta depende de cómo se usa la pantalla, no de cuántos elementos tiene. Las 4.200 líneas del historial y las 600 filas del informe tienen problemas de tamaño parecidos y soluciones opuestas, porque en una manda Ctrl+F y en la otra manda la impresora.

Solución 3

(a) Por qué no vale animar top y left. Dos motivos, y el segundo es el que impide la solución:

1. Ambas están en la fila roja del apartado 11: cada fotograma pasa por estilo, layout, pintado y composición. Con 24 tarjetas moviéndose se pierden 38 de 58 fotogramas.
2. Y sobre todo: la tarjeta no se mueve dentro de un contenedor, cambia de contenedor. Pasa de <ul> de «Pendientes» al <ul> de «En curso». Una animación CSS no puede interpolar entre dos posiciones en árboles distintos, porque el cambio de padre es instantáneo y el estado inicial deja de existir. Por eso hace falta FLIP: medir antes, aplicar el cambio real, medir después, y animar la diferencia con transform.

(b) Implementación integrada en el flujo de 06-06:

Esto funciona porque la reconciliación por data-id de 06-06 reutiliza el mismo nodo: insertBefore lo mueve al nuevo <ul> en lugar de destruirlo y crear otro (06-05). Si el render recreara la tarjeta, el nodo medido en la fase «First» ya no existiría y FLIP no tendría nada que animar. Es un caso precioso en el que una decisión de corrección tomada tres módulos antes hace posible una optimización visual.

(c) Varias tarjetas a la vez. El error sería llamar a flip en un bucle: cada llamada hace dos getBoundingClientRect, así que veinticuatro tarjetas serían 48 lecturas alternadas con 24 cambios de layout. La versión correcta agrupa las tres fases:

Dos recálculos forzados en total, en lugar de 48. Es el patrón del apartado 7 aplicado a animación.

(d) prefers-reduced-motion y por qué la animación sobrevive al hilo ocupado:

Respetar prefers-reduced-motion (07-06) no es un detalle estético: para las personas con trastornos vestibulares, el movimiento en pantalla puede provocar mareo real. La animación debe desaparecer, no ralentizarse.

Y la razón por la que esta animación sobrevive a un hilo principal ocupado es la del apartado 11: element.animate() con transform y opacity se ejecuta en el hilo de composición, no en el principal. Una vez lanzada, si tu JavaScript se queda 300 ms haciendo algo, la animación sigue a 60 fps. Con requestAnimationFrame no: cada fotograma depende de que el hilo principal esté libre, así que la animación se congelaría. Es un argumento decisivo para preferir CSS o la Web Animations API siempre que el efecto se pueda expresar de forma declarativa.

Las dos filas que dominaban la tabla están cerradas. render() ha pasado de 310 ms a 31 ms y el documento de 7.812 nodos a 1.194, con el INP del buscador bajando de propina de 96 a 42 ms y el montículo de 12,8 a 6,1 MB. Y lo más valioso: esas cifras ya no dependen del tamaño del tablero.

Entiendes por qué el DOM es caro, que no es por lo que casi todo el mundo cree. Cruzar la frontera entre JavaScript y el motor de renderizado cuesta nanosegundos; lo que cuesta milisegundos es recalcular, y el navegador ya evita recalcular de más agrupando todas tus escrituras hasta justo antes del siguiente fotograma. Conoces el pipeline de renderizado —JavaScript, estilo, layout, pintado, composición— y sabes que se puede entrar por la mitad: cambiar width recorre las cinco fases, cambiar background-color se salta el layout, y cambiar transform u opacity se salta también el pintado y lo resuelve la GPU sola.

Sabes qué es un cálculo de estilo síncrono forzado y tienes la lista negra que lo provoca —offsetHeight y familia, clientWidth, scrollTop, getBoundingClientRect, getComputedStyle, innerText, focus(), scrollIntoView()—, con lo que queda cerrado el aviso que 06-02 dejó abierto. Y reconoces el layout thrashing a simple vista: una de esas lecturas dentro de un bucle que además escribe. En Nómada Tareas eran cuarenta lecturas de offsetHeight sobre las tarjetas vencidas —los 41 recálculos de estilo y 38 layout del Bottom-Up de 09-01— y costaban 137 ms de los 310. El patrón read-then-write los redujo a uno solo y el render a 179 ms, sin cambiar ni una operación: solo el orden.

Tienes las magnitudes reales de cada técnica, que es lo que evita perder el tiempo en la equivocada. DocumentFragment y replaceChildren aportan un 9–10 %, no el orden de magnitud que la leyenda les atribuye; lo que multiplica por dieciséis es intercalar una lectura en el bucle de inserción. reconciliar de 06-06 gana 38× en el caso frecuente —una tarjeta que cambia— y pierde frente a replaceChildren cuando se reordena la lista entera, límite que la propia lección anunció. Y la optimización más aburrida resultó ser de las mejores: no escribir lo que no ha cambiado, con una huella barata que ahorra 9.600 escrituras por render y baja pintarTarjeta de 149 a 101 ms.

Sabes animar barato: solo transform y opacity, porque son las únicas que se resuelven en composición; con FLIP para los movimientos que cambian la geometría de verdad, con will-change puesto y retirado en lugar de permanente, y con la observación decisiva de que una animación CSS o de la Web Animations API sobrevive a un hilo principal ocupado mientras que una de requestAnimationFrame no. Conoces las tres herramientas de aislamiento: contain para prometer que lo de dentro no afecta a lo de fuera, content-visibility: auto con su contain-intrinsic-size obligatorio —dos líneas de CSS que bajaron el render de 142 a 78 ms—, y will-change con su coste en memoria de GPU. Y sabes cuándo toca requestAnimationFrame en lugar de setTimeout: para todo trabajo visual, con el patrón porFotograma que ejecuta más veces que un throttle de 100 ms y aun así pierde doce veces menos fotogramas, porque lo que importa no es ejecutar poco sino ejecutar en el momento correcto.

Has implementado la virtualización dos veces: la lista progresiva con centinelas de IntersectionObserver, que hace aparecer la primera tarjeta en 11 ms pero acumula nodos al desplazarse, y la ventana calculada con altura fija y espaciadores, que mantiene 48 tarjetas en el DOM sea cual sea el tamaño del tablero. Y has visto su letra pequeña sin adornos: rompe Ctrl+F, exige aria-setsize y aria-posinset para no destrozar la experiencia con lector de pantalla, complica la impresión y los enlaces directos, obliga a filas de altura uniforme y añade noventa líneas con un modo de fallo nuevo. De ahí la regla de decisión: content-visibility por defecto, virtualización solo cuando el problema sean los nodos. Aquí lo era, porque la fila 9 lo exigía explícitamente. Por último, la delegación de eventos de 06-04 ha recibido su tercera justificación —38 ms de registro frente a 0,004 ms, y la única forma sensata de convivir con tarjetas que entran y salen del DOM en cada fotograma— confirmando otra vez que las decisiones de diseño buenas suelen resultar también las rápidas.

Queda un frente, y es el único que no puedes arreglar escribiendo mejor JavaScript, porque ocurre antes de que se ejecute la primera línea de tu código. Las filas 1, 3 y 10 siguen intactas: 4,1 s de LCP, 0,21 de CLS y 214 kB en 28 peticiones antes de que aparezca la primera tarjeta. Todo lo que has optimizado en tres lecciones —el índice Map, la caché, el worker, la limpieza de fugas, la ventana virtual— no sirve de nada durante los cuatro segundos en los que Lucía mira una pantalla en blanco desde el móvil. Ahí manda otra cosa: qué descarga el navegador, en qué orden y cuánto de eso se usa realmente. Es la deuda que 01-03 y 06-01 dejaron apuntada al hablar de defer y type="module", y la que 05-04 aplazó explícitamente al mencionar el tree shaking y los empaquetadores. Le toca ahora, y cierra el módulo: Carga Perezosa y División de Código.