Esto no es purismo. Es aritmética: GSAP con ScrollTrigger son ~45 KB comprimidos, Three.js pasa de 150 KB. Toda esta página pesa 57 KB. Meter una librería de movimiento habría triplicado el peso del sitio para animar una cosa.

Aleatorio, pero siempre el mismo

El primer requisito es raro: el campo tiene que verse aleatorio pero ser determinista. Si cada recarga dibuja un patrón distinto, deja de ser una identidad y pasa a ser ruido. Y Math.random() no sirve, porque no se puede preguntar "¿qué valor te tocaría en la celda 12, 7?".

La solución es una función hash: mismas coordenadas, mismo número, siempre, sin guardar nada.

function hash(x, y) {
  let h = (x * 374761393 + y * 668265263) ^ 0x5bf03635
  h = Math.imul(h ^ (h >>> 13), 1274126177)
  return ((h ^ (h >>> 16)) >>> 0) / 4294967296
}

Devuelve un número entre 0 y 1 a partir de dos enteros. Es el mismo truco de los generadores de terreno procedural, en su versión más pequeña posible.

Crecer, no aparecer

El campo no se dibuja de golpe: se propaga desde una celda semilla, como algo que se extiende. Un recorrido en anchura sobre la retícula, donde cada celda vecina entra o no según su propio hash y con una probabilidad que baja con la distancia, para que el campo se apague en los bordes en vez de cortarse.

const queue = [[seedX, seedY, 0]]
let head = 0

while (head < queue.length && head < budget) {
  const [x, y, depth] = queue[head++]

  for (const [nx, ny] of [[x + 1, y], [x - 1, y], [x, y + 1], [x, y - 1]]) {
    if (seen[ny * cols + nx]) continue
    // El umbral sube con la distancia: el campo se disuelve, no se recorta.
    if (hash(nx, ny) > 0.93 - depth * 0.0085) continue
    seen[ny * cols + nx] = 1
    queue.push([nx, ny, depth + 1])
  }
}

El budget es el detalle que hace que esto sea viable en un teléfono: en escritorio son ~1250 celdas, en móvil 420. No es una degradación visual perceptible; es la diferencia entre 60 fps y un ventilador.

El truco de rendimiento que sí importa

Un fillRect por celda con un fillStyle distinto cada vez es lento, porque cada cambio de estilo es un cambio de estado del contexto. La solución no es dibujar menos: es agrupar.

Las opacidades se cuantizan en diez cubos, y se pinta cubo por cubo. Diez cambios de fillStyle en total, en lugar de mil doscientos:

const buckets = Array.from({ length: 10 }, () => [])

for (const cell of cells) {
  buckets[Math.min(9, (cell.alpha * 10) | 0)].push(cell)
}

buckets.forEach((cells, i) => {
  if (!cells.length) return
  ctx.fillStyle = `rgba(20, 20, 18, ${(i + 0.5) / 10})`
  for (const c of cells) ctx.fillRect(c.x, c.y, size, size)
})

Nadie nota la diferencia entre 1000 opacidades distintas y 10. Todo el mundo nota un scroll a 30 fps.

Sembrado en la posición real

El campo tiene que nacer exactamente del punto naranja del <h1>. No de una coordenada aproximada escrita a mano: del punto renderizado, que cambia según la tipografía cargada, el ancho de pantalla y el tamaño de fuente del sistema.

const fonts = document.fonts?.ready ?? Promise.resolve()

Promise.race([fonts, new Promise((r) => setTimeout(r, 400))]).then(async () => {
  const { initHeroPixels } = await import('./hero-pixels.js')
  initHeroPixels(canvas, seed, { staticOnly, hover: env.hover })
})

Dos cosas pasan aquí. La primera: se espera a document.fonts.ready, porque antes de que cargue Instrument Sans el punto está en otro sitio y el campo nacería descolocado. La segunda: se espera con techo. Si una fuente falla, el Promise.race cede a los 400 ms y el hero se dibuja igual. Una promesa sin timeout es un bug esperando a una mala conexión.

El módulo además se importa dinámicamente, así que su peso no entra en el paquete inicial. Y quien pidió menos movimiento, tiene modo de ahorro de datos o está en un equipo de gama baja recibe el campo ya asentado, sin animación:

export const staticOnly = env.reduced || env.saveData || env.lowEnd

La animación que se apaga sola

Lo último, y lo más fácil de olvidar: el bucle termina. A los dos segundos el campo está asentado, se cancela el rAF y la pestaña vuelve a costar cero. Una animación ambiental que corre para siempre es una batería que se vacía para siempre.

Un fondo animado no tiene por qué costar 200 KB y un núcleo de CPU. Casi siempre cuesta eso porque nadie preguntó cuánto tenía que costar.

—Le falta aire. —Yo lo veo bien.

No hay forma de ganarla, porque nadie está midiendo nada. Los dos están recordando la página, no viéndola. Y un recuerdo de una página no tiene números.

El problema real

Al construir esta página apareció el síntoma clásico: en el monitor grande todo respiraba, y en el teléfono algunas secciones parecían desconectadas entre sí. No "apretadas" — al revés: tan separadas que el ojo perdía la relación entre un titular y su párrafo.

Ese es el matiz que casi siempre se pierde. Generosidad no es lo mismo que vacío. Un hueco tan grande que rompe la jerarquía de proximidad no se lee como lujo, se lee como un error de maquetación.

La escala primero

Antes de medir hay que tener contra qué medir. Todo el espaciado del sitio sale de una escala fluida, y vive en un solo archivo:

--space-2xs: clamp(0.5rem, 0.45rem + 0.2vw, 0.65rem);
--space-xs:  clamp(0.75rem, 0.65rem + 0.4vw, 1rem);
--space-s:   clamp(1.15rem, 1rem + 0.6vw, 1.6rem);
--space-m:   clamp(1.75rem, 1.4rem + 1.4vw, 2.75rem);
--space-l:   clamp(2.75rem, 2.1rem + 2.6vw, 4.5rem);
--space-xl:  clamp(4rem, 2.9rem + 4.4vw, 7rem);
--space-2xl: clamp(5rem, 3.4rem + 5.6vw, 8rem);

La regla que hace que esto funcione no es técnica, es social: si un valor no está en la escala, es un valor puesto a ojo y hay que justificarlo en un comentario. Sin esa regla, la escala se convierte en decoración y a la tercera semana el CSS vuelve a tener margin-top: 37px.

Encima de la escala hay dos roles con nombre, para no elegir un escalón cada vez:

--section-space: var(--space-2xl);   /* entre secciones */
--copy-space:    var(--space-l);     /* dentro de un bloque de texto */

Y luego el metro

Con la escala puesta, la pregunta deja de ser "¿se ve bien?" y pasa a ser "¿qué hueco hay realmente entre estos dos elementos, en este ancho?". Eso sí se puede responder con un script.

const gaps = await page.evaluate(() => {
  const out = []
  for (const section of document.querySelectorAll('section')) {
    const kids = [...section.children].filter((el) => el.offsetHeight > 0)
    for (let i = 1; i < kids.length; i++) {
      const prev = kids[i - 1].getBoundingClientRect()
      const curr = kids[i].getBoundingClientRect()
      out.push({
        section: section.className.split(' ')[0],
        between: `${kids[i - 1].tagName} → ${kids[i].tagName}`,
        gap: Math.round(curr.top - prev.bottom),
      })
    }
  }
  return out
})

Se corre contra el build servido —no contra el HTML crudo— en dos anchos, y escupe una tabla. Ahí es donde aparecen las sorpresas: huecos de 140 px que en el CSS parecían de 60, porque un margin colapsado y un padding de sección se estaban sumando sin que nadie lo hubiera pedido.

Lo que cambió de verdad

El script no toma decisiones de diseño. Lo único que hace es quitar la opinión de la parte que no era opinable. Después de correrlo:

• Tres secciones tenían el doble de separación de la que decía su CSS.
• El par 02 / La intención estaba a --space-m de su propio titular, cuando es una sola unidad y pedía --space-2xs.
• El teléfono no necesitaba "más aire", necesitaba menos, en los sitios exactos donde la proximidad tenía que hacer su trabajo.

Ninguno de esos tres se veía a ojo. Los tres eran evidentes en la tabla.

Lo que me llevo

Medir no sustituye al criterio: sustituye a la discusión sobre los hechos, para que el criterio se pueda gastar en lo que sí importa. Cuando los dos lados de la conversación ven el mismo número, la pregunta vuelve a ser la buena —¿este hueco ayuda a leer?— en vez de la inútil, que es ¿quién tiene razón?