Última actualización: junio de 2026.
Cuando una tienda PrestaShop se siente lenta, la reacción más habitual es también la más costosa: instalar un módulo de caché u optimización, activar todos los interruptores y cruzar los dedos. A veces ayuda. A menudo no hace nada — y en ocasiones empeora las cosas, porque el verdadero cuello de botella nunca estuvo donde el módulo actúa. Los problemas de velocidad son, ante todo, problemas de diagnóstico. El consejo honesto de cualquiera que se dedique a este trabajo es el mismo: mide antes de optimizar. Encuentra la causa real y luego gasta dinero en la solución que la aborda — lo que a veces significa no gastar nada en absoluto.
Por qué adivinar sale tan caro
«Mi tienda es lenta» es un síntoma, no un diagnóstico. La causa subyacente puede estar en cualquiera de varios lugares muy distintos, y una herramienta que arregla uno no hace nada por los demás:
- Un único módulo que dispara una consulta N+1 en cada página de producto — una consulta adicional por artículo en un bucle, multiplicada por tu catálogo.
- Un tema pesado que entrega cientos de kilobytes de CSS y JavaScript que bloquean el renderizado antes de que se pinte nada.
- Un TTFB (tiempo hasta el primer byte) lento de un hosting compartido sobrecargado o de un servidor de base de datos que ya está al límite de su CPU o de su E/S.
- Imágenes sin optimizar — subidas a resolución completa servidas a móviles, sin formatos modernos, sin un dimensionado adecuado.
- Sin caché de página completa, de modo que PrestaShop reconstruye cada página desde cero para cada visitante.
- Una instancia de MySQL falta de memoria, que realiza escaneos de tablas donde debería haber un índice.
Aquí está la trampa. Si tu problema es un tema que bloquea el renderizado y un TTFB lento, un módulo de caché de página podría recortar un poco las visitas repetidas mientras deja intacta la primera impresión — la que Google mide. Si tu problema es una base de datos sobrecargada, ninguna optimización de los recursos del front-end moverá la aguja. Puedes gastar en la capa equivocada indefinidamente y nunca sentirte más rápido. Por eso tratamos una auditoría de rendimiento como el primer paso: te dice qué capa te está costando realmente, de modo que la próxima compra (si la hay) apunte en la dirección correcta.
Lo que realmente mide una auditoría de rendimiento
Una auditoría adecuada no es una única puntuación de un test de velocidad. Separa la página en sus componentes reales y encuentra dónde se va el tiempo:
Tiempo de servidor frente a tiempo de navegador
La primera división es TTFB frente al renderizado del front-end. El TTFB es todo lo que ocurre antes de que tu servidor envíe el primer byte — ejecución de PHP, consultas a la base de datos, búsquedas en caché. El renderizado del front-end es todo lo que el navegador hace después con la respuesta. Una página de 3 segundos con 2,4 s de TTFB es un problema de back-end; la misma página de 3 segundos con 0,2 s de TTFB y 2,8 s de renderizado es un problema de front-end. Necesitan soluciones opuestas, y solo la medición te dice cuál de las dos tienes.
Consultas por página y los peores infractores
Las páginas de PrestaShop pueden ejecutar desde unas pocas docenas hasta varios cientos de consultas SQL. La auditoría las cuenta por tipo de página y clasifica a los peores infractores — con frecuencia un único módulo que debería cachear una búsqueda pero la vuelve a consultar en cada hook. Encontrar esa única consulta a menudo vale más que cualquier cantidad de caché apilada encima de ella.
Sobrecarga de los módulos
Cada módulo enganchado a una página añade trabajo, y algunos se enganchan a todas las páginas, se necesiten allí o no. La auditoría perfila qué módulos aportan un tiempo de ejecución significativo y cuáles se disparan innecesariamente, de modo que puedas desactivar o reemplazar a los verdaderos culpables en lugar de adivinar.
Peso de los recursos y caché
Mide el peso total de la página, el número de peticiones y qué tan bien están configurados CCC (combinar-comprimir-cachear), el critical-CSS y el JavaScript diferido — o si están configurados siquiera. También comprueba la pila de caché de principio a fin: el ratio de aciertos de la caché de página completa, OPcache para el PHP compilado y Redis para la caché de objetos/consultas. Una caché que existe pero rara vez acierta no vale casi nada, y solo el ratio de aciertos lo revela.
Límite del hosting, móvil y Core Web Vitals
Por último, observa la realidad del hardware — margen de CPU, de E/S y de memoria bajo carga — y prueba el móvil por separado del escritorio, porque la mayor parte de tu tráfico y la mayor parte de la medición de Google es móvil. Eso se relaciona directamente con los Core Web Vitals: LCP, CLS e INP. No son métricas de vanidad; son una señal de posicionamiento real, y por eso la velocidad y la búsqueda se solapan, y por eso una auditoría SEO técnica y una auditoría de rendimiento sacan a la luz con tanta frecuencia los mismos problemas.
Una autocomprobación que puedes hacer en diez minutos
No necesitas encargar nada para obtener una primera lectura de tu propia tienda. Abre tu página de inicio y una página de producto con mucho contenido en Chrome y prueba esto:
- Ejecuta una cascada. Abre las DevTools, ve a la pestaña Red, recarga forzando (hard-reload) y observa la primera petición. Su tiempo de «Waiting (TTFB)» te dice cuánto es del lado del servidor. Más de ~600 ms con una caché caliente apunta al back-end.
- Cuenta peticiones y peso. El pie de la pestaña Red muestra el total de peticiones y el tamaño transferido. Cientos de peticiones o varios megabytes por página son una fuerte señal de recursos/CCC.
- Lee el profiler de PrestaShop. Activa el modo de depuración en una copia de staging y enciende el profiler — imprime el número de consultas y las consultas más lentas por página. Una página de producto que ejecuta más de 250 consultas merece atención.
- Limita la velocidad del móvil. En las DevTools, configura el dispositivo a un perfil móvil de gama media con limitación «Slow 4G» y recarga. Si la experiencia se desmorona aquí, eso es lo que realmente sienten la mayoría de tus visitantes.
Estos números son umbrales ilustrativos, no garantías — cada tienda es diferente. Pero normalmente te apuntarán al vecindario correcto antes de que nadie gaste un euro.
Mide el TTFB desde la línea de comandos
Si prefieres obtener una cifra precisa del tiempo de servidor sin abrir las DevTools, curl informa del desglose de tiempos directamente. Es de solo lectura — simplemente obtiene la página e imprime cuánto duró cada fase:
# Print connection, TLS, TTFB and total time for one page load
curl -s -o /dev/null \
-w "dns: %{time_namelookup}s\nconnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\ntotal: %{time_total}s\n" \
https://yourdomain.com/your-product-pageLa cifra que más importa aquí es el TTFB (time_starttransfer): todo hasta el primer byte de la respuesta. Ejecútalo unas cuantas veces para que una caché fría no distorsione el resultado. Si esa cifra se mantiene alta — bastante por encima de medio segundo con una caché caliente — tu cuello de botella es del lado del servidor (PHP, consultas, hosting), y ninguna optimización de los recursos del front-end lo arreglará. Si el TTFB es bajo pero la página aún se siente lenta en el navegador, el coste está en el renderizado y los recursos en su lugar. Esa única división es toda la razón para medir antes de comprar.
El giro honesto: lo que la auditoría te dice que hagas
Todo el sentido de medir primero es que el veredicto a menudo no es «compra un módulo de optimización». Una buena auditoría termina en una de unas pocas direcciones claras:
- Es el hosting. Si el TTFB es alto incluso con un acierto de caché y el servidor está al límite de su CPU/E/S, ningún módulo lo arregla — necesitas un mejor hosting o una pila ajustada, que es exactamente lo que delimita una auditoría de hosting.
- Es la configuración. Con frecuencia las cachés existen pero están mal configuradas: CCC a medio activar, OPcache demasiado pequeño, Redis no realmente conectado. Eso es un cambio de ajustes, no una compra.
- Es un módulo o tema concreto. A veces un único módulo pesado o un tema ineficiente es todo el problema, y la solución es reemplazarlo o eliminarlo.
- Realmente necesitas una herramienta. Si el cuello de botella son los recursos del front-end y la falta de caché de página completa, un módulo enfocado y de código abierto como Performance Revolution es la compra adecuada — una vez que sabes que esa es la capa que te está costando, no antes.
- Ya está bien. En ocasiones la auditoría muestra que la tienda está sana y que la lentitud percibida es un único script de terceros lento o un problema de red regional. Saberlo te ahorra «optimizar» algo que no está roto.
Comprar a ciegas es como las tiendas acaban con tres módulos de caché solapados y un sitio más lento del que tenían al empezar. Diagnosticar primero es más barato, incluso cuando el diagnóstico cuesta algo, porque te impide gastar en la capa equivocada.
Cómo empezar
Si quieres una lectura estructurada en lugar de una tarde de bricolaje, nuestra auditoría de rendimiento está hecha exactamente para esto. Introduces la URL de tu tienda, se ejecuta primero una rápida comprobación de preparación de solo lectura — sin entregar credenciales de administración, consulta nuestras notas sobre la preparación para la auditoría de la tienda para saber cómo gestionamos el acceso — y solo entonces se encarga la auditoría. Se sitúa junto al resto de nuestros servicios expertos para los casos en los que la solución resulta ser hosting, configuración o desarrollo en lugar de un producto. Sea cual sea el resultado, sabrás por qué la tienda es lenta antes de gastar en hacerla rápida — y esa es la parte que realmente ahorra dinero.
Preguntas frecuentes
Ya tengo un módulo de caché instalado. ¿Por qué sigue siendo lenta mi tienda?
Porque la caché solo ayuda a la capa sobre la que se asienta. Una caché de página completa no hace nada por un primer byte lento en una base de datos sobrecargada, y un optimizador de front-end no puede arreglar un servidor que está al límite de su CPU. También es habitual que una caché esté instalada pero apenas acierte — CCC a medio configurar, OPcache demasiado pequeño, Redis no realmente conectado. La división del TTFB de arriba te dice si tu cuello de botella siquiera está en una capa que la caché pueda tocar. A menudo no lo está, y por eso el módulo «no hizo nada».
¿Cuál es un TTFB «bueno» para PrestaShop?
Como guía aproximada, por debajo de ~200 ms es saludable, ~200–600 ms es aceptable, y de forma constante por encima de ~600 ms con una caché caliente apunta a un problema del lado del servidor que vale la pena perseguir. Estos son vecindarios, no líneas rígidas — una página de producto pesada legítimamente hace más trabajo que la página de inicio. La comparación útil es tu propia tienda en frío frente a en caliente, y tu TTFB frente al tiempo de renderizado que el navegador añade después. Ese ratio, no una cifra aislada, te dice en qué dirección gastar.
¿Puede una auditoría de rendimiento garantizar que mi tienda será más rápida?
No, y desconfía de cualquiera que lo prometa. Una auditoría te dice por qué la tienda es lenta y qué solución la aborda — no realiza la solución ni garantiza una cifra. Si la causa es el hosting, la mejora de velocidad depende de la nueva pila; si es un módulo pesado, de si puedes reemplazarlo; si ya está bien, el resultado honesto es «no gastes nada». El valor está en apuntar el gasto correctamente, no en un recuento de milisegundos prometido.
¿La auditoría ralentizará o pondrá en riesgo mi tienda en producción?
No. La comprobación de preparación y las mediciones son de solo lectura — cargan las páginas como lo haría un visitante y registran los tiempos; no se escribe ni se cambia nada. El paso del profiler en la autocomprobación es lo único que deberías ejecutar en una copia de staging en lugar de en producción, porque el modo de depuración expone los detalles internos y añade sobrecarga. La auditoría en sí no necesita el modo de depuración en tu sitio de producción.
¿En qué se diferencia esto de simplemente ejecutar PageSpeed Insights?
PageSpeed mide el renderizado del front-end de una URL y la puntúa frente a los Core Web Vitals — genuinamente útil, y vale la pena ejecutarlo. Lo que no puede ver es tu servidor: el número de consultas, qué módulo se dispara en cada hook, tus ratios de aciertos de caché o si la base de datos es el verdadero límite. Una página puede puntuar bien en PageSpeed y aun así ser lenta bajo la carga real del catálogo, o puntuar mal por una razón que un módulo no puede arreglar. La auditoría cubre la mitad del back-end para la que PageSpeed es ciego.
Comentarios
Aún no hay comentarios. ¡Sé el primero!
Sé el primero en hacer una pregunta o compartir una opinión útil.
Dejar un comentario
Comparte una pregunta, un detalle de instalación o una opinión que pueda ayudar a otro lector.