CodeForge

JavaScript de Cero a Experto / DOM a fondo

Fragmentos y rendimiento: tocar el DOM con cabeza

Teoría18 min20 XP

Cada vez que insertas algo en el DOM, el navegador puede tener que recalcular posiciones y redibujar la pantalla. Con 4 gastos da igual; con 500 filas de un reporte, tu página se siente pesada. Hoy aprendes el hábito que separa el código que "funciona" del que escala: agrupar los cambios y tocar el DOM UNA vez.

El costo invisible: reflow

Cuando cambias el DOM, el navegador debe recalcular el layout de la página (reflow) y volver a pintarla (repaint) — el mismo trabajo que hace al cargar, en miniatura. Insertar 500 elementos con 500 append separados puede disparar ese trabajo una y otra vez; insertarlos en UN lote lo dispara una sola.

DocumentFragment: el carrito

Un fragmento es un contenedor invisible que vive solo en memoria: le haces append como a cualquier elemento, y al insertarlo en el DOM se "disuelve" — entran sus hijos, no él:

console.time / console.timeEnd — tu primer cronómetro de rendimiento: todo lo que pase entre los dos se mide y se imprime. Guárdatelo, lo usarás toda la carrera.

El atajo moderno: append con spread

append acepta VARIOS argumentos — así que un array de elementos + el spread del módulo 5 logran el mismo lote sin fragmento explícito:

atajo-spread.js
// map: cada gasto → su li (el patrón del módulo 4)
const items = gastos.map((gasto) => {
const item = document.createElement("li");
item.textContent = gasto.nombre;
return item;
});

lista.append(...items);   // un solo append, todos adentro

Esta es la forma que verás en código moderno: map para transformar datos en elementos, UN append para instalarlos. El fragmento sigue siendo útil cuando armas estructuras más complejas por partes, pero para "array → lista" el spread es imbatible.

Nota honesta: los navegadores de hoy son listísimos optimizando cambios seguidos, y con 10 elementos JAMÁS notarás la diferencia — no reescribas código que funciona por esto. El punto es el HÁBITO: pensar en lotes no cuesta nada hoy y te salva cuando la lista tenga 5.000 filas — o cuando un framework lo haga por ti y entiendas POR QUÉ lo hace (React agrupa cambios exactamente por esta razón).

Tu app inserta 2.000 filas de un reporte con un for que hace lista.append(fila) en cada vuelta, y se siente lenta. Tu compañero dice que JavaScript es lento para bucles. ¿Cuál es el diagnóstico correcto?

Mini-reto

En el playground del reporte: 1) mide el mismo render SIN carrito (append directo dentro del bucle) y compara los tiempos — corre cada versión varias veces, verás que bailan; 2) reescribe el render con el atajo map + append(...items) y confirma que el tiempo es del mismo orden que con fragmento; 3) sube los registros a 2.000 y observa cuál aguanta mejor. Medir antes de opinar: así se discute rendimiento.

Qué sigue

Módulo casi completo: seleccionas, creas, vistes, pintas y hasta optimizas. Falta demostrarlo en cancha: el reto del módulo pone "Mi Bolsillo" EN LA PANTALLA — la lista de gastos renderizada desde el array, con formato colombiano, clases según categoría y total calculado. Todo lo del módulo en una sola página.