Volver al blog

Mi web carga rápido, pero el checkout no: cómo diagnosticar WooCommerce con LiteSpeed

Imagen de alojamiento optimizado para WordPress

Una portada rápida no demuestra que tu tienda cobre rápido. El catálogo puede responder desde caché mientras el checkout calcula el carrito y consulta servicios externos. Si el cliente ve una rueda de carga al introducir su dirección o pagar, primero hay que localizar qué paso espera.

Esta guía propone un diagnóstico para WooCommerce con LiteSpeed, sin cambiar ajustes a ciegas. No contiene resultados de un experimento ni promete un tiempo de compra: incluye una ficha para que puedas registrar tus propias mediciones.

Antes de tocar nada: describe el retraso

«La tienda está lenta» es demasiado amplio para decidir una solución. Escribe qué acción falla y qué sigue funcionando. Por ejemplo: «La ficha del producto abre con normalidad; al cambiar el código postal, el resumen tarda en actualizarse». Ese registro evita confundir la carga inicial con el cálculo de envío o la confirmación del pago.

  • ¿Sucede al añadir al carrito, abrir el checkout, cambiar la dirección o confirmar?
  • ¿Afecta a todos los métodos de pago o solo a uno?
  • ¿Se reproduce en móvil y escritorio?
  • ¿Comenzó después de actualizar un plugin, cambiar caché o añadir una integración?

Usa una copia de pruebas aislada para desactivar extensiones o simular pagos. Comprueba antes que esa copia no envíe correos a clientes ni ejecute automatizaciones de producción. Conserva un respaldo y una lista de ajustes originales.

1. Identifica el tipo de checkout

WooCommerce distingue el checkout clásico del basado en bloques. Sus solicitudes no son idénticas: el clásico utiliza endpoints wc-ajax y el de bloques usa la Store API. En las herramientas del navegador, abre Red/Network, filtra Fetch/XHR y observa la petición que coincide con la espera. Anota dirección, estado HTTP y duración. Si el retraso ocurre después de confirmar, revisa primero si ya existe un pedido antes de reintentar. Estos pasos se desarrollan en la guía oficial del checkout bloqueado.

El objetivo no es aprender todas las peticiones de la tienda. Basta con identificar un paso reproducible y una solicitud concreta. Guarda una captura legible sin nombres, direcciones, cookies, claves ni datos de tarjeta.

2. Separa caché de página y cálculo de compra

LiteSpeed Cache excluye por defecto las páginas de carrito, checkout y Mi cuenta en WooCommerce. Por eso, un resultado excelente al visitar el catálogo no permite deducir cómo responderá una operación dinámica. La documentación de caché de LiteSpeed describe ese comportamiento.

Comprueba si hay otras capas, como reglas de CDN o un segundo plugin de caché. Revisa las rutas realmente asignadas a tu carrito y checkout, especialmente si fueron renombradas. No actives una regla global de caché para HTML dinámico con la intención de acelerar el pago: podrías servir información incorrecta entre sesiones.

La comparación útil es entre operaciones equivalentes. Una visita anónima al inicio y un carrito con productos, cupón y transporte no constituyen dos versiones del mismo trabajo. Define primero el escenario y después compara el antes y el después.

3. Busca el error que coincide con la hora

Un error HTTP, una respuesta inesperada o una solicitud pendiente requieren investigaciones distintas. No cambies PHP, memoria, base de datos y caché a la vez. Escoge la evidencia más concreta y sigue esa pista.

En WooCommerce → Estado → Registros revisa el intervalo exacto del incidente. Algunos errores se registran automáticamente; otras extensiones requieren activar su propio registro. El informe de estado de WooCommerce permite reunir versiones y configuración relevantes.

Prepara un paquete mínimo para soporte: hora y zona horaria, paso que falla, versión de la extensión involucrada y mensaje de error. Evita enviar una exportación completa de clientes cuando basta un fragmento anonimizado. Si no aparece un error, eso también es información: el siguiente paso puede ser medir dónde se consume el tiempo.

4. Aísla JavaScript, plugins y servicios externos

En la copia de pruebas, cambia una sola variable por vez. Si sospechas de optimizaciones de JavaScript, contrasta la operación con esa optimización desactivada y conserva las demás condiciones. LiteSpeed publica una guía de diagnóstico para aislar problemas del plugin. Una corrección debe resolver el síntoma y permitir reactivar las optimizaciones que no causaban el fallo.

Si hace falta más detalle, un desarrollador puede inspeccionar consultas, llamadas HTTP y errores en el entorno de pruebas con herramientas como Query Monitor. WooCommerce lo incluye entre sus recursos oficiales de depuración. No mantengas herramientas de diagnóstico intensivo activas de forma indefinida en producción.

Considera cada integración como una hipótesis: envío, impuestos, antifraude, correo o pago. Pregunta qué llamada aparece en el intervalo lento. No atribuyas el problema al proveedor de hosting o a una pasarela solo porque participe en el proceso.

5. Si solo falla una pasarela, compruébala por separado

Revisa las notas del pedido y los registros de la extensión de pago. Utiliza su modo de pruebas en el entorno aislado y confirma que las credenciales corresponden a ese modo. La guía de errores de pago de WooCommerce recomienda revisar registros y posibles conflictos con el tema o plugins.

No conviertas una tarjeta rechazada en un pago aprobado para que el proceso parezca más rápido. Tampoco vuelvas a pulsar repetidamente el botón de compra mientras investigas. La experiencia debe distinguir pedido recibido, pago pendiente y pago confirmado.

Ficha de medición: completa tus datos reales

Elige un producto de prueba, una dirección ficticia y un método de pago de pruebas. Mantén constantes dispositivo, conexión y contenido del carrito. Realiza unas pocas comprobaciones manuales; esto no es una prueba de carga.

  1. Escenario: versiones, tipo de checkout, producto y extensiones relevantes.
  2. Acción medida: abrir checkout, recalcular envío o confirmar el pedido de prueba.
  3. Antes: duración de cada intento y solicitud que concentra la espera.
  4. Cambio único: ajuste exacto y motivo.
  5. Después: misma operación y mismas condiciones.
  6. Resultado funcional: totales correctos, un único pedido y estado de pago esperado.

Plantilla sin mediciones: este artículo no atribuye mejoras porcentuales a ninguna configuración. Un ensayo comparativo propio queda pendiente de realizar y documentar antes de añadir cifras.

Cuándo revisar el alojamiento

Valora recursos y arquitectura cuando tengas evidencia repetida de saturación, límites alcanzados o trabajo de servidor que no puede atenderse en el plan actual. Aumentar recursos no elimina un conflicto de JavaScript ni una API que responde con errores.

Puedes comparar el hosting web con cPanel y los servidores Cloud de Hostilimitado. Para elegir, comparte número de productos, concurrencia aproximada y los registros del diagnóstico; confirma también quién administrará las actualizaciones y el servidor.

Preguntas frecuentes

¿Un PageSpeed alto garantiza que el checkout funciona bien?

No. Una evaluación de carga de página no reemplaza la comprobación funcional de dirección, envío, totales y pago. Registra ambos aspectos por separado.

¿Debo desactivar LiteSpeed Cache por completo?

No como ajuste permanente sin diagnóstico. En pruebas, aislar una función ayuda a verificar una hipótesis; después conserva solo los cambios que tengan evidencia y valida de nuevo la compra.

¿Cómo sé que resolví el problema?

Cuando el mismo escenario deja de fallar, sus tiempos quedan documentados y el pedido conserva importes y estado correctos. Una rueda de carga que desaparece sin confirmación de pago no basta para dar el caso por cerrado.