Cómo construí un configurador de autos para el MG IM6 en una semana

Me pidieron un configurador para el MG IM6, el SUV eléctrico de IM Colombia: elegir versión, color exterior, interior y opciones, ver el auto desde varios ángulos y enviar el interés como lead. El plazo era corto y el sitio ya estaba en WordPress. Esta es la historia de cómo lo resolví sin cargar el proyecto de librerías.

El reto: un configurador que no pese

Un configurador suele terminar en un framework pesado. Yo quería lo contrario: que cargara rápido, no rompiera el resto del sitio y fuera fácil de mantener. La meta era cero dependencias externas en el front del configurador y que aportara al Core Web Vitals en lugar de restarle.

Arquitectura: un child theme, HTML/CSS/JS puro

Lo empaqueté como un child theme de WordPress. Así el configurador vive dentro del sitio, hereda el diseño y no depende de un plugin que mañana falle en una actualización. El núcleo es un panel de varios pasos escrito en JavaScript vanilla, sin build.

• Versión del vehículo.
• Color exterior.
• Color interior.
• Opciones y paquetes.

El panel se inicializa solo cuando el DOM está listo, para no pelear con el JavaScript diferido del sitio:

document.addEventListener('DOMContentLoaded', () => {
  Configurador.init({ version: 'default', color: 'blanco' });
});

El carrusel por ángulo y color

La parte visual era un carrusel que cambia la imagen según el ángulo seleccionado y el color activo. Precargué solo lo necesario y definí dimensiones explícitas en cada imagen para evitar saltos de layout (CLS). Las specs de cada versión se cargan en pestañas dinámicas, sin recargar la página.

El puente con Contact Form 7 y el DMS

Cuando el usuario termina de configurar, el estado se traduce en un lead. Monté un puente hacia Contact Form 7 que arma el mensaje con la configuración elegida y lo integra con el DMS del cliente. El formulario queda con contexto real, no un “quiero información” genérico.

El problema que ya esperaba: LiteSpeed Cache

Por experiencia previa, sabía que el caché iba a morder. Con LiteSpeed activo, partes del JS se servían en un estado que rompía el paso a paso. Lo resolví excluyendo los recursos del configurador de la optimización agresiva y verificando el orden de carga. Regla personal: cuando algo “funciona en local pero no en producción”, el primer sospechoso es el caché.

Lo que me llevo

Menos dependencias significó menos superficie para que algo se rompiera y un sitio más rápido. La parte difícil no fue el JavaScript: fue la integración con lo que ya existía (tema, formulario, DMS, caché). En proyectos reales, el 80% del trabajo es que las piezas convivan.

Preguntas frecuentes

¿Por qué no usaste un framework para el configurador?

Porque el sitio ya estaba en WordPress y el plazo era corto. Un framework habría añadido peso y un paso de build. Con HTML, CSS y JS puros el configurador carga rápido y es fácil de mantener.

¿Cómo evitas los saltos de layout (CLS) con tantas imágenes?

Definiendo width y height explícitos en cada imagen y precargando solo la vista inicial. El resto se carga de forma diferida a medida que el usuario cambia de ángulo o color.

¿El configurador afecta la velocidad del sitio?

No si se aísla del caché correctamente y se sirven las imágenes optimizadas. En este caso el objetivo era sumar a Core Web Vitals, no restarle.