Qué significa que algo "se compile en el cliente"
Publicado el 2026-09-12 por frfrand
La diferencia entre armar el HTML en el servidor y armarlo en el navegador, qué cambia para el usuario, para el buscador y para tu factura de servidor, y por qué hoy casi todo es una mezcla.
Cuando alguien dice que una aplicación "se compila en el cliente" o "renderiza del lado del cliente", está describiendo quién arma el HTML final.
Es una decisión de arquitectura con consecuencias muy concretas, y conviene entenderla antes de elegir herramienta.
Las dos formas
En el servidor. Llega la petición, el servidor consulta la base, arma el HTML completo con los datos adentro y lo manda. El navegador recibe un documento listo y lo dibuja. Así funcionaron la web entera durante veinte años, y así funcionan hoy WordPress, Django o Rails sin nada encima.
En el navegador. El servidor manda un HTML casi vacío y un archivo de JavaScript. El navegador ejecuta ese JavaScript, que pide los datos a una API y construye la página en el momento. Es lo que hacen React, Vue o Angular en su forma más simple.
La palabra "compilar" es un poco engañosa: no se compila en el sentido clásico. Lo que pasa es que el código se transforma antes (de JSX o TypeScript a JavaScript que el navegador entiende) y ese resultado se ejecuta en el cliente para producir el HTML.
Qué cambia para el usuario
Con renderizado en el servidor: la primera pantalla aparece rápido, porque lo que llega ya es la página. Pero cada navegación posterior pide otra página completa.
Con renderizado en el navegador: la primera carga es más lenta, porque hay que descargar y ejecutar el JavaScript antes de ver nada. A cambio, una vez cargado, moverse por la aplicación es casi instantáneo: sólo se piden los datos, no la página entera.
El intercambio, resumido: pagás al principio para que después sea rápido, o no pagás al principio y cada paso cuesta un poco.
Los dos costos que se subestiman
Los buscadores y los previsualizadores. Un rastreador que no ejecuta JavaScript ve el HTML vacío. Google hoy ejecuta JavaScript, pero no todos lo hacen, y tarda más en indexar. Y cuando alguien comparte tu link en un chat, el que genera la vista previa casi nunca ejecuta scripts: si el título y la descripción los pone el JavaScript, la vista previa sale vacía.
Los teléfonos que no son el tuyo. Ejecutar JavaScript cuesta procesador. En un teléfono de gama media de hace cuatro años, un paquete grande puede significar varios segundos de pantalla en blanco. Es un problema que casi nunca se ve desde una laptop de desarrollo con buena conexión.
Por qué hoy casi todo es una mezcla
La industria se dio cuenta de que el intercambio no hacía falta aceptarlo entero. Los frameworks modernos hacen las dos cosas:
El servidor genera el HTML de la primera pantalla, para que aparezca de inmediato y sea legible por cualquiera. Ese HTML llega con el JavaScript al lado, que al ejecutarse "toma el control" de la página ya dibujada y se encarga de las siguientes interacciones.
Eso se llama hidratación, y es el modelo de Next.js, Nuxt, SvelteKit y los demás.
Y una tercera vía que se usa poco
Si el contenido no cambia por usuario, hay una opción mejor que las dos: generarlo una sola vez al publicar y servir archivos estáticos.
Un blog, una documentación o un sitio institucional no necesitan que nadie arme nada en cada visita. Un archivo HTML en disco, servido por nginx, es lo más rápido y lo más barato que existe, y no se cae.
En ArduMaker esto es literalmente un tipo de despliegue: se compila el sitio en el servidor al hacer push y queda servido como estático, con su dominio y su certificado. Para sitios de contenido es difícil de superar.