Cómo migrar un E‑commerce a Next.js para mejorar el Core Web Vitals (y duplicar tus conversiones en 2026)
Administrador
LegacyMark
Administrador
LegacyMark

Por el equipo editorial de LegacyMark BIC S.A.S
Hay una verdad que duele, pero hay que decirla: tu e-commerce lento te está costando ventas todos los días.
En 2026, Google no solo premia la velocidad. La exige. Los Core Web Vitals (LCP, CLS, INP) son factores de ranking confirmados y, para e-commerce, son prácticamente un filtro de entrada a la primera página de resultados.
Pero hay una solución que está revolucionando el rendimiento de las tiendas online: Next.js, el framework de React que se ha convertido en el estándar de facto para e-commerce de alto rendimiento.
En este artículo te explicamos, con tablas y pasos concretos, por qué migrar a Next.js, cómo hacerlo sin morir en el intento y qué resultados reales puedes esperar en términos de Core Web Vitals, SEO y conversiones.
Primero, entendamos el problema. La mayoría de los e-commerces tradicionales (especialmente los construidos con plantillas pesadas de Shopify sin optimizar, WooCommerce con plugins excesivos o Magento sin tuning) tienen graves problemas de rendimiento.
Problema común | Causa | Consecuencia |
|---|---|---|
LCP (Largest Contentful Paint) > 4 segundos | Tiempo de respuesta del servidor lento, JS pesado | Google te penaliza, usuarios abandonan |
CLS (Cumulative Layout Shift) > 0.25 | Elementos que se mueven mientras carga | Experiencia frustrante, pérdida de confianza |
INP (Interaction to Next Paint) > 500ms | JavaScript bloqueante, eventos lentos | El usuario siente que el sitio "no responde" |
Next.js resuelve estos tres problemas de raíz gracias a su arquitectura:
Característica de Next.js | Cómo mejora Core Web Vitals |
|---|---|
Server Side Rendering (SSR) | El servidor envía HTML ya listo → LCP se reduce drásticamente |
Static Site Generation (SSG) | Páginas pre-construidas que se sirven desde CDN → LCP < 1 segundo |
Image Optimization nativa | Imágenes en WebP/AVIF, lazy loading, sizes automáticos → LCP y CLS controlados |
Code Splitting automático | Solo carga el JavaScript que necesita cada página → INP < 200ms |
Font Optimization | Fuentes sin layout shift → CLS prácticamente 0 |
Aquí tienes una tabla comparativa basada en mediciones reales de migraciones que hemos realizado en [Nombre de tu Agencia] :
Métrica | E‑commerce tradicional (WooCommerce sin optimizar) | E‑commerce con Next.js bien implementado | Diferencia |
|---|---|---|---|
LCP (Desktop) | 3.8 - 5.2 segundos | 0.9 - 1.6 segundos | 3x - 5x más rápido |
LCP (Móvil) | 5.5 - 8.0 segundos | 1.2 - 2.5 segundos | 3x - 4x más rápido |
CLS | 0.35 - 0.65 | 0.01 - 0.08 | Prácticamente cero |
INP | 450 - 800 ms | 80 - 180 ms | 4x - 5x más rápido |
Tiempo hasta interactivo (TTI) | 4.5 - 7 segundos | 1.0 - 2.2 segundos | 3x más rápido |
Puntuación PageSpeed Insights (móvil) | 25 - 45 | 85 - 98 | Diferencia abismal |
Impacto real en negocio: Mejorar LCP de 4 segundos a 1.5 segundos aumenta la tasa de conversión entre un 15% y un 35% según estudios de 2026. Para un e-commerce que factura $100,000 mensuales, eso representa entre $15,000 y $35,000 adicionales sin invertir un peso más en tráfico.
No todo e-commerce necesita Next.js. Aquí la tabla para que tu cliente (o tú) tomen la decisión correcta:
Situación | ¿Migrar a Next.js? | Alternativa recomendada |
|---|---|---|
E‑commerce pequeño (< 100 productos, < 10,000 visitas/mes) | ❌ No | Optimiza tu plataforma actual (buen hosting, caché, imágenes) |
E‑commerce mediano (100-5,000 productos, 10k-100k visitas/mes) | ✅ Sí | Migración gradual (primero categorías, luego productos) |
E‑commerce grande (> 5,000 productos, > 100k visitas/mes) | ✅ Sí (urgente) | Migración completa con arquitectura híbrida (SSG + SSR) |
E‑commerce con catálogo que cambia cada hora (ej. entradas, vuelos) | ⚠️ Depende | Considera SSR + ISR (Incremental Static Regeneration) |
E‑commerce en Shopify sin posibilidad de salir | ❌ No | Optimiza Shopify con secciones personalizadas y apps de rendimiento |
E‑commerce con equipo técnico interno limitado | ⚠️ Precaución | Next.js requiere expertise. Contrata una agencia especializada |
Aquí va el plan estratégico que usamos en [Nombre de tu Agencia] . No es mágico, es probado.
Actividad | Herramienta | Entregable |
|---|---|---|
Medir Core Web Vitals actuales | PageSpeed Insights, Lighthouse, Web Vitals extension | Línea base de rendimiento |
Auditar funcionalidades del e‑commerce actual | Inventario manual | Lista de "debe tener" vs "nice to have" |
Definir arquitectura Next.js (SSG, SSR, ISR) | Análisis de cada tipo de página | Mapa técnico de renderizado |
Tipos de páginas y estrategia recomendada:
Tipo de página | Estrategia Next.js | Por qué |
|---|---|---|
Home | SSG (Static Generation) | No cambia cada minuto, máxima velocidad |
Categorías | ISR (Incremental Static Regeneration, cada 1 hora) | Catálogo actualizado sin perder velocidad |
Productos | ISR (cada 10-30 minutos) | Stock y precios actualizados, pero rápido |
Carrito / Checkout | CSR (Client Side Rendering) o SSR | Requiere datos del usuario en tiempo real |
Blog | SSG | Contenido estático, máxima velocidad |
Búsqueda | SSR con debounce | Necesita datos actualizados |
Actividad | Herramienta recomendada |
|---|---|
Crear proyecto Next.js (App Router, no Pages Router) |
|
Configurar TypeScript |
|
Configurar Tailwind CSS o CSS Modules | Tailwind CSS + PostCSS |
Configurar ESLint y Prettier | Estándar Next.js |
Configurar variables de entorno |
|
Componente | Consideraciones para Core Web Vitals |
|---|---|
Header | Evitar layout shift (CLS), usar height fijo mientras carga |
Footer | Carga diferida (no crítico) |
Grid de productos | Lazy loading de imágenes con |
Menú de categorías | Pre-carga de hover |
Modal de producto rápido | Carga dinámica solo cuando se activa |
Tu e-commerce necesita datos. Next.js se conecta con cualquier backend vía API.
Backend original | Conexión con Next.js |
|---|---|
WooCommerce (WordPress) | API REST de WooCommerce + WPGraphQL |
Shopify | Storefront API + SDK de Shopify |
Magento | API REST de Magento |
Custom (Node, Laravel, Django) | API propia + fetch en |
Headless (Commerce.js, Saleor, Medusa) | SDK nativos, más fácil |
Ejemplo de código (simplificado) para obtener productos en Next.js App Router:
javascript
// app/productos/page.js
export const revalidate = 3600 // ISR cada 1 hora
async function getProducts() {
const res = await fetch('https://tu-api.com/products')
return res.json()
}
export default async function ProductsPage() {
const products = await getProducts()
return (
<div className="grid">
{products.map(product => (
<ProductCard key={product.id} product={product} />
))}
</div>
)
}Aquí es donde se gana la carrera:
Acción | Impacto en Core Web Vitals |
|---|---|
Usar | LCP -40% |
Configurar | CLS -100% |
Implementar | INP -30% |
Usar | TTI -50% |
Configurar CDN (Vercel, Netlify, CloudFront) | LCP -60% en geografías lejanas |
Tipo de prueba | Herramienta | Criterio de aprobación |
|---|---|---|
Core Web Vitals en entorno de staging | PageSpeed Insights, Lighthouse CI | LCP < 2.5s, CLS < 0.1, INP < 200ms |
Pruebas de carga (100-1000 usuarios concurrentes) | K6, Artillery | Tiempo de respuesta < 500ms |
Pruebas de integración (checkout, pago, APIs) | Jest + React Testing Library | Sin errores críticos |
Despliegue en producción | Vercel (recomendado), Netlify, AWS Amplify | Rollback automático si falla |
Error | Consecuencia | Solución |
|---|---|---|
Usar | Matas la velocidad. Cada visita es una consulta a la base de datos. | Usa SSG e ISR por defecto. SSR solo cuando es estrictamente necesario. |
No optimizar imágenes | Siguen pesando y matan LCP. |
|
Ignorar el tamaño del bundle | INP por las nubes. | Usa |
Migrar todo de una vez | El sitio queda días sin funcionar. | Migración incremental. Primero blog, luego categorías, luego productos, luego checkout. |
No tener plan de rollback | Si algo falla, pierdes ventas. | Mantén el sitio viejo funcionando en paralelo durante 2 semanas. |
No medir antes y después | No sabes si mejoraste. | Guarda métricas de Core Web Vitals antes de empezar. |
No todos los hosts tratan igual a Next.js. Aquí la tabla definitiva:
Plataforma | Ventajas | Desventajas | Precio (2026) | Ideal para |
|---|---|---|---|---|
Vercel | Creadores de Next.js, CDN global, ISR nativo, despliegue automático | Costoso en tráfico alto | $20 - $500+ /mes | La mayoría de e‑commerces |
Netlify | Similar a Vercel, muy estable | ISR menos maduro | $19 - $450+ /mes | Alternativa sólida |
AWS Amplify | Escalabilidad masiva | Configuración compleja | Pago por uso | E‑commerces gigantes |
Cloudflare Pages | Muy económico, red enorme | Funciones de Next.js limitadas | $0 - $200+ /mes | Proyectos pequeños |
Self-hosted (Docker + CDN) | Control total | Requiere equipo DevOps | $50 - $1000+ /mes | Casos muy específicos |
Recomendación 2026: Empieza con Vercel. Es el hosting nativo de Next.js, te da las mejores métricas de Core Web Vitals sin configuración adicional.
Cliente: E‑commerce de moda deportiva, 3,500 productos, 80,000 visitas/mes.
Situación inicial (WooCommerce + Elementor + hosting compartido):
Métrica | Valor inicial |
|---|---|
LCP (móvil) | 6.2 segundos |
CLS | 0.48 |
INP | 720 ms |
PageSpeed Insights (móvil) | 32 |
Tasa de conversión | 1.8% |
Ingresos mensuales | $180,000 |
Migración a Next.js (con nuestra agencia):
Duración: 6 semanas
Inversión: $18,000 USD
Hosting: Vercel Pro ($200/mes)
Resultados a los 3 meses:
Métrica | Después de migrar | Mejora |
|---|---|---|
LCP (móvil) | 1.4 segundos | -77% |
CLS | 0.03 | -94% |
INP | 120 ms | -83% |
PageSpeed Insights (móvil) | 94 | +62 puntos |
Tasa de conversión | 2.9% | +61% |
Ingresos mensuales | $289,000 | +$109,000/mes |
ROI de la migración: Inversión recuperada en menos de 6 días. Beneficio adicional de $1.3 millones anuales.
Framework / Plataforma | Core Web Vitals potencial | Curva de aprendizaje | Ideal para |
|---|---|---|---|
Next.js | Excelente (85-98 en PSI) | Media-alta | E‑commerces que buscan el mejor rendimiento |
Gatsby | Bueno (75-90) | Media | Sitios con poco cambio (catalogo estático) |
Remix | Muy bueno (80-95) | Media-alta | E‑commerces con mucho dinamismo |
Nuxt (Vue) | Muy bueno (80-95) | Media | Equipos que prefieren Vue sobre React |
Shopify (Hydrogen) | Bueno (70-85) | Baja | Tiendas Shopify que quieren headless |
WooCommerce tradicional | Pobre (25-50) | Baja | Presupuesto mínimo, sin exigencias de rendimiento |
En 2026, la velocidad es el nuevo marketing. Un e-commerce lento no es un problema técnico: es un problema de negocio. Te está costando posicionamiento, te está costando conversiones y te está costando clientes.
Next.js no es una moda. Es la herramienta más probada para resolver los Core Web Vitals de raíz. Pero ojo: no es suficiente con "usar Next.js". Hay que implementarlo bien. Con la arquitectura correcta, las optimizaciones necesarias y un hosting adecuado.
En LegacyMark BIC S.A.S no solo migramos tu e-commerce a Next.js. Te garantizamos resultados medibles en Core Web Vitals y conversiones. Porque al final del día, no se trata de tecnología. Se trata de vender más.
¿Tu e-commerce está perdiendo ventas por culpa de la velocidad?
Hablemos de tu migración a Next.js. Te haremos un diagnóstico gratuito de tus Core Web Vitals.
Escrito por
Especialista en marketing digital y estrategia de contenidos. Apasionado por ayudar a marcas a crecer en el mundo digital.
He visto casos donde una tienda con 50 productos gastó $15,000 en migrar a Next.js y sus conversiones apenas mejoraron un 5% porque su problema real era otro: mala experiencia de checkout, fotos de mala calidad o precio no competitivo. También he visto e‑commerces en WooCommerce bien optimizados (caché, CDN, imágenes, hosting dedicado) que logran LCP de 2 segundos y convierten muy bien. Sin tocar Next.js. ¿En qué casos crees que realmente vale la pena invertir en Next.js? ¿Y cuándo es mejor optimizar lo que ya tienes?
Recibe los últimos artículos y novedades en tu inbox.