La pregunta equivocada que cuesta dinero
Cuando una tienda online está lenta, la decisión más común es: "Vamos a hacer upgrade del servidor." A veces es correcta — pero frecuentemente es la respuesta a la pregunta equivocada. Un servidor nuevo resolvería el problema si el problema fuera el servidor. Si es caché desactivado, consulta sin índice o script de tercero cargado de forma síncrona, el upgrade solo redistribuye el costo sin eliminar el cuello de botella.
La pregunta correcta es: ¿dónde se está gastando el tiempo? Y esa respuesta debe basarse en datos — no en intuición, no en "el plan de hosting está viejo", no en "quizás es el tema".
Concepto central: TTFB (Time to First Byte) es el indicador más directo del rendimiento del servidor + backend. Si el TTFB es bajo y la página aún carga lentamente, el problema es frontend. Si el TTFB es alto, el problema está en el servidor, el código de backend, o la base de datos.
Paso 1: medir el TTFB con precisión
Use WebPageTest (webpagetest.org) o Chrome DevTools (pestaña Network, waterfall) para medir el TTFB de una página de producto real — no la homepage. Las páginas de producto tienen consultas más complejas y reflejan mejor el comportamiento real.
Valores de referencia:
- TTFB por debajo de 200ms: servidor respondiendo bien. El problema, si existe, está en el frontend.
- TTFB entre 200ms y 600ms: zona de atención. Verificar caché y consultas.
- TTFB por encima de 600ms: problema claro de backend/infraestructura. Investigar antes que cualquier otra cosa.
Paso 2: verificar si el caché está activo
La causa más común de TTFB alto en e-commerces no es el servidor — es el caché desactivado o mal configurado. En Magento, el Full Page Cache desactivado puede elevar el TTFB de 80ms a 3s+ en la misma infraestructura. En WooCommerce, la ausencia de caché de objeto y de página completa produce el mismo efecto.
Verifique en los headers de la respuesta HTTP: X-Cache: HIT indica que el caché está funcionando. X-Cache: MISS en todas las peticiones significa que nada está siendo cacheado.
Qué puede estar desactivando el caché
- Plugin de personalización o test A/B que fuerza bypass del caché por sesión
- Carrito persistente sin separación de caché por estado de sesión
- Cookie de afiliado o UTM siendo tratado como variable de caché
- Configuración incorrecta de Varnish o Redis expirando demasiado rápido
Paso 3: identificar consultas lentas en la base de datos
Si el TTFB es alto y el caché está funcionando (o no hay caché configurado), el siguiente paso es la base de datos. Active el slow query log de MySQL/MariaDB con umbral de 1 segundo y analice las consultas más frecuentes y más lentas.
Patrones comunes en e-commerce:
- Listado de productos sin índice en
priceostatus - Tabla de opciones (wp_options en WordPress) escaneada sin índice
autoload - JOINs innecesarios en consultas de pedido con miles de registros
- Consultas N+1 en bucles de renderización de producto
Cómo separar servidor de código
| Síntoma | Origen probable | Próximo paso |
|---|---|---|
| TTFB alto, caché HIT | Servidor subdimensionado | Probar con caché warm; comparar planes |
| TTFB alto, caché MISS | Caché desactivado o mal configurado | Activar y configurar caché correctamente |
| TTFB bajo, LCP alto | Frontend — imágenes, scripts | Auditar assets, lazy load, scripts síncronos |
| TTFB variable (a veces rápido) | Cold start de caché o conexiones agotadas | Verificar configuración de conexiones de la BD |
| Lento solo en hora pico | Recursos insuficientes (CPU/RAM) | Analizar métricas del servidor durante el pico |
Regla práctica: Antes de contratar un plan de servidor más caro, active el caché, analice las consultas lentas y desactive scripts de terceros innecesarios. En la mayoría de los casos, estas tres acciones solas resuelven el problema sin costo adicional de infraestructura.
¿Necesitas un diagnóstico de velocidad para tu tienda?
Análisis completo de TTFB, caché, consultas lentas y scripts de terceros — con informe identificando si el problema es infraestructura, código o configuración.