Skip to main content

Rendimiento, build y producción

Rendimiento no es optimización tardía, es decisión temprana​

El rendimiento no se “arregla al final”. Se condiciona desde el primer día por cómo estructuras el proyecto, cómo usas Tailwind y cómo entiendes el build. Una UI lenta rara vez lo es por una sola causa.

Lo es por acumulación de decisiones pequeñas.

El rendimiento no se optimiza. Se preserva.

El build como frontera entre desarrollo y realidad​

En desarrollo:

  • Todo funciona.
  • Todo parece rápido.
  • Todo es permisivo.

En producción:

  • El navegador paga cada decisión.
  • El CSS se descarga completo.
  • El JS se parsea y ejecuta.
  • La red es el cuello de botella.

El build es el momento donde:

  • El código se reduce.
  • El CSS se poda.
  • Las decisiones se congelan.

Tailwind en producción: generar solo lo necesario​

Tailwind no es pesado por naturaleza. Es pesado si no se configura bien. En producción:

  • Solo deben existir las clases realmente usadas.
  • No deben existir utilidades huérfanas.
  • No deben generarse variantes innecesarias.

La clave no es “usar menos clases”. Es usar clases detectables y estables.

Clases dinámicas: el enemigo silencioso del purge​

Uno de los mayores errores en Tailwind es construir clases dinámicamente:

  • Concatenaciones de strings
  • Valores calculados
  • Clases que no existen en el código fuente literal

Esto provoca:

  • CSS faltante en producción
  • Workarounds peligrosos
  • CSS inflado por “safelists” indiscriminadas

Si el build no puede ver la clase, no existe.

Configuración de contenido como decisión crítica​

La opción content no es un detalle técnico. Es un contrato con el build. Debe:

  • Apuntar solo a archivos reales.
  • Incluir JSX/TSX/HTML que renderizan UI.
  • Excluir carpetas irrelevantes.

Un content demasiado amplio:

  • Genera CSS innecesario.
  • Aumenta tiempos de build.
  • Oculta errores.

Un content demasiado estrecho:

  • Rompe estilos en producción.

CSS final: tamaño, orden y predictibilidad​

En producción importa:

  • Tamaño del CSS
  • Orden de las reglas
  • Ausencia de duplicados

Señales de alerta:

  • CSS de cientos de KB para una UI simple.
  • Diferencias visuales entre dev y prod.
  • Overrides inesperados.

Un CSS sano:

  • Es pequeño.
  • Es predecible.
  • No necesita “parches” tras el deploy.

Rendimiento percibido vs rendimiento real​

No todo es milisegundos medidos.

El usuario percibe rendimiento cuando:

  • El layout no salta.
  • El texto aparece rápido.
  • Las interacciones responden.
  • Los estados son inmediatos.

Tailwind influye en esto indirectamente:

  • Clases bien declaradas evitan reflows.
  • Layout estable evita CLS.
  • Estados visibles reducen incertidumbre.

Componentes y coste de render​

En frameworks modernos:

  • El coste no es solo CSS.
  • Es render, re-render y reconciliación.

Malas prácticas comunes:

  • Clases condicionales innecesarias.
  • Componentes demasiado genéricos.
  • Variantes que disparan re-render.

Un sistema bien diseñado:

  • Reduce combinaciones.
  • Reduce lógica visual.
  • Reduce trabajo del framework.

Producción no es desarrollo con npm run build​

Producción implica:

  • Variables de entorno correctas.
  • Minificación real.
  • Eliminación de warnings.
  • Verificación visual final.

Errores frecuentes:

  • No probar el build local.
  • Confiar solo en dev server.
  • Detectar errores cuando ya está desplegado.

El build local es la última oportunidad barata de fallar.

Monitorizar lo que importa​

No todo se mide con Lighthouse, pero ayuda.

Indicadores útiles:

  • Tamaño del CSS final
  • Número de reglas generadas
  • CLS (layout shift)
  • TTI (time to interactive)

Lo importante no es el número perfecto. Es detectar regresiones.

Errores frecuentes en rendimiento con Tailwind​

  • Safelist masiva “por si acaso”.
  • Clases dinámicas sin control.
  • Configs copiadas sin entender.
  • CSS creciendo sin nadie darse cuenta.
  • Pensar que Tailwind es el problema.