Framework JavaScript o sitio estático: qué hace la página

Un framework no es una decisión sobre velocidad de desarrollo. Es una decisión sobre cuánto estado tiene que cargar la página en el navegador. Una página que solo presenta contenido paga el precio del framework y no usa lo que el framework entrega. Decide por el estado que la página necesita, no por la herramienta que prefieres.

Qué tiene que hacer la página más allá de presentar contenido

Presentar contenido es HTML y CSS. El navegador pinta el texto y las imágenes, y el trabajo termina ahí. No hay nada que tenga que seguir ahí después de un clic.

Estado es todo lo demás. Un filtro que conserva la selección, un carrito que recuerda un artículo, un formulario que valida mientras escribes, una lista que se actualiza sin recargar. Estado significa que la página sabe algo, lo recuerda y cambia lo que muestra sin un documento nuevo.

Una pregunta sencilla separa los dos caminos. ¿En el clic, la página tiene que decidir algo en el dispositivo, o solo tiene que cargar otro documento?

Cuando la respuesta es otro documento, el navegador ya sabe hacerlo. Lo hace desde antes de que existiera cualquier framework.

Qué baja el visitante en cada camino

En un sitio estático, el visitante baja el documento, la hoja de estilo y las fuentes. El JavaScript que entra es la parte que de verdad necesita el dispositivo, como un buscador o un botón de tema.

En una página de framework, la descarga incluye el runtime del framework y el código de los componentes de toda la ruta. La página Rendering on the Web, de Google, describe el motivo. Para que el script del cliente tome el control donde el servidor se detuvo, hay que pasarle los datos. La mayoría de las soluciones con renderizado en el servidor serializa esos datos en etiquetas de script.

El documento pasa a cargar el HTML, los datos de origen y una copia completa de la interfaz. La expresión que usa el propio Google es una app por el precio de dos.

La página de Google sobre Core Web Vitals define dónde cae ese peso. Largest Contentful Paint mide la carga y debe ocurrir dentro de 2,5 segundos. Interaction to Next Paint mide la interactividad y debe quedar en 200 milisegundos o menos. Cumulative Layout Shift mide la estabilidad visual y debe quedar en 0,1 o menos. Google lee las tres en el percentil 75 de las cargas, separando móvil y escritorio.

La misma página registra que Interaction to Next Paint reemplazó a First Input Delay como Core Web Vital estable en 2024. El conjunto de métricas se mueve, así que el número que optimizas hoy tiene una fecha de retiro documentada.

Donde los límites de tiempo de respuesta divergen de la métrica

El Nielsen Norman Group (en inglés) fija tres límites de tiempo de respuesta. Un retraso de 0,1 segundos se lee como instantáneo, 1 segundo mantiene el flujo de pensamiento y 10 segundos mantienen la atención en la tarea.

Un segundo artículo del NN/g (en inglés) repite los mismos tres límites y agrega el resultado. Un retraso de 10 segundos muchas veces hace que la persona salga del sitio de inmediato.

Un tercer artículo (en inglés) convierte los límites en regla de interfaz. Una acción de más de 1 segundo pide indicador de progreso, en bucle entre 2 y 10 segundos y en porcentaje por encima de 10 segundos.

Esos límites describen la espera percibida por interacción. El Core Web Vitals describe dato de campo por carga, en el percentil 75.

Las dos referencias divergen en la escala. Interaction to Next Paint en 200 milisegundos es el doble del límite del NN/g para la respuesta instantánea y la mitad del límite de flujo de 1 segundo (Core Web Vitals, NN/g (en inglés)).

Largest Contentful Paint en 2,5 segundos queda por encima del límite de flujo de 1 segundo y por debajo del límite de atención de 10 segundos. Una página puede pasar la métrica y aun así sentirse lenta (Core Web Vitals, NN/g (en inglés)).

También divergen en lo que significa pasar. Google lee un número sobre todas las cargas en el percentil 75, así que un cuarto de las visitas puede estar peor. El NN/g describe el retraso único que la persona percibe.

La tercera diferencia es la retroalimentación. El NN/g tolera la espera cuando la interfaz muestra progreso. Ningún Core Web Vital mide esa señal, y Cumulative Layout Shift no tiene equivalente en el NN/g, porque mide estabilidad y no tiempo.

Conviene mirar los dos. La métrica dice cómo se comporta la página en el campo. Los límites dicen qué tolera el visitante mientras espera.

Qué hace el servidor en cada camino

Un sitio estático hace el trabajo una vez, en el build. Google describe el renderizado estático como producir un archivo HTML separado para cada URL antes del acceso. Después el host devuelve un archivo, y un CDN puede servirlo desde el borde.

La misma página enumera el resultado. El renderizado estático entrega un First Contentful Paint rápido y un Total Blocking Time y un Interaction to Next Paint más bajos, siempre que la página limite el JavaScript del cliente. También logra un Time to First Byte consistentemente rápido, porque el HTML existe antes de que llegue la petición.

Una página de framework con renderizado en el servidor hace ese trabajo en cada navegación. El servidor renderiza la interfaz a HTML, incrusta el JavaScript y los datos, y el cliente renderiza otra vez. Google observa que muchas soluciones de renderizado en el servidor retrasan el Time to First Byte o envían los datos dos veces, una en el markup y otra en el script.

Ese es el precio de la personalización. Una página que se arma por visitante necesita un servidor que la arme.

Qué pasa en la navegación siguiente

En un sitio estático, el clic siguiente es un documento nuevo. El navegador interpreta el HTML y pinta. Google observa que el visitante tiene menos probabilidad de esperar por JavaScript pesado de CPU antes de usar el sitio.

El costo es recargar la página. El estado de la página se pierde, y una animación o un panel abierto desaparecen, salvo que el sitio los guarde.

En una aplicación de página única, el router intercepta el clic, busca los datos y renderiza en el lugar. El estado sobrevive, y después de la primera carga la transición puede sentirse inmediata.

Quien pagó por eso fue la primera carga. También tiene un modo de falla que aparece en las métricas. La página de Google afirma que una página renderizada en el servidor puede parecer cargada e interactiva sin responder a la entrada. Eso dura hasta que el script se ejecuta y el handler se conecta. La misma página dice que, en el móvil, eso puede llevar minutos.

Quien hace clic dentro de esa ventana no recibe nada. La página parecía lista.

Cuándo el framework se paga solo

El framework es la elección correcta cuando la página carga estado que pertenece al dispositivo. Cuatro casos donde eso es claramente cierto.

Panel autenticado, donde la pantalla arma datos de varios endpoints y la persona filtra, ordena y edita sin salir.
Edición en tiempo real o colaboración, donde el cambio de otra persona tiene que aparecer sin recargar.
Flujo con muchas interacciones encadenadas, donde cada paso depende de la respuesta anterior y la validación ocurre mientras escribes.
Producto donde un estado alimenta varias vistas, como un constructor o un editor con vista previa.

El enrutado en el cliente también compensa cuando la aplicación tiene decenas de pantallas y moverse entre ellas es el producto. Cada navegación pasa a costar una búsqueda de datos en lugar de un documento.

Esos casos, de todos modos, son la excepción y no la regla. Una página que solo presenta contenido no gana nada con el framework.

El camino del medio: sitio estático con islas de interacción

La mayoría de las comparaciones se detiene en dos opciones. La tercera entrega HTML estático e hidrata solo las partes que lo necesitan.

La documentación de Astro define isla como un componente de interfaz mejorado dentro de una página de HTML estática. La misma página afirma que la mayoría de los frameworks basados en JavaScript hidrata y renderiza el sitio entero como una aplicación grande.

Astro invierte el valor por defecto. La documentación dice que el framework hidrata exactamente lo que está marcado y deja el resto como HTML estático. Un componente se vuelve interactivo por una directiva de cliente, y la directiva también define el momento.

client:load hidrata el componente apenas carga la página.
client:idle espera a que el navegador quede inactivo.
client:visible espera a que el componente entre en el área visible, y un componente que el visitante nunca ve nunca carga.

Para un sitio de contenido, eso cubre los casos reales. Un buscador, un selector de precio, un botón de tema y un formulario de newsletter entran como un paquete pequeño cada uno, y el texto alrededor sigue siendo HTML.

Esto tiene un costo real. Ahora decides, componente por componente, dónde termina la página estática y dónde empieza la parte interactiva. Equivocarte hacia un lado entrega JavaScript que nadie necesita. Equivocarte hacia el otro deja un control muerto hasta que llegue el paquete.

La propia documentación de Astro afirma que un sitio puede cargar 40 por ciento más rápido con 90 por ciento menos JavaScript. La comparación es con el mismo sitio hecho en el framework React más popular. La misma página vende el valor por defecto como cero JS. Los dos números vienen del proveedor, en la página del proveedor, y ninguno es una medición neutra.

Cómo decidir por el estado que carga la página

Responde esto antes de elegir la herramienta.

Lista cada pieza de estado que tiene que sobrevivir a un clic. Cero piezas apunta a un sitio estático.
Cuenta las interacciones que se encadenan. Un paso es un componente, y cinco pasos dependientes son una aplicación.
Pregunta quién es dueño del dato en cada paso, el servidor o el dispositivo. Si el dueño es el servidor, conviene el documento.
Cuenta las URLs. Pocas páginas con contenido profundo favorecen el estático, y decenas de pantallas con estado compartido favorecen el framework.
Pregunta qué hace la persona en la segunda visita. Leer de nuevo es un documento, y volver a una sesión de trabajo es estado.
Mira al equipo. Un framework que no puedes operar es un intercambio peor que HTML que sí puedes.

Lo que decide es el estado, no la herramienta. El mismo equipo puede elegir respuestas distintas para el sitio de marketing y para el producto, y las dos pueden estar bien.

Prueba antes de cerrar la elección

Mide los bytes de JavaScript por ruta, no el tamaño del paquete en el repositorio.
Lee el Interaction to Next Paint en el percentil 75, en un perfil de móvil con red limitada.
Carga la página con el JavaScript desactivado. Google ofrece esta prueba para separar renderizado estático de prerenderizado, porque la página prerenderizada se ve inerte sin script.
Haz clic en la navegación siguiente en una conexión lenta y anota si la página responde o solo parece lista.
Cuenta las rutas que renderizan en el cliente y confirma que cada una tiene un motivo.
Repite la cuenta después de un trimestre. La versión del framework y el requisito se mueven.

La respuesta depende del estado que carga la página, los bytes que el visitante paga por él y el punto en que un documento alcanzaba.