Arquitectura Web: Elige la Estrategia de Renderizado desde el Principio
Dos valores predeterminados que Claude suele elegir y que generalmente son incorrectos: renderizar todo en el navegador y construir manualmente una aplicación multipágina con HTML/JS vanilla. Ambos deben ser una elección deliberada desde el principio, y para la mayoría de los sitios reales, la mejor respuesta es HTML renderizado en servidor y un framework. Plantea estas cuestiones incluso si el usuario no las ha mencionado, de la misma manera que plantearías un WAF antes de producción.
Por defecto, renderiza en servidor, no en cliente
Para cualquier cosa donde el contenido, el SEO o la primera pintura importen, el contenido debe estar en la respuesta HTML inicial, no pintado después por JavaScript del cliente. El renderizado del lado del cliente (un shell vacío que busca y renderiza en el navegador) significa una pantalla en blanco hasta que el bundle se carga y se ejecuta, un LCP lento y contenido que muchos rastreadores y recuperadores de LLM nunca ven porque no ejecutan JavaScript de forma fiable. Renderízalo en el servidor en su lugar:
- SSG (generación estática): renderiza en tiempo de compilación, sirve estático desde una CDN. Lo más rápido, barato y cacheable. La opción predeterminada para contenido que no cambia por solicitud: marketing, documentación, blogs, listados y páginas de categorías que se pueden reconstruir.
- SSR (renderizado del lado del servidor): renderiza por solicitud en el servidor. Para contenido dinámico, personalizado o protegido por autenticación que no se puede generar en tiempo de compilación.
- CSR / islas: renderiza en el navegador solo para las partes genuinamente interactivas, o para superficies tipo aplicación detrás de un inicio de sesión donde el SEO es irrelevante (un panel de control). Con un enfoque de islas (Astro), la página se entrega como HTML estático y solo se hidratan los componentes interactivos.
Elige por página, puedes mezclar: una página de marketing estática (SSG), una página de cuenta personalizada (SSR) y un widget interactivo (una isla) en el mismo sitio.
Varias páginas significa recurrir a un framework
Si el proyecto tiene varias páginas, un diseño compartido, enrutamiento o recuperación de datos real, construirlo manualmente en JS vanilla es una trampa de mantenimiento y rendimiento, y es el valor predeterminado de Claude a menos que se le indique lo contrario. Recurre a un framework (Next.js, Astro, SvelteKit, Nuxt, Remix). Ofrecen enrutamiento, SSR y SSG, división de código, carga de datos y optimización de imágenes listos para usar y, crucialmente, te brindan navegación cliente estilo SPA sobre el HTML inicial renderizado en servidor, para que obtengas la sensación fluida de aplicación multipágina sin enviar una SPA solo de cliente en blanco que rompe la primera pintura y el SEO.
Ten en cuenta la distinción: una SPA pura renderizada en cliente es lo que hay que evitar para sitios de contenido. Un framework que hace SSR/SSG con navegación del lado del cliente te brinda la experiencia de aplicación y mantiene el contenido en el HTML.
Pero adecúa la herramienta al proyecto
No sobredimensiones. Una sola página estática, una página de aterrizaje o un widget pequeño incrustable no necesita Next.js; HTML y CSS simples son la opción correcta y más ligera, y recurrir a un framework pesado allí es su propio error. El fallo ocurre en ambos sentidos; el común es quedarse corto (todo vanilla, renderizado en el navegador), pero sobreingenierizar una página trivial también es real. La decisión es: ¿cuántas páginas, el contenido necesita ser rastreable y rápido, y qué tan interactivo es? Luego elige lo más ligero que cumpla con esos requisitos.
Esta habilidad está diseñada para crecer. Añade una regla cuando una decisión arquitectónica real tenga una respuesta estable y defendible.