Definición
El Frontend Rendering o renderizado en el frontend es el conjunto de estrategias que determinan dónde y cuándo se genera el HTML que ve un usuario (y un bot) al visitar una tienda online. En lugar de un único método, hablamos de un espectro: CSR (Client-Side Rendering), SSR (Server-Side Rendering), SSG (Static Site Generation) e ISR (Incremental Static Regeneration).
En el contexto DTC/eCommerce, esta decisión no es "técnica" sin más: impacta directamente en el Core Web Vitals, en el crawl budget que Google asigna a tu catálogo y, sobre todo, en la tasa de conversión. Una PDP (Product Detail Page) que tarda 4 s en pintar puede perder hasta un 20 % de conversión frente a una que carga en 1,5 s.
Analogía
Piensa en tu tienda como un restaurante:
- CSR = te dan los ingredientes crudos y tú cocinas en tu mesa. El camarero (servidor) solo trae la caja. Rápido de montar, pero el cliente espera.
- SSR = el chef cocina el plato en el momento para cada comensal. Siempre fresco, pero la cocina se satura en hora punta.
- SSG = comida preparada por la mañana y servida al instante. Rapidísimo, pero si cambias la receta, hay que rehacerlo todo.
- ISR = buffet que se reabastece cada X minutos sin cerrar el restaurante. Equilibrio entre frescura y velocidad.
Fórmulas clave
TTFB (Time To First Byte):
TTFB = T_red + T_servidor + T_render_inicial
LCP (Largest Contentful Paint):
LCP ≈ TTFB + T_descarga_HTML + T_descarga_recursos + T_render_bloqueante
Coste de hidratación (CSR/SSR):
T_hidratación = N_componentes × T_por_componente
Ejemplo real: una PDP con 180 componentes React puede tardar ~1,2 s solo en hidratar en un móvil de gama media (Moto G Power, 4G).
Fórmula de indexación útil:
Páginas_indexadas = Páginas_rastreadas × (1 - Tasa_descarte)
Si tu CSR deja el HTML vacío, la tasa de descarte sube y Google puede indexar solo el 30-50 % de tu catálogo.
Comparativa de estrategias
| Estrategia | Dónde se renderiza | TTFB | SEO | Ideal para | Riesgo principal |
|---|---|---|---|---|---|
| **CSR** | Navegador | Bajo (HTML vacío) | Pobre sin prerender | Apps internas, paneles | Catálogo no indexado |
| **SSR** | Servidor por request | Medio (200-500 ms) | Excelente | PDP dinámicas, stock en vivo | Coste servidor alto |
| **SSG** | Build time | Muy bajo (<100 ms) | Excelente | Home, blogs, landings | Contenido obsoleto |
| **ISR** | Build + revalidación | Muy bajo | Excelente | PLP con miles de SKUs | Stale content si mal configurado |
| **Edge SSR** | CDN edge | Bajo (50-150 ms) | Excelente | Personalización geográfica | Complejidad de caché |
Aplicación en DTC/eCommerce
1. Home y landings de campaña → SSG + ISR
Cámbialas cada 10-30 min. Un build estático servido desde CDN logra TTFB de ~80 ms y LCP < 1,8 s. En Black Friday, esto marca la diferencia entre aguantar 50 k visitas/minuto o caerse.
2. PLP (Product Listing Pages) → ISR con revalidación de 60 s
Con 5.000 SKUs, un SSR puro te obliga a escalar servidores. Con ISR revalidas solo las categorías visitadas: reduces coste de cómputo hasta un 70 % manteniendo frescura de stock.
3. PDP (Product Detail Page) → SSR o Edge SSR
Necesitas precio, stock y variantes en tiempo real. Aquí el SEO manda: Googlebot debe ver el <title>, el JSON-LD de Product y el precio sin ejecutar JS. Edge SSR en Cloudflare/Vercel baja TTFB a ~120 ms desde Madrid o Ciudad de México.
4. Checkout y cuenta → CSR
No necesitan SEO y sí mucha interactividad. Aíslalos del resto del sitio para que su JS no bloquee el catálogo.
5. Blog y guías de compra → SSG
Contenido que cambia poco, con enorme valor SEO long-tail. Rebuild programado semanal.
Errores comunes
1. "Con React ya tengo SEO" — Falso. Un SPA sin SSR/SSG entrega HTML vacío. Google puede renderizarlo, pero con retraso y menor presupuesto de rastreo.
2. Confundir SSR con caché — SSR sin CDN delante es un cuello de botella. Cada visita golpea tu servidor.
3. ISR sin fallback bien definido — El usuario ve un 404 en un SKU nuevo hasta la revalidación.
4. Hidratación masiva — Enviar 800 KB de JS a un móvil 4G mata el INP (Interaction to Next Paint). Usa islas o componentes servidor.
5. Ignorar el stale-while-revalidate — Es la cabecera que convierte ISR en magia; sin ella, pierdes el beneficio.
6. Renderizar el precio solo en cliente — Googlebot puede no verlo. El precio debe ir en el HTML inicial (riesgo de cloaking si se hace mal, pero es la práctica correcta).
7. No medir por dispositivo — Un LCP de 1,2 s en desktop puede ser 3,8 s en móvil. Segmenta siempre.
Datos concretos de referencia
- Amazon reportó que cada 100 ms de latencia le costaban 1 % de ventas.
- Google confirma que el 53 % de los usuarios móviles abandona si la carga supera 3 s.
- Un sitio DTC migrado de CSR a ISR suele ver +15-25 % en tráfico orgánico en 90 días por mejor indexación de PLP.
Términos relacionados
- Core Web Vitals (LCP, INP, CLS)
- Hydration e Islands Architecture
- CDN y Edge Computing
- TTFB, FCP, LCP
- Crawl Budget y Render Budget
- Jamstack y Headless Commerce
- React Server Components (RSC)
- Streaming SSR y Partial Prerendering (PPR)
Resumen operativo: para una tienda DTC, la combinación ganadora en 2024-2025 es SSG/ISR para catálogo y contenido, SSR/Edge SSR para PDP y búsqueda, y CSR aislado para checkout y cuenta. Mide siempre por dispositivo y por plantilla, no por sitio global.
