Rendimiento del checkout en Magento 2: arreglar la página más lenta que tiene

El checkout es la única página de su tienda en la que cada milisegundo tiene una cifra de ingresos directamente atribuible. Un comprador que abandona una página de categoría lenta puede volver. Un comprador que abandona en el paso de pago con el carrito lleno normalmente no vuelve.

También es la página que Magento menos optimiza. El checkout no se puede cachear con la full-page cache —es completamente específico de cada cliente por definición—, así que ninguno de los trucos que hacen rápido su catálogo está disponible aquí. Lo que hay en su lugar es una aplicación JavaScript pesada arrancando desde cero, y después una serie de llamadas AJAX secuenciales antes de que el comprador pueda hacer nada.

Este es el último artículo de una serie que cubre el rendimiento a nivel de sitio, las páginas de categoría y las páginas de producto.

El problema de Knockout, dicho sin rodeos

El checkout por defecto de Luma en Magento es una aplicación de una sola página en Knockout.js. Cargarlo significa: descargar el grafo de dependencias de RequireJS, resolver y ejecutar decenas de módulos, inicializar los view models de Knockout, y después pedir el quote, los métodos de envío, los métodos de pago y la libreta de direcciones del cliente, varios de ellos en secuencia y no en paralelo.

En un móvil de gama media sobre una red real, esa secuencia de arranque suele tardar varios segundos antes de que el formulario de envío sea utilizable. No es una cosa lenta que se pueda arreglar; es la arquitectura.

Tiene tres opciones generales, y conviene ver los intercambios con claridad en lugar de fingir que la optimización lo resuelve todo.

Optimizar el checkout de Luma tal cual. Realista, y la decisión correcta para muchas tiendas. Puede reducir el coste de arranque de forma significativa, pero no llegará a un checkout rápido: llegará a uno tolerable.

Sustituirlo por un checkout construido para ello. Hyvä Checkout, o una de las varias extensiones de checkout en una página, sustituye el stack de Knockout por algo mucho más ligero. Es la mayor mejora disponible, y es un proyecto de licencia más integración, sobre todo si tiene lógica de pago o de envío a medida.

Reconstruirlo headless. Control total, la respuesta correcta para algunos negocios, un compromiso serio para la mayoría. No tome este camino solo por rendimiento.

Qué arreglar dentro del checkout de Luma

Si se queda en el checkout por defecto, estas son las palancas que importan de verdad.

Recorte la cadena inicial de peticiones

Abra el panel Network en su checkout y mire la cascada. Busca peticiones que ocurren en secuencia cuando podrían ocurrir en paralelo, y peticiones que ocurren cuando no hace falta que ocurran.

Los hallazgos habituales:

• La llamada de estimate-shipping-methods disparándose antes de que el comprador haya introducido una dirección. Muchos temas la lanzan al cargar con un país por defecto, y otra vez cuando se introduce la dirección real. La primera llamada es desperdicio puro, y a menudo es la petición más lenta de la página.
• Métodos de pago cargados antes de completar el paso de envío. El comprador todavía no puede verlos. Difiéralos.
• Varias llamadas separadas a /rest/V1/carts/mine/... que podrían agruparse.

Audite su cálculo de tarifas de envío

Es la causa individual más habitual de un checkout realmente lento, y normalmente no es culpa de Magento.

Cada transportista activo se consulta al estimar las tarifas. Los transportistas en tiempo real (UPS, FedEx, DHL y la mayoría de las extensiones de comparación de tarifas) hacen una llamada a una API externa. Si tiene cuatro transportistas en vivo y cada uno tarda 600 ms, y se consultan en secuencia, su comprador espera 2,4 segundos mirando un spinner, y si la API de uno de ellos tiene un mal día, todo el checkout se queda parado.

Qué hacer:

• Ponga timeouts agresivos a cada transportista. Un timeout por defecto de 30 segundos significa que una API degradada puede colgar todo su checkout. Cinco segundos suele ser generoso.
• Cachee las tarifas donde el transportista lo permita. Las tarifas para el mismo código postal y el mismo peso de carrito no cambian de un minuto a otro.
• Desactive los transportistas que no usa de verdad. Los transportistas de prueba que quedaron activados tras una migración son habituales.
• Monitorice los tiempos de respuesta de los transportistas como una métrica de primer nivel. Es exactamente el tipo de cosa que se degrada en silencio y a la que se culpa de que «el sitio va lento».

Revise sus tablas quote

quote, quote_item y quote_address crecen sin límite por defecto. Cada carrito abandonado, cada sesión de bot, cada invitado que añadió un artículo y se fue. En una tienda con actividad estas tablas alcanzan millones de filas, y las consultas del checkout contra ellas se ralentizan en consecuencia.

Magento tiene limpieza para esto, pero con frecuencia está mal configurada o desactivada. Revise el ajuste de vida de los quotes, verifique que el cron de limpieza está corriendo y, si las tablas ya son enormes, planifique un archivado por lotes: borrar millones de filas en una sola sentencia bloqueará la tabla y tirará la tienda, que es una forma memorable de aprender esta lección.

quote_address en particular merece un vistazo, porque acumula una fila por cada estimación de envío, así que crece más rápido que las otras.

Reglas de precio del carrito

Cada regla de precio del carrito activa se evalúa en cada recálculo del quote, que ocurre con los cambios de dirección, la selección del método de envío, la introducción de cupones y las actualizaciones de cantidad. Las reglas con condiciones complejas sobre catálogos grandes son caras, y las tiendas acumulan durante años reglas caducadas pero todavía activas.

Audite la lista de reglas activas. Desactive todo lo que haya pasado su fecha de fin, en lugar de dejarlo activado con una condición de fecha.

Scripts de pago de terceros

Los proveedores de pago envían SDKs de JavaScript, y varían enormemente en peso. Algunos cargan el SDK completo al entrar en el checkout aunque solo haga falta cuando se selecciona ese método.

Cargue los SDKs de pago bajo demanda donde el proveedor lo soporte. Donde no, al menos cárguelos de forma asíncrona para que no bloqueen el renderizado del checkout. Y mídalos: un SDK de pago que añade 400 ms a la carga del checkout es algo que conviene plantear a su proveedor, o sopesar cuando renegocie.

El formulario en sí

Algunas de las mayores mejoras del checkout no son técnicas.

Checkout como invitado, activado y visible. Obligar a crear una cuenta es, de forma consistente, uno de los mayores motivos de abandono en la investigación sobre checkout. Si necesita cuentas para precios B2B, esa es una decisión segmentada, no general.

Menos campos. Cada campo opcional que pueda eliminar es fricción eliminada. El nombre de la empresa, la segunda línea de dirección y el número de teléfono merecen cuestionarse uno a uno.

Autocompletado de direcciones, implementado con cuidado. Reduce la escritura y los errores, pero un widget de autocompletado mal integrado añade un script de terceros y un desplazamiento de layout. Reserve el espacio del desplegable.

Atributos autocomplete e inputmode correctos. Gratis, y materialmente más rápido en móvil: inputmode="numeric" en los campos de código postal y tarjeta muestra el teclado adecuado.

No valide en cada pulsación. La validación agresiva por carácter ejecuta JavaScript en cada evento de entrada y es un contribuyente real al INP en un formulario con quince campos. Valide al perder el foco.

Mida el embudo, no la página

Lighthouse sobre una URL de checkout le dice muy poco: no puede llenar un carrito, y el estado de carrito vacío no es lo que experimentan los compradores.

Mida lo real en su lugar:

• Instrumente los pasos. Tiempo desde que carga el checkout hasta que el formulario de envío es interactivo, desde la introducción de la dirección hasta que aparecen las tarifas, desde la selección del pago hasta el pedido realizado. Esos son los números que se corresponden con el abandono.
• Registre los tiempos del servidor en los endpoints REST que usa el checkout. Un estimate-shipping-methods lento aparece aquí antes de que lo reporten los clientes.
• Vigile el abandono por paso en la analítica. Un pico en el paso de envío después de un deploy es una regresión de rendimiento hasta que se demuestre lo contrario.
• Ponga alertas. El checkout es el único sitio donde una regresión de rendimiento es un incidente, no un ticket. Trátelo así.

Qué haríamos primero

En un checkout Magento lento, en este orden:

1. Cascada de red en un dispositivo real con un carrito real. Encuentre la barra más larga.
2. Timeouts de transportistas y caché de tarifas: es el culpable más habitual y a menudo la solución más rápida.
3. Tamaño de las tablas quote y cron de limpieza.
4. Diferir los SDKs de pago y eliminar la llamada de estimación de envío previa a la dirección.
5. Auditoría de reglas de precio del carrito.
6. Instrumentar el embudo, para que la próxima regresión se detecte en horas y no en trimestres.

Después, con honestidad, tenga la conversación sobre sustituir el checkout de Knockout. Los pasos 1 a 6 le darán una mejora real, y por encima de ellos hay un techo que solo un cambio de arquitectura supera. Saber dónde está ese techo —y lo que le está costando en carritos abandonados— es la diferencia entre una decisión informada y una frustración recurrente.

Emyrix trabaja en checkouts de Magento y Adobe Commerce: rendimiento, lógica de pago y envío a medida, y el soporte de emergencia para cuando el checkout se rompe en el peor momento posible. Escríbanos.