Comercio electrónico con Next.js

El comercio es donde el modelo de renderizado de Next.js se gana el sueldo, y donde equivocarse sale más caro. Una ficha de producto que tarda tres segundos no convierte, y todas las plantillas de tienda que hemos heredado tomaron la misma decisión de arquitectura: un use client arriba del todo, porque el carrito necesita estado.

Esa decisión vuelve el catálogo -la parte que debería ser estática, cacheada en el edge e indexable- tan dinámica como el checkout.

Cómo lo separamos

El catálogo es estático. Fichas de producto, colecciones y páginas de aterrizaje de búsqueda se generan en el build o se revalidan por etiqueta cuando el backend avisa de que algo cambió. Salen del CDN, son indexables, y su LCP no depende de que tu API de comercio esté despierta.

El carrito es una isla de cliente. Un componente pequeño, no una frontera alrededor de la página. Cantidad, mini-carrito y añadir al carrito son interactivos; la descripción, las imágenes, las reseñas y los datos estructurados que hay alrededor no lo son y se quedan en el servidor.

Precios y stock son la excepción, tratada a propósito. No pueden quedarse obsoletos y tampoco pueden volver dinámica la página. O llegan por streaming detrás de Suspense mientras el resto se pinta, o se revalidan por etiqueta con el webhook del backend. Cuál de las dos depende de con qué frecuencia se mueven tus precios de verdad: preguntamos en vez de suponer.

El checkout se queda donde está. Si estás en Shopify, su checkout alojado cumple PCI, convierte bien y no merece reconstruirse. Integramos hasta ahí. Un checkout propio es un proyecto aparte y te diremos cuándo no está justificado - y cuando lo está, se construye sobre un reparto de confianza que no incluye al navegador y una página de vuelta que sobrevive al redirect.

Qué hacemos con las partes que deciden los ingresos

Datos estructurados Product con Offer real y disponibilidad, para que los resultados enriquecidos muestren un precio. Canónicos correctos entre URLs de variantes y filtros: un catálogo facetado genera miles de direcciones casi duplicadas, y a su aire se gastan tu presupuesto de rastreo en combinaciones de parámetros que nadie busca.

Core Web Vitals tratados como métrica de comercio y no de ingeniería, medidos en las plantillas que llevan tráfico, con un presupuesto impuesto en CI para que el siguiente cambio de tema no lo deshaga.

Qué backend

Shopify (Storefront API), Commerce Layer, Medusa, BigCommerce o tu propio servicio. La arquitectura de la tienda es la misma en todos los casos; lo que cambia es la capa de datos, y es la parte que tipamos y cacheamos con cuidado.

Si estás en los temas propios de Shopify y te planteas una tienda headless, la respuesta honesta es que merece la pena cuando tienes un equipo de front real o nos tienes a nosotros, y no merece la pena cuando no. Un tema Liquid bien mantenido gana a una tienda headless que no es de nadie.

Cómo se desarrolla un encargo

Arrancamos desde los ingresos y no desde la arquitectura. Qué plantillas llevan el tráfico, dónde pierde gente el embudo, y qué hace imposible la plataforma actual.

El alcance que sigue nombra el backend, la lista de plantillas, el mapa de URL con su plan de redirecciones, y el presupuesto de rendimiento, con precio por fase. Se firma antes de empezar a construir. El mapa de URL en particular se acuerda de antemano, porque un cambio de plataforma que descubre tarde sus redirecciones ya ha perdido las posiciones.

Después el desarrollo, desplegado por fases, con el presupuesto aplicado en CI desde la primera.

Qué recibes

El storefront, la capa de datos tipada contra su backend de comercio, el mapa de URL con sus redirecciones, y el presupuesto de rendimiento corriendo en CI sobre las plantillas que llevan el tráfico.

Además, las partes que nadie enseña en una demo: la estrategia de caché por plantilla escrita, qué hace la página cuando el backend está lento o caído, y las reglas de facetado que deciden a qué combinaciones de parámetros puede llegar un rastreador.

Los dos números que mueven ingresos en comercio están en las plantillas que llevan el tráfico. El LCP, que en una página de producto es casi siempre la imagen. Y el resto de Core Web Vitals, medido sobre visitantes reales y no en laboratorio. Las facetas, la paginación y las URL con parámetros son la otra mitad, y mantenerlas fuera del índice es estructural, no un ajuste.