Decir que una tienda WooCommerce es lenta es el comienzo del diagnóstico, no la conclusión. El catálogo puede abrir deprisa y el proceso de pago tardar; una página puede responder rápidamente y seguir siendo pesada en móvil. Instalar otro plugin de optimización sin distinguir estos casos añade variables y puede afectar a funcionalidades que eran correctas.
La prioridad es encontrar el punto que retrasa al visitante y confirmar la causa. Esta guía propone un método para organizar mediciones, comparar hipótesis y validar cambios. Una mejora debe facilitar el uso y preservar la compra; una puntuación aislada no demuestra que todos los clientes puedan elegir, pagar y recibir una confirmación.
1. Describir dónde y cuándo se produce la lentitud
Elige URL y acciones concretas: abrir una categoría, seleccionar una variación, añadir al carrito, calcular gastos de envío o finalizar el pedido. Registra dispositivo, red, hora y estado de sesión. Diferencia visitante anónimo, cliente autenticado y sesión con artículos en el carrito. Estos recorridos pueden utilizar caché y recursos diferentes, incluso dentro de la misma tienda.
- Catálogo: compara categoría, producto simple y producto con variaciones.
- Compra: prueba añadir, actualizar cantidades, aplicar cupón, elegir envío y pagar en modo de prueba.
- Cuenta: comprueba inicio de sesión y acceso a pedidos sin compartir datos de clientes.
- Operativa: anota si el retraso coincide con importaciones, tareas automáticas o una mayor demanda.
2. Leer Core Web Vitals sin confundir laboratorio y uso real
Los Core Web Vitals observan la carga del contenido principal (LCP), la respuesta a las interacciones (INP) y la estabilidad visual (CLS). En PageSpeed Insights, distingue los datos de visitantes reales de las pruebas de laboratorio. El laboratorio permite repetir escenarios controlados; los datos de campo representan condiciones y comportamientos efectivos cuando existe información suficiente para mostrarlos.
Unos resultados diferentes no significan necesariamente que una herramienta esté equivocada. Dispositivos, red, caché e interacciones varían. Una medición de laboratorio tras una corrección puede mejorar de inmediato, mientras que los datos agregados de campo todavía incluyen visitas anteriores. Si faltan datos públicos, no concluyas que la tienda es rápida: combina pruebas representativas con observación del funcionamiento y, cuando corresponda, medición propia.
3. Separar tiempo de respuesta y trabajo del navegador
El TTFB mide el tiempo hasta el primer byte y es útil para investigar la respuesta inicial. La documentación de web.dev lo distingue de los Core Web Vitals. Un TTFB elevado puede implicar red, redirecciones, generación de página e infraestructura; no demuestra por sí solo que el alojamiento sea insuficiente. Compara solicitudes equivalentes antes de atribuir la causa a un proveedor.
Si la respuesta inicial es rápida pero el contenido principal aparece tarde, observa imágenes, fuentes y recursos que bloquean la presentación. Si los controles se vuelven pesados después de abrir la página, investiga el trabajo de JavaScript y los servicios externos. La imagen más grande no siempre es el elemento LCP. Identifica el elemento observado y cuándo se solicita antes de elegir la intervención.
4. Comprobar la caché sin guardar información de otro cliente
La caché de página, la caché de objetos y una CDN resuelven problemas diferentes. La primera puede reutilizar HTML; la segunda puede evitar trabajo repetido al acceder a datos; una CDN puede acercar los recursos a los visitantes. Confirma qué capas están activas y quién las gestiona. Varios plugins o reglas superpuestas dificultan entender cuál entrega una página desactualizada.
La orientación de caché de WooCommerce exige atención a las páginas de carrito, pago y cuenta porque contienen información específica de la sesión. Comprueba exclusiones, cookies y reglas del alojamiento o de la CDN. No apliques una regla genérica de guardar todas las páginas para mejorar una puntuación. Los precios personalizados, las monedas y el contexto del cliente también requieren validación.
Compara la primera visita con una repetición y confirma si producto, precio y stock siguen actualizados después de un cambio. Prueba sesiones separadas para garantizar que no se intercambie el carrito y que la cuenta exija autenticación. Estas comprobaciones funcionales forman parte de la aceptación de la caché, junto con la reducción observada de trabajo o tiempo de respuesta.
5. Aislar plugins y tema en una copia de pruebas
El número de plugins, por sí solo, no determina la velocidad. Una extensión puede hacer llamadas externas en cada solicitud; otra puede cargar scripts únicamente donde se necesitan. Reproduce la lentitud en una copia protegida y registra un escenario de referencia. Desactiva componentes de forma controlada y repite la misma acción, conservando las dependencias necesarias para la prueba.
Si un componente parece responsable, reactívalo y confirma si el problema regresa. Esto refuerza la hipótesis frente a una mejora observada después de varios cambios simultáneos. Considera tema, extensiones obligatorias, componentes del alojamiento e integraciones. No desactives pagos o sincronizaciones en la tienda pública para experimentar; la documentación WooCommerce recomienda copias de seguridad y staging para las pruebas de conflictos.
6. Investigar base de datos y servidor con evidencias
Pide al responsable técnico que relacione la solicitud lenta con consultas demoradas, llamadas externas, consumo de recursos y tareas en ejecución. Las opciones cargadas automáticamente, los datos acumulados y las operaciones de extensiones pueden merecer análisis. La cantidad total de pedidos no identifica por sí sola una consulta ineficiente. Un informe útil vincula el síntoma con la operación que consume tiempo.
Evita limpiezas automáticas indiscriminadas de la base de datos. Los datos de pedidos, sesiones y tareas pueden tener utilidad operativa; define qué puede eliminarse, haz una copia y prueba el cambio. Una caché de objetos persistente puede ser adecuada en ciertos contextos, pero requiere compatibilidad y gestión. Ampliar recursos puede aliviar la capacidad sin corregir trabajo innecesario: compara coste, complejidad y efecto medido.
7. Aplicar un cambio y repetir el recorrido de compra
Para cada hipótesis, escribe el cambio propuesto, el efecto esperado, la prueba y la forma de volver atrás. Puede ser ajustar una imagen, una exclusión de caché o una integración; el orden debe seguir el impacto observado y el riesgo. Repite mediciones en condiciones comparables y prueba el comportamiento antes de generalizar la mejora a toda la tienda.
- Guardar el escenario y la configuración inicial para permitir la comparación.
- Aplicar el cambio en una copia y confirmar la hipótesis con la misma acción.
- Validar producto, carrito, descuentos, gastos de envío, pago y confirmación del pedido.
- Publicar el cambio acordado y observar errores y mediciones representativas, con la recuperación preparada.
Ejemplo hipotético: catálogo rápido, cálculo de gastos de envío lento
Imagina que categorías y productos responden normalmente, pero cambiar la dirección en el proceso de pago provoca una espera larga. El diagnóstico puede encontrar una llamada al transportista que tarda. Volver a comprimir las imágenes no actúa sobre esa solicitud. Es necesario analizar la integración, sus tiempos de respuesta y el tratamiento de fallos. El escenario es hipotético y no representa resultados de clientes RedeShop.
Para observar ese retraso, abre Network en Chrome DevTools antes de repetir la acción. Compara el documento inicial con las solicitudes Fetch/XHR iniciadas cuando cambias la dirección; observa la duración y la pestaña Timing. Si el documento ya ha cargado y una de esas solicitudes sigue pendiente, la espera no corresponde a la carga inicial del DOM. Esto localiza el recorrido, pero no demuestra que el transportista sea la causa: correlaciónalo con los registros del servidor.
Si la respuesta llega y la interfaz sigue bloqueada, graba la interacción en el panel Performance para observar el trabajo del navegador. El evento DOMContentLoaded no demuestra que haya terminado el cálculo de gastos de envío o el proceso de pago.
Preparar una solicitud de diagnóstico WooCommerce
Envía la dirección de la tienda, las páginas o acciones lentas, cuándo empezó el problema y los cambios recientes. Comparte informes existentes sin datos personales ni accesos. El equipo RedeShop está disponible para analizar la situación, distinguir medición de implementación y definir prioridades técnicas con criterios de validación. El próximo paso es entender la causa y el alcance antes de elegir herramientas.
Fuentes y documentación
- web.dev: Web Vitals y métricas de experiencia
- web.dev: diferencias entre laboratorio y datos de campo
- web.dev: diagnóstico y optimización de TTFB
- WooCommerce: diagnóstico de una web lenta
- WooCommerce: configuración de caché
- WooCommerce: pruebas de conflictos entre tema y plugins
- WordPress: optimización, caché y base de datos
- Chrome DevTools: solicitudes y tiempos en el panel Network
- Chrome DevTools: análisis en el panel Performance