prerender no es un capricho para fardar de “métricas instantáneas”.
No es un sustituto de prefetch.
No es un hack para enmascarar webs lentas.
No es magia negra que Google premia porque sí.
Eso es lo que piensa el mediocre.
Lo que prerender sí es:
una orden al navegador para cargar y renderizar en segundo plano una página completa, antes de que el usuario la pida.
Cuando haga clic, no verá un “cargando”, verá un corte inmediato.
Es el equivalente digital a tener la mesa puesta antes de que llegue el invitado.
Acto I — La mentira de la medianía
Dogma reproducido:
“Pon prerender en todas las páginas y la navegación será instantánea”.
Autopsia:
Un ecommerce mete prerender en la home para la categoría, en la categoría para todos los productos, y en los productos para el checkout.
El navegador empieza a cargar páginas que el usuario nunca visita.
Resultado: ancho de banda desperdiciado, CPU disparada, batería móvil drenada.
El rendimiento global cae.
El diseñador sonríe porque su click demo en Chrome fue instantáneo.
El usuario, en cambio, cierra la pestaña porque el móvil se recalienta.
Causa: confundir “posible” con “probable”.
Consecuencia: sobrecarga de recursos, frustración, métricas peores.
Smells — síntomas de abuso:
- prerender en 10 rutas a la vez.
- prerender en páginas pesadas (checkout con 40 scripts).
- prerender en rutas que cambian con frecuencia (datos dinámicos, usuarios distintos).
Contraejemplo rápido:
HTML
<!-- Solo la siguiente página del flujo crítico -->
<link rel="prerender" href="/checkout.html">
Explicación:
El navegador carga /checkout.html en segundo plano.
Cuando el usuario pulse “Comprar”, el checkout se abre al instante.
No hay transición perceptible.
Acto II — La verdad de prerender
Visión:
prerender no es un comodín, es una bala de francotirador.
Solo tiene sentido cuando la probabilidad de que el usuario visite esa ruta es casi del 100%.
Lo demás es desperdicio.
Modelo operativo:
Crítico + seguro → prerender.
Probable → prefetch.
Urgente → preload.
Innecesario → delete.
Táctica 1 — un único camino
Prerender solo en un paso obvio del flujo: home → checkout, login → dashboard.
Nunca en diez rutas a la vez.
Táctica 2 — mide antes y después
Chrome DevTools y Lighthouse permiten medir si el prerender realmente acelera el primer render.
Sin datos, es superstición.
Táctica 3 — cuidado con el contenido dinámico
Si la página cambia (ej: carrito, sesión, usuario), el prerender puede servir datos obsoletos.
Úsalo solo donde el contenido es estable o universal.
Acto III — El manifiesto
Principios no negociables:
prerenderno sustituye aprefetchnipreconnect.- Se usa solo en rutas críticas y seguras.
- Nunca más de un prerender activo por página.
- No sirve para esconder la lentitud de una web obesa.
Definición de hecho (DoD):
- El click en la ruta prerenderizada es instantáneo (<100ms percibidos).
- No hay sobrecarga de CPU ni batería en móviles.
- Los datos prerenderizados siguen siendo válidos en la sesión.
Métricas de guardarraíl:
- Prerender <= 1 ruta por página.
- Consumo de recursos controlado (<10% extra en DevTools).
- Mejora real en métricas de transición entre páginas.
Plan de acción en 24h:
- Identifica el flujo crítico (ej: producto → checkout).
- Aplica
prerendersolo al siguiente paso seguro. - Mide el impacto en métricas reales (LCP, INP, FID).
- Elimina cualquier prerender innecesario.
Pablo Rodríguez: el crítico implacable
¿Qué opinas del que mete prerender en todas las rutas?
Es como cocinar 20 platos distintos porque “quizá” el invitado los pida.
Resultado: cocina saturada, ingredientes desperdiciados, ninguno fresco.
El navegador se quema, el usuario se queda sin batería y la supuesta optimización se convierte en sabotaje.
¿Cuál es la diferencia real entre prefetch y prerender?
prefetch es comprar los ingredientes con antelación.
prerender es cocinar el plato entero y tenerlo en la mesa.
Si aciertas con el plato, el invitado come al instante.
Si fallas, tiras la comida y el esfuerzo.
El profesional sabe cuándo arriesgarse, el mediocre cocina todo el menú.
¿Por qué la mayoría lo usa mal?
Porque confunden “posible” con “probable”.
Creen que el usuario va a visitar todas las rutas, así que prerenderizan todo.
El resultado: desperdicio masivo de ancho de banda y CPU.
Es la versión digital de llenar el carrito con cosas que nunca vas a comer.
Entonces, ¿cuándo usarías prerender sí o sí?
En flujos de conversión obvios: del carrito al checkout, del login al dashboard.
Donde la probabilidad es altísima.
Ahí el prerender convierte un clic en una experiencia instantánea, casi mágica.
En todo lo demás, es sobreingeniería.
¿Qué le dirías al que lo ignora siempre?
Que está perdiendo un arma brutal en flujos clave.
Un checkout prerenderizado puede ser la diferencia entre una conversión y un abandono.
Si nunca lo usas, no eres minimalista: eres un flojo que se conforma con tiempos mediocres.
¿Y qué pasa con la obsolescencia de datos?
Ese es el talón de Aquiles.
Si prerenderizas páginas con estado dinámico (carrito, sesión, contenido personalizado), corres el riesgo de servir basura.
El que lo ignora es un ingenuo, el que lo controla con cabeza es un maestro.
La diferencia entre amateur y profesional es saber dónde no aplicar la herramienta.
La sentencia
prerender es el ajedrez del rendimiento.
Juegas la pieza antes de que el rival piense.
Si aciertas, la experiencia es instantánea, impecable, inolvidable.
Si fallas, malgastas recursos, arruinas métricas y quemas al navegador.
Un profesional lo dispara como un francotirador.
Un mediocre lo suelta como una ametralladora y se pega un tiro en el pie.