¿Qué es el Prerendering?

¿Qué es el prerendering?

El prerendering es la técnica de generar HTML totalmente renderizado para URLs específicas con anticipación — en build time, on-demand en request time, o programado — para que cuando un navegador o crawler solicite la página reciba markup listo para pintar en lugar de un shell SPA vacío que necesita JavaScript para poblar. El prerendering se sitúa entre el Server-Side Rendering completo (SSR, que renderiza en cada petición) y el Client-Side Rendering puro (CSR, que renderiza solo en el navegador). Resuelve el problema de SEO + first-paint de las aplicaciones de página única sin asumir la complejidad operacional de SSR.

La técnica tiene múltiples sabores que se confunden en conversación. El prerendering estático (build-time, también llamado SSG) genera un archivo HTML por ruta durante el pipeline de build — los outputs van a un CDN. El prerendering dinámico (request-time, a menudo vía servicios como Prerender.io o Rendertron) detecta tráfico de bots y sirve un caché pre-renderizado mientras los usuarios regulares obtienen el SPA. El prerendering híbrido mezcla ambos — pre-renderizar las rutas más visitadas estáticamente, recurrir a SSR o CSR para rutas long-tail.

Las tres estrategias de prerendering

1. Prerendering estático / SSG (build time)

Generar HTML para cada ruta durante el despliegue. Herramientas: getStaticProps de Next.js, Gatsby, Astro, adaptador estático de SvelteKit, generate estático de Nuxt. Mejor para contenido que no cambia por petición: páginas de marketing, blogs, docs, listados de categorías de e-commerce. Limitación: rebuild requerido para cambios de contenido.

2. Prerendering dinámico (request-time, dirigido a bots)

El servidor detecta User-Agent (Googlebot, Bingbot, crawlers sociales) y los enruta a un caché renderizado por Chrome headless. Los usuarios regulares siguen obteniendo el SPA. Herramientas: Prerender.io, Rendertron, Puppeteer personalizado + caché. Mejor para: SPAs legacy que no puedes refactorizar a SSR, pero necesitas SEO. Limitación: viola la preferencia de Google por paridad (humanos vs. crawlers deberían ver el mismo contenido).

3. Incremental Static Regeneration (ISR)

Híbrido: las páginas son estáticas pero se regeneran en segundo plano después de un TTL o on-demand. Next.js, Astro y Nuxt 3 lo soportan. Mejor para: contenido que cambia ocasionalmente (páginas de producto, artículos de noticias, listados). Combina velocidad SSG con frescura SSR.

Prerendering vs. SSR vs. CSR — cuándo usar cuál

Por qué importa el prerendering para rendimiento + SEO

• TTFB / LCP más rápidos. El HTML pre-renderizado golpea el navegador listo para pintar. Sin ciclo de descarga + ejecución + fetch + render JS.
• Mejores puntuaciones Core Web Vitals. LCP mide el paint above-fold más grande. El contenido pre-renderizado normalmente pinta más rápido que el contenido montado por SPA. Beneficio directo de señal de ranking.
• HTML rastreable. Los motores de búsqueda parsean contenido del HTML inicial, no después de que JavaScript se ejecute. Elimina el riesgo de cuello de botella de renderizado en el crawl de dos pasos de Googlebot.
• Cache-friendly. El HTML estático se cachea en cualquier sitio — edges CDN, navegador, proxies intermedios. Las respuestas SSR son normalmente por usuario, no se pueden cachear tan agresivamente.
• Offline-friendly. Las páginas pre-renderizadas pueden ser cacheadas por service workers para acceso offline.

Errores comunes de prerendering

• Pre-renderizar contenido personalizado. Los datos específicos del usuario (nombre, preferencias, carrito) no deberían estar en el HTML estático. Hidrátalos del lado del cliente después del mount.
• Contenido pre-renderizado obsoleto. Si tu TTL es demasiado largo, los usuarios ven info desactualizada. Ajusta ISR / cache-control agresivamente.
• Cloaking vía prerendering dinámico. Servir a Googlebot una versión totalmente renderizada mientras los usuarios obtienen un shell lento puede violar las directrices de cloaking de Google si el contenido difiere.
• Desajustes de hidratación. El HTML pre-renderizado y el render del lado del cliente deben coincidir exactamente, o React/Vue lanza warnings + re-renderiza. Verifica contenido no determinista (Date, IDs aleatorios, formato específico de locale).
• Bloat de build time. Pre-renderizar estáticamente 100,000 rutas puede tardar horas. Usa ISR para la cola larga; estático para los top 5,000.
• Olvidar metadata. El prerendering debería poblar title, meta description, og:image, JSON-LD — no solo contenido del body.

FAQ: Prerendering

¿Es el prerendering lo mismo que SSR?

No. SSR renderiza en cada petición (lado del servidor), el prerendering renderiza con anticipación (build o programado). Ambos producen HTML para el navegador, pero con diferentes trade-offs de caching + frescura.

¿Google todavía necesita prerendering en 2026?

Menos que antes — Googlebot ahora ejecuta JavaScript. Pero: el renderizado es la fase cuello de botella del crawl de Google; el HTML pre-renderizado se indexa más rápido y de forma más fiable. Otros crawlers (Bingbot, redes sociales, scrapers de entrenamiento LLM) manejan JS peor, así que el prerendering todavía vale la pena.

¿Cuál es la diferencia entre prerendering y static site generation (SSG)?

SSG es una forma de prerendering — específicamente la variante de build-time. El prerendering es el concepto más amplio que también cubre enfoques dinámicos e incrementales.

¿Debería usar Prerender.io o reconstruir con SSG?

Prerender.io es una solución temporal para SPAs legacy que no se pueden refactorizar. Si puedes reconstruir en Next.js, Astro o SvelteKit con su SSG/ISR nativo, eso casi siempre es la mejor respuesta a largo plazo.

¿Cómo afecta el prerendering al tiempo de despliegue?

Para SSG con miles de rutas, el tiempo de build puede dispararse (horas). Estrategias: builds paralelos, cachear artefactos de build, ISR para la cola larga (solo construir las rutas top estáticamente + regenerar el resto on-demand).

¿Puedo pre-renderizar páginas autenticadas?

No lo hagas — el estado de auth es por usuario, y servir el mismo HTML estático a todos los usuarios filtra información o rompe la personalización. Usa SSR o CSR para contenido bloqueado por auth.

Cómo se relaciona LoadFocus con el prerendering

El prerendering mejora LCP y TTFB, pero las ganancias solo aparecen si tu setup de CDN + caching sirve el HTML pre-renderizado correctamente. Las pruebas de velocidad de sitio web LoadFocus validan que las rutas pre-renderizadas realmente alcanzan los objetivos Core Web Vitals (LCP ≤2.5s, INP ≤200ms, CLS ≤0.1) en producción. Las pruebas de carga validan que el flujo de regeneración (ISR, prerender dinámico) aguanta bajo tráfico — el modo de fallo común es que el regenerador se sobrecarga durante escenarios cache-stampede.