¿Qué es el prerendering?

El prerendering consiste en generar el HTML de una página antes de que nadie la pida, normalmente al construir el sitio, y servirlo ya hecho. Cuando llega la primera visita, el trabajo está terminado y no queda nada por ejecutar para ver el contenido.

Es una respuesta directa al problema que plantea el JavaScript SEO: si todo lo importante aparece solo después de ejecutar el código, cualquier lector que no lo ejecute —o que lo haga más tarde— ve una página incompleta.

La palabra se usa con dos alcances distintos y conviene no mezclarlos. En el mundo del SEO suele significar generación estática de todas las páginas de un CMS; en el navegador existe además una función que precarga y prerrenderiza el siguiente enlace probable. Comparten nombre y no comparten propósito.

Vale la pena decir qué NO cambia. El prerendering no altera el contenido ni el enlazado interno: la misma página, los mismos textos, los mismos enlaces. Lo único que cambia es el momento en que ese HTML existe, y eso ya basta para que la conversación con un buscador sea otra.

Tampoco es una técnica nueva ni sofisticada. Antes de que las webs se montaran en el navegador, todas las páginas eran archivos escritos de antemano; lo que llamamos prerendering es en buena medida volver a eso, con herramientas que generan esos archivos a partir de plantillas y datos.

Todas las formas de montar una web se distinguen por una sola pregunta: en qué momento existe el HTML. Al construir el sitio, en cada petición, en el navegador del visitante, o de forma distinta según quién pregunte.

Las tres primeras son decisiones legítimas con costes distintos. La cuarta merece una nota, porque durante años se recomendó y hoy no: Google la describe como un apaño y no como una solución a largo plazo, y recomienda en su lugar renderizado en servidor, renderizado estático o hidratación.

Conviene además no leerlo como una escalera de peor a mejor. Un blog que cambia una vez por semana y un e-commerce con stock en vivo no tienen la misma respuesta correcta; lo que se elige es dónde se paga el trabajo, no cuánta calidad se quiere.

Hay una quinta forma que no cabe en la lista porque las combina: generar de antemano y refrescar por lotes cuando algo cambia. Es hoy el punto medio más extendido, porque conserva la entrega instantánea sin condenar el contenido a quedarse congelado.

Y conviene notar quién decide en cada caso. En las tres primeras decide el equipo que construye el sitio; en la cuarta decide el servidor en el momento, mirando quién pregunta. Esa diferencia es la razón de fondo por la que la última envejece mal: cualquier cambio en cómo se reconoce a un rastreador puede romperla sin que nadie toque el código.

Lo que gana es previsibilidad. La página llega completa para todo el mundo, el rastreador la ve entera en la primera fase y el TTFB suele ser el mejor posible, porque no hay nada que calcular en el momento.

Lo que cuesta es frescura. Un HTML generado ayer sigue diciendo lo de ayer hasta que se vuelva a generar, y eso choca de frente con un catálogo cuyos precios y disponibilidad cambian a lo largo del día y el índice se queda con la versión vieja.

Y hay un coste que aparece con el tamaño: el tiempo de construcción. Generar cien mil páginas en cada publicación deja de ser gratis, y a partir de cierto punto obliga a generar solo lo que cambió, que es una decisión de arquitectura y no un ajuste.

Hay una ganancia menos evidente y bastante valiosa: la robustez. Una página ya generada se sigue sirviendo aunque falle la base de datos, lo que en otro caso daría un error 500, porque en ese momento no es más que un archivo. Para secciones críticas —precios, contacto, avisos legales— eso vale más que unas décimas de segundo.

Y un coste que aparece en el otro extremo: la depuración. Cuando algo sale mal, el error ocurrió en la construcción, es decir horas antes y en otra máquina, no en la visita que lo destapó. Los registros útiles ahí no son los del servidor sino los del proceso de generación, algo que conviene tener resuelto antes de necesitarlo, igual que ocurre con el análisis de logs.

Tiene sentido claro cuando el contenido cambia con menos frecuencia que las visitas: artículos, fichas de servicio, documentación, glosarios — todo lo que un rastreo encuentra igual una semana después. Ahí generar una vez y servir mil veces es sencillamente la cuenta correcta.

Deja de tenerlo cuando cada visitante debe ver algo distinto —su carrito, su sesión, sus precios— porque eso no puede compartirse. La salida habitual es mixta: la parte estable prerenderizada y lo personal cargado aparte, lo que además evita el problema de guardar en un CDN lo que no debe guardarse.

Y hay un caso intermedio muy común: contenido que cambia a diario pero no cada minuto. Ahí basta con regenerar por lotes o al detectar el cambio, y conviene comprobar en el análisis de logs con qué frecuencia vuelve realmente el rastreador antes de decidir el ritmo.

Una señal práctica para decidir: mira cuántas de tus URLs muestran exactamente lo mismo a cualquiera que entre. Si son la mayoría —y en la mayoría de los sitios lo son— generar de antemano es la opción evidente para esa parte, aunque el resto necesite otra cosa.

Y una precaución sobre el tamaño: si el catálogo crece, el tiempo de construcción crece con él, y llega un punto en que publicar un cambio menor obliga a regenerarlo todo. Antes de llegar ahí conviene poder generar solo lo afectado, sobre todo si la paginación multiplica las URLs; es más fácil montarlo desde el principio que rehacerlo cuando el e-commerce ya tiene cien mil fichas.

El primero es prerenderizar solo para los buscadores. Eso es exactamente el renderizado dinámico que Google desaconseja, y además obliga a mantener dos versiones que acaban divergiendo sin que nadie lo note.

El segundo es olvidar la regeneración. Una página generada una vez y nunca más se queda congelada: precios viejos, avisos caducados, enlaces a secciones que ya no existen y que terminan en errores 404.

Y el tercero es dar por hecho que con esto se acabaron los problemas de rendimiento. El HTML llega antes, pero si después se cargan tres megas de código, el INP y la sensación de lentitud siguen exactamente donde estaban.

Un cuarto error, típico de las migraciones: prerenderizar y olvidarse de las cabeceras. El HTML llega perfecto y las instrucciones que viajan en la respuesta —entre ellas el X-Robots-Tag— dependen de cómo se sirvan los archivos, no de cómo se generaron. Es fácil perderlas al cambiar de servidor sin notarlo.

Y el último: creer que el HTML generado ya está bien por serlo. Un generador reproduce fielmente lo que se le indique, incluidos un canonical mal puesto o un título repetido en mil páginas, es decir contenido duplicado. Prerenderizar acelera la entrega de lo que hay; no lo corrige.