OpenCart y Next.js: una cuestión de escaparate

OpenCart ya le da lo que las plataformas alojadas cobran: el catálogo, el carrito, el checkout, sus datos en su servidor, y ningún porcentaje por pedido. Nada de eso está en cuestión aquí, y ninguna parte de esta página sugiere sustituirlo.

Lo que sí está en cuestión es más estrecho. OpenCart también renderiza su escaparate, y esa es la única parte de la que trata esta decisión.

Lo que la plantilla hace bien

Para una tienda que es una tienda, la ruta de renderizado por defecto está bien. Páginas de producto, de categoría, búsqueda, carrito. Es HTML renderizado en servidor, es cacheable, y una plantilla mantenida sobre alojamiento decente va rápida.

Si eso describe su sitio, el front no es su problema, y una reconstrucción le daría una página parecida a un coste considerable. Mida antes de decidir otra cosa.

La medición que va primero

Coja las plantillas que llevan ingresos. Portada, una categoría, una página de producto. Lea datos de campo, no una puntuación de laboratorio.

Las causas de una página lenta son concretas y no son muchas. En un escaparate PHP la respuesta es muy a menudo una imagen principal que el navegador descubre tarde, una webfont que bloquea el pintado, y unos cuantos scripts añadidos con los años para analítica y chat. Son arreglos a nivel de plantilla, llevan alrededor de una semana, y cuestan una pequeña fracción de sustituir el front.

Haga eso primero. Si los números salen bien, ya tiene su respuesta, y no involucró a ningún framework.

Dónde el front necesita cambiar de verdad

Hay una frontera real, y no es la velocidad.

Es cuando el escaparate tiene que hacer cosas para las que una plantilla no es buen contenedor. Un configurador con interacción real. Filtrado sobre un catálogo grande que tiene que ser rápido y enlazable. Un área con sesión y comportamiento propio. Un sistema de diseño compartido con algo que no es la tienda. Contenido que merece su propia estrategia de renderizado en vez de ser una página de CMS atornillada a un carrito.

En ese punto la pregunta deja de ser el rendimiento y pasa a ser qué es el front. El modelo de renderizado es lo primero que hay que entender, porque decidir qué rutas son estáticas, cuáles revalidan y cuáles son dinámicas es la mayor parte del diseño.

Cómo encaja todo

OpenCart conserva el catálogo, el carrito, el checkout y el panel. Next.js renderiza el escaparate y habla con OpenCart por su API REST, normalmente con una capa fina por delante, porque esa API está formada alrededor del carrito y no alrededor de ser una fuente de contenido general.

El checkout se queda donde está en la mayoría de versiones de esto. Las integraciones de pago y la gestión de pedidos ya funcionan, y moverlas es una decisión aparte con su propio riesgo.

El movimiento va ruta a ruta. Primero las plantillas con tráfico, el resto todavía servido por OpenCart, y una nota escrita de qué sistema responde a qué URL. Así acotamos este tipo de trabajo, y el mapa de URL es lo primero que se acuerda, no lo último.

Cuándo dejarlo en paz

Una tienda que es una tienda. Nadie dentro que escriba JavaScript. Productos que rotan más rápido que el código. Un conjunto de extensiones que funciona y que alguien entiende.

Una plantilla que alguien mantiene gana a un escaparate que nadie posee, y lo segundo es lo que tiene doce meses después de una reconstrucción sin entrega.