Checkout lento en WooCommerce: qué revisar

Síntomas

• Varios segundos entre pulsar Realizar pedido y la página de agradecimiento o de pago.
• El resumen del pedido se queda cargando cada vez que el cliente cambia la dirección, el método de envío o la cantidad.
• El checkout va rápido de noche y lento en las horas de más tráfico.
• Errores 502 o 504 ocasionales en el checkout con carga.

Causas más comunes

1. Llamadas externas durante el checkout: tarifas de envío en tiempo real, servicios de cálculo de impuestos, validación de direcciones, puntuación antifraude, consultas de stock al ERP, comprobaciones de licencia.
2. Trabajo hecho al crear el pedido: emails transaccionales enviados por un servidor de correo lento, envíos síncronos al CRM o al ERP, generación de facturas en PDF.
3. Consultas lentas a la base de datos: tablas de meta enormes, una tabla de sesiones grande, consultas a medida sin índices y ninguna caché de objetos persistente.
4. Demasiadas actualizaciones: cada cambio de campo dispara una actualización del resumen del pedido que vuelve a ejecutar todo lo anterior.
5. Procesos PHP agotados: las peticiones lentas ocupan el pool de PHP-FPM y las nuevas peticiones del checkout esperan en cola.

Diagnóstico

1. Mide las peticiones correctas

Abre el panel de red y recorre un checkout. Anota el tiempo hasta el primer byte (TTFB) de:

• ?wc-ajax=update_order_review (checkout clásico, en cada actualización)
• ?wc-ajax=checkout (checkout clásico, Realizar pedido)
• /wp-json/wc/store/v1/cart/... y /wp-json/wc/store/v1/checkout (bloque de Checkout)

Un update_order_review lento apunta a envíos, impuestos y totales; un checkout lento apunta a la creación del pedido, al pago y a todo lo que se engancha a ellos.

2. Desglosa el tiempo en staging

En una copia de staging con datos parecidos a los de producción, usa Query Monitor para ver, en la petición lenta, las consultas a la base de datos (las más lentas y las duplicadas), las llamadas a la HTTP API con su duración y los hooks que se ejecutan. Las llamadas externas suelen saltar a la vista enseguida.

3. Encuentra las peticiones lentas en producción

Activa el slow log de PHP-FPM (request_slowlog_timeout, por ejemplo 5 segundos). Para cada petición que lo supere, PHP-FPM escribe la traza del punto donde el código estaba esperando: a menudo un curl_exec() dentro de un plugin de envíos o del ERP.

4. Revisa la parte de la base de datos

Mira el slow query log, el tamaño de la tabla de sesiones, las opciones con carga automática y si hay una caché de objetos persistente (Redis o Memcached) activa y realmente utilizada.

Registros y comprobaciones técnicas

• Tiempos del panel de red para las peticiones del checkout.
• Query Monitor en staging: consultas, llamadas a la HTTP API, hooks.
• Slow log y página de estado de PHP-FPM.
• Slow query log de MySQL.
• Registros de correo o del plugin SMTP en busca de envíos lentos en el momento del pedido.
• Herramientas → Acciones programadas para el trabajo en segundo plano que se queda atrás.

Soluciones

• Cachea o reduce las llamadas externas: cachea las respuestas de transportistas e impuestos cuando sus condiciones lo permitan, añade timeouts y evita llamar a servicios en cada cambio de campo.
• Saca trabajo de la petición del pedido: lleva las sincronizaciones con ERP y CRM a Action Scheduler; difiere los emails transaccionales o envíalos por un relay rápido.
• Añade una caché de objetos persistente y asegúrate de que los datos del checkout no se vacían en cada petición.
• Arregla las consultas lentas: índices para las búsquedas a medida, limpieza de sesiones caducadas y de opciones con carga automática demasiado grandes.
• Dimensiona PHP-FPM para el tráfico real, según la memoria por proceso y la concurrencia en los picos.

// Envía los emails transaccionales de WooCommerce después de la respuesta, no durante el checkout.
add_filter( 'woocommerce_defer_transactional_emails', '__return_true' );

Qué no hacer

• No cachees el checkout ni el carrito para que «vayan rápido»: rompe sesiones, nonces y totales.
• No instales un segundo plugin de caché: no se aplica al checkout.
• No quites plugins de envíos o de impuestos sin revisar las reglas de negocio que aplican.
• No cambies de hosting antes de medir dónde se va el tiempo.

Cuándo recurrir a un experto

Recurre a un ingeniero cuando la parte lenta está dentro de un plugin o de código a medida que no puedes cambiar con seguridad, cuando la lentitud solo aparece con tráfico real, o cuando empiezan a aparecer errores en el checkout (502/504) en las horas punta.

Problemas relacionados

• WooCommerce / Rendimiento Problemas con Action Scheduler en WooCommerce Acciones programadas vencidas, fallidas y atascadas: cómo funciona la cola, por qué se detiene y cómo arreglarlo sin perder trabajo pendiente. →
• WooCommerce / Checkout El checkout de WooCommerce no funciona: cómo diagnosticar la causa raíz Determina primero si el fallo ocurre antes de la petición del checkout, durante ella o después de la respuesta de la pasarela. El panel de red y los registros PHP suelen revelar qué capa falla. →
• WooCommerce / Errores Conflicto de plugins en WooCommerce: cómo encontrar la causa Parte de las evidencias (el error, el momento, la petición) y aísla en staging por mitades, no plugin a plugin en producción. →

Preguntas frecuentes