WooCommerce lento: causas típicas y en qué orden solucionarlas

Un WooCommerce lento rara vez tiene una sola causa. Lo normal es una suma: un alojamiento justo, una tabla de opciones que ha ido creciendo durante años, una docena de plugins que cargan en todas las páginas y alguna tarea programada que coincide con las horas de más tráfico. Repasamos las causas que más encontramos al revisar tiendas WooCommerce, cómo medir cada una sin adivinar y en qué orden conviene actuar para que cada cambio se note.

Por qué un WooCommerce lento se nota más en el carrito y el checkout

WordPress genera cada página con PHP y con consultas a MySQL o MariaDB. En la portada, las categorías y las fichas, una caché de página completa esconde buena parte de ese trabajo: el servidor guarda el HTML ya montado y lo entrega sin recalcularlo. El carrito, el checkout y la cuenta del cliente no se pueden cachear así, porque cada visitante ve su propio contenido. En esas páginas la tienda trabaja sin red y salen a la luz los problemas del servidor y de la base de datos.

Por eso hay tiendas que parecen rápidas mientras navegas por el catálogo y se arrastran justo cuando vas a pagar. Con el administrador pasa algo parecido. Si editar un pedido o guardar un producto tarda varios segundos, el origen suele estar en el servidor, en la base de datos o en algún plugin, y la caché de página no lo va a tapar.

Cómo medir la lentitud antes de tocar nada

Lo primero es separar dos tiempos: lo que tarda el servidor en responder y lo que tarda el navegador en pintar la página. Si el primero es alto, optimizar imágenes o scripts dará poco resultado. Si es bajo y la página sigue lenta, hay que mirar el front. Con esa separación hecha, el trabajo va de abajo arriba:

Para medir con datos:

• Tiempo de respuesta del servidor en una ficha cacheada y en el carrito con un producto dentro, varias veces y a distintas horas.
• Un plugin de diagnóstico como Query Monitor, instalado en una copia de la tienda, para ver cuántas consultas lanza cada página, cuáles tardan más y qué plugin las origina.
• El registro de consultas lentas de MySQL activado durante unos días, si tu alojamiento lo permite.
• Los registros de errores de PHP. Un aviso que se repite miles de veces al día también consume tiempo.
• Las acciones programadas pendientes o fallidas, que WooCommerce muestra en su pantalla de estado.

Apunta las cifras de partida para poder comparar después de cada cambio, y haz los cambios de uno en uno.

Servidor y hosting: PHP, memoria y caché de objetos

En WooCommerce el servidor es cosa tuya o de tu proveedor de alojamiento, y un plan compartido pensado para una web corporativa se queda corto en cuanto la tienda recibe pedidos a diario. Revisa estos puntos:

• La versión de PHP. Las antiguas suelen rendir peor y dejan de recibir parches de seguridad. Antes de subir de versión, prueba los plugins en una copia.
• El límite de memoria de PHP y cuántos procesos pueden atender peticiones a la vez. Cuando se agotan, las peticiones hacen cola y en campaña la tienda parece caída.
• Si hay caché de objetos persistente, como Redis o Memcached. WordPress guarda ahí resultados que se repiten y alivia las páginas que no se pueden cachear enteras.
• Que la caché de página excluya carrito, checkout y cuenta, y respete las cookies de sesión de WooCommerce.

Cambiar de hosting tiene sentido cuando, con la base de datos y los plugins ya revisados, el servidor sigue tardando en responder. Hacerlo antes suele llevar el mismo problema a una máquina más cara.

Base de datos: wp_options, autoload y tablas que crecen

La tabla wp_options guarda la configuración de WordPress y de cada plugin. Las opciones marcadas para cargarse automáticamente (el famoso autoload) se leen en cada petición, las necesite la página o no. Con los años se acumulan restos de plugins desinstalados, configuraciones enormes guardadas en una sola fila y datos temporales que nadie limpia. Si ese bloque pesa varios megas, todas las páginas lo arrastran.

Según la versión, la pantalla Salud del sitio de WordPress avisa cuando las opciones autocargadas ocupan demasiado. Para verlo con detalle hace falta una consulta a la base de datos que sume el tamaño de esas filas y liste las más grandes. Antes de borrar o desmarcar ninguna, averigua qué plugin la creó, porque quitar la equivocada puede dejar un plugin activo sin su configuración.

Hay otras tablas que crecen sin que nadie las mire:

• Los transitorios, datos temporales que también viven en wp_options. Los caducados deberían desaparecer solos, aunque no siempre ocurre.
• Las tablas de Action Scheduler, donde WooCommerce y muchos plugins apuntan sus tareas en segundo plano. Miles de acciones fallidas indican que algo se repite sin éxito.
• Las sesiones de WooCommerce de los visitantes que han añadido algo al carrito.
• Los registros de plugins de correo, seguridad o estadísticas que guardan cada evento en la base de datos.

Los pedidos también pesan. Con el almacenamiento clásico, cada pedido es una entrada más de WordPress con decenas de metadatos, y buscar en el administrador se vuelve lento cuando el histórico es grande. El almacenamiento de pedidos de alto rendimiento los pasa a tablas propias. En la guía sobre HPOS en WooCommerce explicamos cómo hacer ese cambio sin romper plugins.

Plugins y consultas pesadas

Importa menos cuántos plugins hay que lo que hace cada uno y en qué páginas. Uno que solo trabaja en el administrador apenas afecta al visitante. Otro que lanza consultas pesadas en cada ficha, o que llama a un servicio externo antes de pintar la página, sí se nota.

La forma más fiable de dar con el culpable es una copia de la tienda: desactivas plugins uno a uno, o por grupos, y mides el tiempo de respuesta de las mismas páginas cada vez. Query Monitor acorta la lista porque agrupa las consultas por el componente que las lanza.

Estos patrones aparecen a menudo:

• Filtros de catálogo que buscan por atributos o metadatos sin índices adecuados. En catálogos grandes, algunas combinaciones de filtros tardan segundos.
• Buscadores que recorren la tabla de metadatos de productos comparando texto.
• Plugins que consultan una API externa de envíos, divisas o stock cada vez que se carga una página, en lugar de guardar la respuesta un rato.
• WP-Cron disparado por las visitas. En una tienda con tráfico suele ir mejor desactivar ese disparo y lanzar las tareas desde el servidor cada pocos minutos.
• Importaciones de stock o de precios programadas en hora punta.

A veces un plugin hace mucho más de lo que la tienda usa, y una pieza pequeña escrita para tu caso pesa menos. En plugin comprado o código a medida en WooCommerce contamos cuándo compensa cada opción.

Imágenes, scripts y fragmentos del carrito

Con el servidor respondiendo rápido, queda lo que pasa en el navegador. Las fotos de producto subidas a varios miles de píxeles, sin tamaños intermedios ni formatos modernos, siguen siendo lo más habitual. Regenerar las miniaturas al tamaño que usa el tema y servirlas en WebP, desde el servidor o con una extensión, suele notarse en categorías y fichas.

Los fragmentos del carrito merecen un apartado propio. WooCommerce usa una petición AJAX para actualizar el minicarrito de la cabecera sin depender de la caché de la página. Desde la versión 7.8 ese script ya no se carga por defecto en todas las páginas, solo donde aparece el widget del carrito. Aun así, algunos temas llevan el widget fijo en la cabecera y algunos plugins declaran el script como dependencia, y entonces cada visita lanza una petición que no se puede cachear. Si ves esa petición en todas las páginas desde las herramientas de desarrollo del navegador, averigua quién la carga.

Luego están los scripts de terceros: chat, reseñas, píxeles de publicidad y ventanas emergentes. En la guía sobre la velocidad de una tienda online entramos con más detalle en Core Web Vitals, imágenes y scripts, para cualquier plataforma.

Qué preparar antes de pedir una revisión de rendimiento

Para que la revisión empiece por las causas y no por suposiciones, ten a mano lo siguiente:

• Acceso de administrador a WordPress y al panel del alojamiento, o el contacto de quien lo gestiona.
• Versiones de WordPress, WooCommerce y PHP, y la lista de plugins activos con quién usa cada uno.
• Qué páginas van lentas y cuándo: siempre, solo en campaña o solo en el administrador.
• Si ya existe una copia de la tienda o se puede crear una para probar.
• Tareas programadas que conozcas, como importaciones, sincronizaciones con el ERP o copias de seguridad.
• Cambios recientes, si la lentitud empezó de golpe: un plugin nuevo, una actualización o un cambio de tema.

Si quieres que lo miremos, en mantenimiento WooCommerce explicamos cómo trabajamos: medimos, probamos cada cambio en una copia y lo pasamos a producción cuando la mejora está comprobada.