JavaScript a la velocidad de la luz: Por qué tu bucle 'for' ya no es suficiente

Imagina que tienes una tienda online para sibaritas del café. Tienes un catálogo enorme con 200.000 variedades y tus usuarios adoran filtrarlas en tiempo real sin latencia. Ya has eliminado los métodos lentos(.filter() .map()) y usas un bucle for tradicional de una sola pasada sin crear nuevos objetos.

Eliminar arrays intermedios y evitar la recolección de basura (Garbage Collection) es el primer gran paso. Pero este no es un artículo sobre cómo dejar de usar .filter(). Aquí asumimos que ya sabes eso.

Hoy vamos a tomar ese bucle for optimizado —el que la mayoría de desarrolladores considera el top del rendimiento en JavaScript— y vamos a destrozar sus tiempos de ejecución aplicando Data-Oriented Design (DoD).

El rival a batir: El bucle "Top Tier" Habitual

En nuestra arquitectura, transferimos el catálogo completo a un Web Worker al inicio de la sesión para tener latencia cero en el main thread. Para filtrar los datos, el enfoque estándar y "optimizado" que escribiríamos sería tal que así (Array of Objects):

const t0 = performance.now();
let count = 0;
let sumPrice = 0;
const len = data.length;
for (let i = 0; i < len; i++) {
  const item = data[i];
  const { pricePerKg } = item;
  if (
    pricePerKg <= maxPrice &&
    item.intensity >= minIntensity &&
    item.stockKg >= minStock
  ) {
    count++;
    sumPrice += pricePerKg;
  }
}
const avgPrice = count > 0 ? Math.round(sumPrice / count) : 0;

const t1 = performance.now();
self.postMessage({
  type: "RESULT",
  stats: { count, avgPrice, time: t1 - t0 },
});

Es un código rápido. No hay asignaciones de memoria en el bucle. Pero tiene un problema oculto: la memoria caché de la CPU lo odia.

La Comparación en Vivo

Compara los resultados tú mismo. En un lado tenemos la versión original del bucle for, en el otro lado la versión DoD con conocimiento de dominio. Presta especial atención al filtro de Intensidad Mínima y mira el multiplicador de velocidad. Ambos cálculos operan sobre los mismos 200.000 registros, pero el enfoque DoD juega en otra liga.

Los números no mienten

Aunque hay una variación alta y dificilmente evitable entre ejecuciones, al aplicar DoD no solo ganamos velocidad bruta, sino que también reducimos la huella de memoria. Ahora entendamos qué hay detrás de esa versión optimizada.

El elefante en la habitación: ¿Por qué no filtrar en el Backend?

Antes de meternos en el código, hay que responder a la pregunta que cualquier desarrollador de backend sensato se estará haciendo: "¿Para qué envías 200.000 registros al navegador del usuario? ¿Por qué no filtras en el backend?"

El paradigma tradicional cliente-servidor se rompe cuando buscamos interactividad extrema. Enviar los datos al frontend es una decisión arquitectónica basada en tres pilares:

• Latencia Cero (UX): En nuestra demo, el usuario filtra moviendo sliders, lo que dispara docenas de eventos de estado por segundo. Si hacemos un round-trip de red a nuestra API por cada milímetro que se mueve el cursor, la experiencia será a trompicones. Al tener los datos en la memoria del Web Worker, la respuesta visual es inmediata.
• Computación Gratuita (Client-side): Si 5.000 usuarios empiezan a aplicar filtros complejos simultáneamente en tu backend, tu servidor sudará y tu factura de cloud se dispara. Sin embargo, los móviles y ordenadores de tus usuarios tienen procesadores multi-núcleo extremadamente potentes inactivos la mayor parte del tiempo. Desplazar la carga de trabajo al cliente es, literalmente, escalar gratis.
• Local-First y Compresión: Enviar 200.000 objetos suena masivo, pero empaquetados en formatos binarios o simplemente transmitidos con compresión Brotli/Gzip, el payload inicial es minúsculo (apenas unos cientos de KB). Se descarga una sola vez, se cachea, y a partir de ahí la red deja de ser un cuello de botella y ahorras el coste adicional en servidores

DoD: Piensa en hardware, no en entidades

DoD nos dice que estructuremos nuestros datos en base a cómo van a ser leídos, no en base a conceptos abstractos (un objeto "Café"). En lugar de tener un array con 200.000 objetos, lo transformamos en una Estructura de Arrays (Structure of Arrays o SoA) usando TypedArrays.

Y aquí entra nuestra arma secreta: conocer el dominio de negocio. En nuestra tienda sabemos por analíticas y experiencia que los usuarios casi siempre filtran por intensidad, podemos ordenar los datos por intensidad al comienzo. Esto nos permite hacer una salida temprana y abortar el bucle pronto.

Al recibir por primera vez los datos en el worker, los pasamos a TypedArrays y ordenamos por intensidad.

const { payload } = e.data;
const length = payload.length;
payload.sort((a, b) => b.intensity - a.intensity);
const intensity = new Uint8Array(length);
const stockKg = new Uint16Array(length);
const pricePerKg = new Uint8Array(length);
for (let i = 0; i < length; i++) {
  const item = payload[i];
  intensity[i] = item.intensity;
  stockKg[i] = item.stockKg;
  pricePerKg[i] = item.pricePerKg;
}
data = { intensity, stockKg, pricePerKg };

El código de filtrado quedaría bastante similar a la versión estandar pero con la optimización de salida temprana

const t0 = performance.now();
let count = 0;
let sumPrice = 0;
const { intensity, pricePerKg, stockKg } = data;
const len = intensity.length;

for (let i = 0; i < len; i++) {
  if (pricePerKg[i] <= maxPrice && stockKg[i] >= minStock) {
    if (intensity[i] < minIntensity) break;
    count++;
    sumPrice += pricePerKg[i];
  }
}

const avgPrice = count > 0 ? Math.round(sumPrice / count) : 0;

const t1 = performance.now();
self.postMessage({
  type: "RESULT",
  stats: { count, avgPrice, time: t1 - t0 },
});

Conclusión: El rendimiento es una decisión de diseño

• Aprovecha los TypedArrays: Obligan al motor de JavaScript a alojar la memoria de forma contigua, mejorando el uso de recursos.
• Los patrones de uso importan: Aprovecha las tendencias de uso (ordenar por el filtro más usado para forzar salidas tempranas).

Siguientes pasos

Para llevar el rendimiento al siguiente nivel, algunas opciones serían compilar nuestro código del worker a wasm y utilizar SIMD o incluso generar el código de filtrado al vuelo aplicando solo los filtros activos y omitiendo aquellos que están en el límite.

La función para generar los datos iniciales

const DATA_COUNT = 200_000;

function generateData() {
  const types = ["Coffee", "Tea", "Herb"];
  const origins = [
    "Colombia",
    "China",
    "Kenia",
    "Brasil",
    "India",
  ];
  const names = [
    "Gran Reserva",
    "Special Blend",
    "Premium Harvest",
    "Classic Oriental",
    "Morning Dew",
    "Sunset Roast",
  ];
  return Array.from({ length: DATA_COUNT }, (_, i) => ({
    id: `id_${i}`,
    name: `${names[i % names.length]} ${origins[i % origins.length]}`,
    type: types[i % types.length],
    origin: origins[i % origins.length],
    pricePerKg: Math.floor(Math.random() * 140) + 10,
    intensity: Math.floor(Math.random() * 5) + 1,
    stockKg: Math.floor(Math.random() * 1000),
  })); 
}