Sitio estático o dinámico: diferencias y cuándo usar cada uno

Todo sitio web responde a una petición del navegador con HTML. La diferencia entre estático y dinámico está en lo que pasa en el servidor entre la petición y la respuesta: o solo lee un archivo que ya existe, o ejecuta código para armar esa página en ese momento.

Esa diferencia decide casi todo lo que viene después: qué tipo de hosting contratas, cuánto pagas, cuánto trabajo cuesta mantener el sitio seguro y cómo se actualiza el contenido. Y muchos proyectos de hoy quedan en un punto intermedio, combinando los dos.

¿Qué es un sitio estático?#

MDN define un sitio estático como el que devuelve el mismo contenido fijo cada vez que se pide un recurso. El servidor busca el archivo en el disco y responde con 200 OK. No se ejecuta ningún lenguaje de back-end ni se consulta una base de datos.

Los archivos se pueden escribir a mano o generar con una herramienta (Astro, Hugo, Eleventy, Vite, Next.js) en un paso de build. Después del build, el resultado es una carpeta con HTML, CSS, JavaScript e imágenes, y esa carpeta es lo que va al servidor. Los detalles están en qué es un sitio estático.

Estático no significa sin interacción. El JavaScript que corre en el navegador puede abrir menús, filtrar listas y llamar a APIs. "Estático" describe al servidor, no a la página.

¿Qué es un sitio dinámico?#

En un sitio dinámico, parte de la respuesta se genera en el momento. Según la misma página de MDN, las páginas suelen crearse insertando datos de una base de datos en plantillas HTML, y el sitio puede devolver contenido distinto para la misma URL según el usuario o sus preferencias guardadas.

Eso exige código en el servidor (Node.js, Python, PHP, Ruby, Java y otros), un proceso corriendo para atender las peticiones y, casi siempre, una base de datos. A cambio, el sitio puede hacer lo que un conjunto de archivos no puede: login con sesión, contenido personalizado, control de acceso, carrito, búsqueda sobre datos que cambian todo el tiempo. Las tiendas online, las redes sociales, los paneles y WordPress son dinámicos. Cómo se combinan un sitio y una base de datos está en hospedar un sitio web con base de datos.

¿Cuáles son las diferencias lado a lado?#

Algunas filas merecen explicación:

• Velocidad. Leer un archivo siempre cuesta menos que ejecutar código y consultar una base. Un sitio dinámico bien hecho puede ser rápido, pero depende de la caché y de consultas optimizadas; el estático es rápido por defecto.
• Seguridad. Sin código en el servidor, no hay inyección SQL, sesión robada ni plugin desactualizado que explotar. El dinámico necesita actualizaciones constantes y una checklist de seguridad.
• SEO. Google procesa JavaScript en tres fases (rastreo, renderizado e indexación), y la propia documentación de búsqueda de Google dice que renderizar en el servidor o pre-renderizar sigue siendo una gran idea, porque hace el sitio más rápido y no todos los bots ejecutan JavaScript. Tanto el estático como el dinámico que arma HTML en el servidor cumplen con eso. Lo que perjudica es el contenido que solo aparece después de ejecutar JavaScript en el navegador.
• Costo. El estático no ejecuta código tuyo ni una base: basta un servidor web que entregue archivos, y eso cabe en el hosting más simple. El dinámico paga RAM y CPU para el proceso y para la base. Los números están en cuánto cuesta alojar un sitio web.

¿Cómo se ve la misma página en cada modelo?#

En el modelo estático, la página es un archivo index.html en la carpeta publicada. Si necesita un dato que cambia, el navegador lo busca en una API después de cargar:

<!doctype html>
<meta charset="utf-8">
<title>Estado</title>
<h1>Estado del servicio</h1>
<p id="status">Cargando...</p>
<script type="module">
  const res = await fetch("/api/status.json");
  const data = await res.json();
  document.querySelector("#status").textContent = data.message;
</script>

En el modelo dinámico, el servidor arma el HTML con los datos antes de responder. Un ejemplo mínimo con el módulo node:http de Node.js, sin dependencias:

import { createServer } from "node:http";

const escapeHtml = (s) =>
  s.replace(/[&<>"']/g, (c) => `&#${c.charCodeAt(0)};`);

const server = createServer((req, res) => {
  const url = new URL(req.url, "http://localhost");
  const name = url.searchParams.get("nombre") ?? "visitante";
  const now = new Date().toLocaleTimeString("es", { timeZone: "UTC" });

  res.writeHead(200, { "content-type": "text/html; charset=utf-8" });
  res.end(`<!doctype html><meta charset="utf-8">
<h1>Hola, ${escapeHtml(name)}</h1>
<p>Página generada a las ${now} UTC</p>`);
});

server.listen(process.env.PORT ?? 3000);

Cada visita a /?nombre=Ana produce un HTML distinto, con el nombre y la hora de esa petición. Fíjate en escapeHtml: todo dato que venga del usuario debe escaparse antes de entrar al HTML, o el sitio queda expuesto a XSS. En el modelo estático no hay plantilla en el servidor que escapar; en el JavaScript del navegador, escribir el dato con textContent, como en el primer ejemplo, evita el mismo problema.

¿Existe un punto intermedio?#

Sí, y es lo que usa la mayoría de los proyectos modernos. Tres combinaciones comunes:

1. Sitio estático + API. El front-end es estático y una API separada se encarga del login, los formularios y los datos. El sitio sigue siendo ligero y barato, y solo la API necesita servidor. Mira el lado de la API en qué es una API REST.
2. CMS + build automático. El contenido vive en un CMS o en archivos Markdown. Cada publicación dispara un nuevo build, y el sitio publicado sigue siendo estático.
3. Framework híbrido. Next.js, Nuxt, Astro y similares deciden página por página: lo que es igual para todos se vuelve HTML en el build, y lo que depende de la petición se renderiza en el servidor. En ese caso el proyecto necesita un servidor corriendo. La documentación de Next.js muestra que, al exportar solo archivos estáticos, funciones como cookies, Server Actions e Incremental Static Regeneration dejan de funcionar.

La diferencia entre generar en el build y en cada petición está explicada en SSR, SSG y sitio estático.

¿Cuándo elegir cada uno?#

La regla práctica: empieza por lo estático y agrega código en el servidor solo cuando aparezca algo que dependa de cada visitante o tenga que cambiar sin un nuevo deploy. Si el contenido es igual para todos y cambia pocas veces al día, un sitio estático lo resuelve con menos costo y menos riesgo. Para poner cualquiera de los dos en línea, mira cómo alojar un sitio web.

Cómo hacerlo en Square Cloud#

Square Cloud aloja los dos modelos, y el punto intermedio, en la misma cuenta. Para lo estático, entre diversos runtimes, como Node.js, Python y Go, hay uno para sitios estáticos: nginx está siempre en línea sirviendo la carpeta que generó el build, ningún código tuyo se ejecuta en el servidor, y un nuevo commit, una subida o una edición en el administrador de archivos quedan en línea al instante. Para lo dinámico, usa el runtime de tu lenguaje (Node.js, Python, PHP, Ruby, Java, Go y otros), en un contenedor siempre encendido, sin cold start ni modo de suspensión. Consulta los runtimes disponibles hoy en Runtimes.

En el esquema estático + API, el front-end y la API son dos aplicaciones separadas, cada una con su propio subdominio *.squareweb.app con HTTPS. Cada aplicación web usa como mínimo 512 MB de la RAM del plan, que es un pool compartido entre ellas. El deploy lo haces tú: ZIP en el panel, CLI, GitHub o la extensión de VS Code, y el archivo squarecloud.app es opcional, porque el panel lo genera en el deploy.

Hobby, desde R$12,49 al mes, cubre sitios web e incluye analítica web sin cookies, con visitas, rutas y códigos de estado. El dominio personalizado y el hosting de bases de datos, que un sitio dinámico suele necesitar, empiezan en Standard. Empieza por el runtime de sitios estáticos o mira la página de sitios.