La optimización del rendimiento de WooCommerce debe reducir trabajo antes de que una petición llegue a PHP, no simplemente hacer que PHP trabaje más. Una tienda que envía cada petición del catálogo a través de WordPress, los plugins, las sesiones de WooCommerce, Redis y MySQL acabará topándose con colas, saturación de workers o contención en la base de datos cuando aumente el tráfico.
En tiendas con mucho tráfico optimizamos toda la ruta de la petición: Cloudflare → Nginx → PHP-FPM → WordPress → Redis → MySQL. El objetivo es concreto. Cachear de forma segura el tráfico anónimo, preservar los flujos dinámicos de compra, eliminar el código innecesario de cada petición y proteger los workers costosos frente a bots y picos repentinos de tráfico.
La propia WooCommerce documenta esta distinción con claridad: las páginas de carrito, pago y cuenta deben seguir siendo dinámicas porque muestran información específica de cada cliente. El catálogo y otras páginas anónimas son otra cosa. Ahí está la oportunidad de sacar de la aplicación la mayor parte del tráfico repetido, si las reglas de caché se diseñan en función del comportamiento real de las sesiones y las cookies. Las recomendaciones de caché de WooCommerce respaldan este límite.
El verdadero cuello de botella es el trabajo innecesario
Una tienda lenta suele describirse como un problema de hosting. A veces lo es. Pero con más frecuencia el problema de fondo es que demasiadas peticiones recorren la misma ruta costosa.
Cada petición del catálogo sin caché puede invocar PHP-FPM, arrancar WordPress, cargar los plugins activos, cargar datos de WooCommerce, consultar MySQL y generar una respuesta que puede ser idéntica para miles de visitantes anónimos. Añadir workers de PHP sin eliminar ese trabajo suele desplazar la presión hacia la CPU, Redis, MySQL o APIs externas.
Nuestro enfoque consiste en detener el trabajo en la capa segura más temprana. Cloudflare debe servir los recursos públicos cacheables y las respuestas que reúnan los requisitos. Nginx FastCGI Cache debe servir el HTML anónimo sin arrancar PHP. PHP-FPM solo debe recibir las peticiones que requieren lógica de aplicación. Redis debe absorber las consultas repetidas de objetos. MySQL debe quedar disponible para escrituras y para lecturas que realmente no se pueden cachear.
| Capa | Responsabilidad principal | Error típico | Qué validar |
|---|---|---|---|
| Cloudflare | Entrega en el edge de recursos públicos y respuestas cacheables verificadas | Saltarse el edge porque cada respuesta lleva cookies o cabeceras de caché restrictivas | Estado de la caché, cabeceras, variación por idioma y moneda |
| Nginx | Caché FastCGI, enrutamiento, protección de colas, límites de peticiones | Pasar por defecto el HTML anónimo a PHP | Tasa de aciertos de caché, tiempo de respuesta del upstream, eventos de limitación |
| PHP-FPM | Ejecución dinámica de la aplicación | Fijar el número de workers a ojo | Tiempo en cola, workers activos, CPU, memoria, latencia p95 |
| WordPress y plugins | Cargar solo el código que necesita la petición | Cargar todas las integraciones en todas las páginas | Tiempo de arranque, hooks, consultas, regresiones funcionales |
| Redis | Caché de objetos y almacenamiento de sesiones | Combinar cargas de trabajo no relacionadas sin planificar el desalojo | Memoria, desalojos, tasa de aciertos, TTL de claves, sobrecarga de persistencia |
| MySQL | Datos duraderos y lecturas y escrituras necesarias | Usar la base de datos como primera capa de caché | Consultas lentas, bloqueos, presión de conexiones, latencia de escritura |
Este orden importa porque cada capa tiene un perfil de coste distinto. Nginx puede servir un acierto de caché válido sin arrancar PHP. Nginx documenta los controles de la caché FastCGI, incluido el bloqueo de caché y el uso de respuestas obsoletas, que pueden reducir la presión sobre el upstream mientras se actualiza una entrada de caché.
Cómo optimizar una tienda WooCommerce con mucho tráfico
Empiece por clasificar las peticiones. No utilice una única política de caché para toda la tienda.
Las páginas públicas del catálogo, los archivos de categorías, las páginas de producto, el contenido editorial y determinadas respuestas públicas de la API pueden ser candidatas a caché. El carrito, el pago, la cuenta del cliente, los callbacks de pago, las peticiones autenticadas y las peticiones con un carrito activo necesitan una ruta dinámica diseñada a propósito. Esa distinción no es opcional. Una página de pago cacheada puede convertirse en un incidente de corrección y seguridad, no en una mejora de rendimiento.
Las recomendaciones de rendimiento de WooCommerce también aconsejan la carga condicional de recursos, consultas eficientes a la base de datos, pruebas de extensiones y benchmarking. Esos principios se aplican tanto a la tienda en su conjunto como a cada extensión.
La arquitectura debe hacer que una visita anónima a un producto sea barata y reservar la capacidad de la aplicación para añadir al carrito, actualizar el carrito, el pago, los cobros, la escritura de pedidos, las acciones de los clientes y las integraciones.
Cachear el tráfico anónimo sin romper la compra personalizada
Usamos Nginx FastCGI Cache para que la mayoría de los visitantes anónimos no lleguen a arrancar PHP ni WordPress. Esto es especialmente valioso en páginas de catálogo grandes, donde renderizar una y otra vez sin caché puede ocupar workers con poco valor para el negocio.
Las claves de caché deben reflejar en qué varía la tienda. En tiendas multilingües y multimoneda, nuestra clave de caché incluye el idioma activo de WPML y el contexto de moneda. Sin esa variación, incluso un acierto de caché válido puede mostrar al visitante el idioma o la presentación de precios equivocados.
Tras purgar la caché podemos precalentar automáticamente hasta 2000 URL del sitemap. El precalentamiento no sustituye a la planificación de capacidad, pero evita que los primeros visitantes reales después de una purga paguen el coste de reconstruir las páginas más populares. También revisamos individualmente determinados endpoints REST. Un endpoint solo pasa a ser cacheable en el edge después de verificar que su respuesta no depende de las cookies del cliente y de eliminar de forma segura los comportamientos innecesarios de Set-Cookie o Vary: Cookie.
Para el almacenamiento de medios podemos guardar las imágenes en Cloudflare R2 y entregarlas por una ruta de recursos adecuada. Así se separa el almacenamiento de medios de la ejecución de la aplicación WordPress. Pero no elimina la necesidad de optimizar dimensiones y formatos de imagen, el marcado responsive y la política de caché.
La regla práctica es sencilla: cachee una respuesta solo cuando se pueda demostrar que es intercambiable para todos los usuarios que pueden recibirla. WooCommerce identifica el carrito, el pago y la cuenta como páginas dinámicas porque su contenido es específico de cada cliente.
Para una revisión más amplia de los cuellos de botella fuera de la capa de caché, utilice nuestro servicio de auditoría de sitios WordPress para identificar las limitaciones de la aplicación, la base de datos, los plugins y la infraestructura antes de cambiar las reglas de producción.
Reducir el trabajo de WordPress y de la base de datos con Redis
Una caché de objetos persistente en Redis reduce el trabajo repetido de la base de datos cuando WordPress y WooCommerce solicitan una y otra vez los mismos objetos. No sustituye a la caché de página completa. Es la siguiente capa para las peticiones que aun así tienen que llegar a la aplicación.
Mantenemos la caché de objetos de WordPress y las sesiones de WooCommerce en instancias de Redis separadas. Sus cargas de trabajo, la vida útil de sus claves, sus modos de fallo y su comportamiento de memoria son distintos. Las claves de la caché de objetos son copias desechables de datos de la base de datos. Las claves de sesión representan el estado activo del cliente y deben tratarse con más cuidado.
En el caso de las sesiones de WooCommerce, trasladamos el almacenamiento de wp_woocommerce_sessions a Redis. Las claves de sesión tienen TTL, y la instancia de Redis para sesiones puede usar volatile-lru, de modo que el desalojo se dirija a claves con caducidad y no a claves persistentes arbitrarias. Redis documenta que volatile-lru desaloja las claves usadas menos recientemente que tienen un TTL asociado, y aconseja instancias separadas cuando las cargas de trabajo tienen necesidades de persistencia muy diferentes (Redis eviction).
Cuando la topología del despliegue lo justifica, podemos conectar PHP con Redis mediante un socket Unix en lugar de TCP. Es una decisión de implementación que hay que medir con benchmarks, no una regla universal. Los permisos del socket, los límites de los contenedores, el diseño de la conmutación por error y la observabilidad son factores que cuentan.
La instancia de sesiones puede usar instantáneas RDB para que las sesiones sobrevivan a un reinicio limpio o a una recuperación desde una instantánea disponible. Sin embargo, RDB es persistencia en un momento dado, no una promesa de cero pérdida de datos. Redis advierte que las escrituras recientes pueden perderse si se produce un fallo entre instantáneas.
En un benchmark controlado de IMADO, trasladar las sesiones de WooCommerce a Redis permitió completar aproximadamente un 78 % más de iteraciones. Un rango de planificación más prudente es entre un 40 % y un 60 % de rendimiento adicional ante un cuello de botella comparable. Es un resultado observado en un entorno concreto, no una garantía. El comportamiento de los plugins, el tamaño del catálogo, el volumen de sesiones, la configuración de PHP, el rendimiento de la base de datos y la combinación de pruebas pueden cambiar el resultado de forma considerable.
La propia WooCommerce sigue reduciendo consultas en el núcleo. Por ejemplo, WooCommerce 10.7 introdujo el cache priming, que en el escenario descrito redujo una ruta documentada de consultas REST de pedidos de 271 a 132 consultas a la base de datos. Esto refuerza el mismo principio: reducir el trabajo repetido antes de escalar la infraestructura (WooCommerce 10.7).
Ajustar PHP-FPM y el arranque de WordPress según el contexto de la petición
Más workers de PHP-FPM no significa automáticamente mejor. Cada worker consume memoria y puede aumentar la presión simultánea sobre MySQL y los servicios externos. Dimensionamos los workers con benchmarks que incluyen tráfico realista de catálogo, carrito, pago, AJAX e integraciones.
OPcache y WP_CACHE deben estar activados y validados. A partir de ahí, la mayor ganancia suele venir de reducir lo que WordPress carga en cada petición.
Utilizamos reglas de carga de plugins según el contexto con Dynamic Plugin Loader. En las páginas del catálogo, esto permite excluir pasarelas de pago, integraciones con empresas de mensajería, herramientas de administración y otros plugins que no intervienen en el renderizado de un listado anónimo de productos. En el pago, la funcionalidad de cobro sigue disponible, mientras que las funciones SEO no esenciales, los feeds de productos, las listas de deseos y las herramientas de administración pueden excluirse donde las pruebas demuestren que no son necesarias.
Las reglas deben ser distintas para productos, categorías, carrito, pago y AJAX. El administrador de WordPress, WP-CLI, cron y la API REST reciben el conjunto completo de plugins, salvo que se haya probado una excepción concreta. Descargar plugins puede aportar ahorros significativos, pero es una optimización sensible a la compatibilidad. Antes del despliegue, pruebe la persistencia del carrito, la continuidad de la sesión, el cálculo de envíos, los métodos de pago, los webhooks, los cupones, las acciones en la cuenta del cliente y las integraciones de terceros.
Si la tienda ha acumulado años de extensiones y lógica personalizada, el trabajo de rendimiento también puede requerir un plan de mantenimiento de WordPress más amplio en lugar de una configuración de caché puntual.
Proteger los workers costosos durante los picos de tráfico
Los picos de tráfico no son solo un problema de capacidad. Son un problema de gestión del tráfico.
Ajustamos las colas de conexión de Nginx y del sistema operativo para absorber picos breves sin rechazar de inmediato peticiones legítimas. También aplicamos limitación de peticiones en Nginx antes de que arranque PHP. Así se evita que bots abusivos, intentos de credential stuffing, integraciones ruidosas y un sondeo excesivo de la API consuman los workers que necesitan los clientes reales.
Los límites de peticiones no deben ser iguales para todo. El inicio de sesión, la API REST, AJAX, el carrito y el pago tienen patrones de tráfico esperados distintos y riesgos de negocio distintos. La protección del pago debe ser lo bastante estricta para contener el abuso, pero no tan agresiva que bloquee a clientes legítimos durante una promoción.
La generación de correos electrónicos es otra fuente habitual de trabajo evitable en el pago. Cuando el diseño de la tienda y de las integraciones lo permite, trasladamos el procesamiento de correos no críticos a una cola y lo ejecutamos mediante tareas programadas. La petición de pago debe priorizar la validación del pedido, el registro del estado del pago y la devolución de una respuesta fiable.
Por eso las grandes campañas necesitan un ensayo. Pruebe una combinación similar a la de producción: navegación por el catálogo cacheado, búsqueda, acciones de añadir al carrito, intentos de pago, peticiones a la API, bots y tareas en segundo plano. Una prueba de carga solo sobre la página de inicio no es un plan de capacidad para WooCommerce.
Qué medir antes y después de cada cambio
Optimizar el rendimiento sin medir se convierte en folclore de configuración. Establezca una línea base, cambie una variable significativa y compare los resultados con la misma combinación de tráfico.
- Experiencia del visitante: tiempo de respuesta p50, p95 y p99 para las rutas de catálogo, producto, carrito y pago.
- Comportamiento de la caché: tasa de aciertos de caché en Cloudflare y Nginx, motivos de bypass, variación de la clave de caché y finalización del precalentamiento.
- Capacidad de PHP: workers de PHP-FPM activos y en cola, memoria de los procesos, saturación de CPU y tiempo de espera del upstream.
- Salud de Redis: tasa de aciertos de la caché de objetos, uso de memoria, desalojos, TTL de claves, latencia y actividad de persistencia.
- Presión sobre la base de datos: número de consultas lentas, latencia de consultas, esperas por bloqueos, conexiones y rendimiento de escritura durante el pago.
- Corrección del negocio: éxito al añadir al carrito, pagos completados, callbacks de pago, creación de pedidos y cambios en la tasa de errores.
Use estas mediciones para elegir el siguiente cuello de botella. Una tasa de aciertos de caché alta con un pago lento apunta a trabajo en la aplicación dinámica, la base de datos, los pagos o las integraciones. Pocos aciertos de caché en las páginas públicas del catálogo apuntan a las reglas de caché, las cabeceras, las cookies, la variación o el precalentamiento.
En tiendas con mucha funcionalidad a medida, nuestro equipo de desarrollo WordPress puede abordar el rendimiento a nivel de código y arquitectura en lugar de tratar los síntomas en el edge.
Lista de comprobación para el despliegue en producción
- Registre una línea base para catálogo, carrito, pago, PHP-FPM, Redis, MySQL y tasas de error.
- Clasifique cada ruta según su capacidad de caché y sus requisitos de personalización.
- Implemente la variación de caché por idioma, moneda, comportamiento específico del dispositivo cuando esté justificado y límites del estado del cliente.
- Pruebe las reglas de FastCGI y de caché en el edge con navegación anónima, actualizaciones del carrito, pago, inicio de sesión, acciones de cuenta y callbacks de pago.
- Traslade la caché de objetos y las sesiones de forma deliberada, con límites de memoria, política de desalojo, TTL, monitorización y comportamiento de recuperación definidos.
- Determine el número de workers de PHP-FPM con benchmarks de concurrencia realista en lugar de maximizar el número de procesos.
- Introduzca las reglas de carga de plugins de un contexto en un contexto y mantenga una vía rápida de reversión.
- Defina límites de peticiones por ruta y pruebe escenarios de campaña y de bots antes de que llegue el pico de tráfico.
- Despliegue de forma gradual, observe la latencia p95 y p99 y las transacciones de negocio, y conserve la configuración anterior hasta que el cambio esté probado.
Cuándo la optimización del rendimiento de WooCommerce requiere trabajo de ingeniería
Un plugin de caché puede ayudar a una tienda sencilla. No basta cuando la tienda tiene mucho tráfico en el catálogo, precios multilingües, lógica de pago personalizada, integraciones con ERP o CRM, pasarelas de pago, APIs externas, un gran número de plugins, campañas recurrentes o un historial de incidentes en producción.
En ese punto, el trabajo es de arquitectura y operaciones: límites de caché, cabeceras de respuesta, gestión de sesiones, ejecución de plugins, capacidad de PHP, protección de colas, comportamiento de la base de datos, controles de despliegue y monitorización. La implementación adecuada reduce la carga sin perjudicar el recorrido del cliente.
¿Necesita una arquitectura de tienda que siga respondiendo durante el tráfico de las campañas y los picos de pago? Consulte nuestro servicio de optimización de velocidad de WordPress o hable con nuestros ingenieros.
