La mayoría de tiendas WooCommerce intentan ir rápido instalando un plugin de caché más. Funciona hasta cierto punto, pero el techo real lo pone el servidor: PHP, la base de datos, la caché de objetos y, sobre todo, ese WP-Cron que se dispara con cada visita. Cuando eso está bien resuelto a nivel de sistema, la tienda vuela. Cuando no, ningún plugin te salva en campaña.
Yo me ocupo de la capa de sistema: el servidor, el sistema operativo y todos los servicios sobre los que corre WordPress y WooCommerce. De la tienda en sí —tema, plugins, código y actualizaciones de WordPress/WooCommerce— se encarga la agencia o tu equipo de desarrollo. Lo mío es que el entorno donde vive la tienda esté rápido, seguro, monitorizado y disponible.
Trabajo sobre todo con agencias y desarrolladores que necesitan un especialista de sistemas para sus proyectos WooCommerce sin sumarlo a la plantilla, y también directamente con responsables de e-commerce que quieren una tienda que aguante. En segundo plano, como una extensión de tu equipo.
De qué parto: los problemas que suelo encontrar
La mayoría de proyectos WooCommerce llegan con alguno de estos síntomas:
- La tienda va lenta y el plugin de caché no basta. TTFB alto, carrito y checkout pesados, wp-admin que se arrastra. El plugin cachea la portada, pero las páginas que de verdad importan en una tienda no se pueden cachear igual, y ahí es donde se nota el servidor.
- WP-Cron descontrolado. Las tareas programadas de WordPress se ejecutan en cada visita, cargando el servidor justo cuando hay más tráfico. Es uno de los cuellos de botella más típicos y se resuelve a nivel de sistema.
- Se cae justo cuando más vende. Rebajas, Black Friday, un envío de newsletter que funciona demasiado bien… y el servidor dice basta en el peor momento.
- Ataques a wp-login y xmlrpc. WordPress es el CMS más atacado del mundo: fuerza bruta al login, abuso de XML-RPC, bots sin parar. Mucho de eso se corta antes de que toque PHP.
- Una migración o un servidor nuevo. Salir de un hosting compartido que se ha quedado pequeño, cambiar de servidor o consolidar, sin perder ventas ni SEO. (Las actualizaciones de la tienda las coordina tu equipo; yo preparo y migro la infraestructura.)
Si te suena alguno, ahí es donde entro.
Cómo lo resuelvo
No vendo recetas mágicas ni «optimizaciones» genéricas, ni el enésimo plugin. El método es siempre el mismo: medir, dimensionar y afinar el stack concreto de tu tienda a nivel de servidor.
Parto de datos reales (métricas de servidor, perfilado de servicios, logs de tráfico de campañas anteriores) para saber dónde está el cuello de botella de verdad antes de tocar nada. A partir de ahí, ajusto cada servicio del stack —servidor web, PHP, base de datos, caché de objetos— para el patrón de carga real de tu tienda, dejo todo documentado y reproducible, y me quedo disponible para los picos. La idea es que la infraestructura esté preparada antes de la campaña, no apagando fuegos durante. La tienda corre por encima; yo me aseguro de que tenga un suelo firme bajo los pies.
Qué incluye
Esto es lo que aporto a nivel de sistema en un proyecto WooCommerce. No tienes que contratarlo todo: se adapta a lo que necesite el proyecto.
Rendimiento y afinado del stack
- Afinado de PHP-FPM y OPcache para el patrón de carga real de la tienda (pools, workers, memoria).
- Configuración del servidor web (Nginx o Apache) con FastCGI cache, compresión, caché de estáticos y HTTP/2 o HTTP/3.
- Caché de página a nivel de servidor excluyendo correctamente carrito, checkout y cuenta de cliente, en coordinación con tu equipo (justo lo que un plugin de caché suele hacer mal en una tienda).
- Provisión y afinado del servicio Redis / Memcached como caché de objetos persistente de WordPress.
- WP-Cron desactivado y sustituido por un cron de sistema real, para que las tareas programadas dejen de dispararse en cada visita.
- Afinado de MariaDB/MySQL (buffer pool, conexiones, consultas lentas), muy sensible al peso de
wp_options, transients y plugins. - Provisión del servicio de búsqueda (p. ej. Elasticsearch para ElasticPress) si el proyecto lo requiere.
Preparación para campañas y picos
- Pruebas de carga previas para conocer el techo real del servidor antes del evento.
- Dimensionado de recursos (vertical y, cuando aplica, horizontal con balanceo) para soportar el pico.
- Plan de contingencia y disponibilidad reforzada (on-call) durante la ventana crítica.
Seguridad y hardening
- Hardening del servidor y protección de wp-login.php y XML-RPC (límites, fail2ban, bloqueo de fuerza bruta) antes de que la petición llegue a PHP.
- Actualizaciones de seguridad del sistema: sistema operativo, kernel y servicios del stack al día. (Las actualizaciones de WordPress, plugins y tema son cosa de tu equipo; yo mantengo seguro lo que hay debajo.)
- WAF delante de la tienda (Cloudflare, ModSecurity u otros) y mitigación de bots y scraping.
- Cortafuegos, permisos de ficheros correctos y cabeceras de seguridad a nivel de servidor web.
- Buenas prácticas orientadas a cumplimiento PCI-DSS en la parte de infraestructura, y gestión de certificados TLS con renovación automática.
Migraciones de infraestructura
- Migraciones de hosting o de servidor sin downtime perceptible y sin perder SEO.
- Salida de hosting compartido a un entorno dedicado o cloud mejor dimensionado.
- Provisión de entornos de staging y producción equivalentes, para que tu equipo despliegue y pruebe sobre una base sólida.
- Migración de datos y servicios a nivel de sistema, con plan de vuelta atrás claro si algo sale mal.
Copias de seguridad y monitorización
- Copias cifradas, externas y probadas (criterio 3-2-1): no vale una copia que nunca se ha restaurado.
- Monitorización continua de servidor, servicios y disponibilidad, para enterarte antes de que lo note tu cliente.