¿Tu tienda va lenta? Cómo comprobarlo y qué hacer para solucionarlo

"Mi tienda se nota lenta" no es un diagnóstico: es un síntoma, y actuar por sensaciones es la forma en que muchos comerciantes pierden un fin de semana instalando un módulo de caché que no arregla nada. Lo primero no es arreglar nada. Es averiguar, con datos, si tu tienda es realmente lenta, dónde está la lentitud (¿en el servidor?, ¿en el peso de la página?, ¿en la base de datos?, ¿en un único módulo rebelde?) y qué tan grave es. Si mides bien, la solución suele señalarse sola. Si mides mal, acabarás optimizando imágenes en una tienda cuyo problema real es un Time to First Byte de 1,8 segundos que ninguna técnica de imágenes va a tocar.

Esta guía es el paso de diagnóstico: cómo comprobar correctamente la velocidad de una tienda PrestaShop, cómo interpretar lo que te dicen las herramientas y cómo convertir esa lectura en una lista de tareas priorizada. Las correcciones profundas, ajuste de base de datos, caché de página completa, Redis, alojamiento, tienen cada una su propia guía dedicada, y te enlazamos la adecuada en cada rama en lugar de meter aquí una versión superficial de todas.

Todo lo que aparece aquí se aplica a PrestaShop 1.6, 1.7, 8.x y 9.x: el interruptor del perfilador está en el mismo archivo en estas versiones. En PS8/9 también tienes la barra de depuración de Symfony con el recuento de consultas por petición, como se indica más abajo.

Por qué tu propia impresión de la velocidad es la prueba menos fiable

Navegas por tu tienda desde una oficina, con conexión por cable o una buena conexión, a menudo con la sesión iniciada en el panel de administración; eso significa que el perfilador de depuración de PrestaShop y una caché caliente juegan a tu favor, y que estás entrando en páginas que ya has cargado hoy. Tu cliente está en un móvil Android de gama media, con datos móviles, llegando en frío a una página de categoría que le ha enviado Google. Son dos tiendas distintas. El comerciante que dice "a mí me va bien" y las analíticas que muestran picos de abandono del proceso de compra en móvil dicen la verdad: simplemente están midiendo máquinas distintas.

Así que, antes de usar cualquier herramienta: si estás probando con la sesión iniciada como administrador, no estás viendo lo que ven los clientes. Abre el front office en una ventana privada/incógnito o, mejor aún, limita la red del navegador a "Slow 4G" en Chrome DevTools. Solo eso suele cambiar por completo la conversación para la mayoría de propietarios.

Las cuatro comprobaciones que merece la pena hacer (y qué te dice realmente cada una)

No necesitas diez herramientas. Necesitas cuatro lecturas que, juntas, te digan si el problema está en el servidor, en la página o en los datos, porque son tres talleres de reparación distintos.

PageSpeed Insights: lee los datos de campo, no solo el número

Introduce la URL de tu tienda en pagespeed.web.dev y obtendrás una puntuación para móvil y otra para escritorio. La puntuación móvil es la que importa: Google indexa primero la versión móvil y la mayor parte del tráfico de escaparate viene desde móviles. Pero la puntuación (el gran círculo de color) es una simulación de laboratorio. Sube hasta la sección que puede decir "Descubre qué están experimentando tus usuarios reales": son los datos de campo de CrUX, procedentes de visitantes reales de Chrome, y ofrecen una imagen más fiel. Una tienda puede sacar 55 en la simulación de laboratorio y aun así aprobar Core Web Vitals en campo, o al revés. Lee ambas cosas.

Como orientación aproximada para la puntuación de laboratorio:

• 90–100, estás en buena forma; dedica el esfuerzo a otra cosa.
• 50–89. Hay dinero real en esa brecha; merece una revisión estructurada.
• Por debajo de 50. Ya te está costando tráfico y conversiones; trátalo como urgente.

Una puntuación de PageSpeed en los 90 es alcanzable en una tienda PrestaShop real con una pila pesada de módulos: no es un objetivo teórico reservado a instalaciones de demostración vacías. Documentamos exactamente cómo hacerlo en una tienda PrestaShop en producción en PageSpeed 99/100 en una tienda real con 130 módulos, que es el acompañamiento de prueba de concepto de esta guía de diagnóstico.

Los tres Core Web Vitals y qué señala cada fallo

Google mide la velocidad real con tres métricas. El valor no está en el número en sí, sino en que cuál de las métricas falla te indica a qué taller de reparación debes acudir.

• Largest Contentful Paint (LCP). Tiempo hasta que el contenido principal es visible. Objetivo: menos de 2,5 s. En una página de categoría o de producto de PrestaShop, casi siempre es la imagen principal o la primera imagen de producto, o un servidor lento que entrega el HTML tarde. Un LCP fallido apunta a imágenes o TTFB.
• Interaction to Next Paint (INP), rapidez con la que responde la página cuando un cliente toca algo. Objetivo: menos de 200 ms. Un INP fallido apunta a JavaScript pesado o duplicado, normalmente demasiados módulos del front office inyectando cada uno sus propios scripts.
• Cumulative Layout Shift (CLS), cuánto salta el diseño durante la carga. Objetivo: menos de 0,1. Un CLS fallido apunta a imágenes servidas sin atributos width/height, fuentes web que se sustituyen tarde o un slider/banner de cookies que empuja el contenido hacia abajo después del pintado.

La cascada y el TTFB: la separación más útil

Abre GTmetrix (o la pestaña Network de DevTools en tu navegador) y mira un número antes que cualquier otra cosa: Time to First Byte (TTFB), el intervalo entre que el navegador pide una página y llega el primer byte de la respuesta. Es la bifurcación más clara de todo el diagnóstico:

• TTFB constantemente por encima de ~500–600 ms en una página con la caché fría → el cuello de botella está del lado del servidor: generación PHP, base de datos o el propio alojamiento. Ninguna compresión de imágenes ni trabajo de front-end va a arreglar esto. Esta es la rama que lleva a soluciones de caché, base de datos y alojamiento.
• TTFB bajo pero la página sigue pareciendo pesada → el servidor está haciendo su trabajo; el peso está en el front-end: imágenes, fuentes, paquetes CSS/JS que se descargan después de que llega el HTML.

Esa única lectura ahorra más esfuerzo desperdiciado que cualquier otra. Los comerciantes que se la saltan pasan días minificando CSS en una tienda cuyo problema era un TTFB de 1,8 s limitado por la base de datos.

El perfilador de depuración de PrestaShop: la lectura de base de datos/módulos que casi nadie ejecuta

Esta es la comprobación específica de PrestaShop que la mayoría de propietarios nunca toca, aunque es la más diagnóstica. En una copia de staging, abre config/defines.inc.php y define _PS_DEBUG_PROFILING_ como true: ese es el interruptor que activa la barra del perfilador en el front office y su lectura del recuento de consultas. La línea exacta que buscas:

// config/defines.inc.php – staging only, switch back to false when done
define('_PS_DEBUG_PROFILING_', true);

En PrestaShop 8 y 9 tienes una segunda lectura, más sencilla: con la tienda en modo de desarrollo, la barra de depuración de Symfony aparece en la parte inferior de cada página del panel de administración y del front office, y muestra el recuento de consultas SQL y el tiempo total de esa petición, sin tocar archivos más allá de activar la depuración. En cualquier caso, el número que te importa es el mismo.

Solo necesitas activar _PS_MODE_DEV_ (modo completo de depuración/errores) si quieres deliberadamente la salida de errores de desarrollo también; no es necesario solo para ver el recuento de consultas, y es más arriesgado dejarlo activo. Después carga una página de categoría y una de producto. PrestaShop muestra una barra de perfilado con el tiempo de carga y, sobre todo, el número de consultas SQL de esa página. Una página sana tiene decenas de consultas; si una sola página de producto dispara varios cientos o un par de miles de consultas, has encontrado la lentitud, y casi siempre es un módulo concreto repitiendo consultas en bucle o una tabla sin índice, no "PrestaShop siendo lento". Vuelve a desactivar ambos interruptores antes de terminar; nunca los dejes activos en producción.

De la lectura a una lista de tareas priorizada

El diagnóstico solo sirve si produce un orden de actuación. Relaciona tus lecturas con la solución, primero la más barata y de mayor impacto, y sigue el enlace a la guía que explica esa corrección a fondo en lugar de conformarte con un párrafo aquí:

Las dos comprobaciones gratuitas que debes hacer antes de gastar nada

Un comando gratuito te da una primera separación entre DNS/tiempo de conexión, espera del servidor y transferencia total. No sustituye a Lighthouse, pero te dice si debes empezar por alojamiento/PHP/base de datos o por el peso del front-end.

url="https://example.com/"
curl -o /dev/null -s -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s total=%{time_total}s
' ";$url

Mantén las cifras de antes y después en un solo lugar, o las optimizaciones se convierten en suposiciones.

Dos correcciones no cuestan nada, vienen con PrestaShop y conviene confirmarlas antes de cualquier compra o actualización, porque cambian todas las demás lecturas que hagas.

Confirma que CCC está activado. Ve a Parámetros avanzados → Rendimiento y activa la caché de Smarty y "Combinar, comprimir y cachear" (CCC) para CSS y JavaScript; si tu configuración de Apache/.htaccess lo admite, activa también las directivas de optimización de Apache / caché del navegador para recursos estáticos (esta opción no se aplica a servidores solo con nginx). Muchas tiendas funcionan durante años con esto desactivado. Actívalo, limpia la caché y vuelve a ejecutar PageSpeed: tus cifras de front-end pueden mejorar por sí solas. (Una advertencia: CCC puede chocar ocasionalmente con los recursos de un módulo mal construido; prueba el escaparate después.)

Audita tu número de módulos. Cada módulo del front office añade CSS, JavaScript y PHP a cada carga de página. Abre Diseño → Posiciones para ver cuántos módulos están enganchados al front office, y desinstala, no solo desactives, todo lo que no estés usando activamente. Una tienda con más de 100 módulos tendrá que pelear contra su propio hardware. La mecánica de qué módulos perjudican y por qué se explica en qué hace realmente lento a PrestaShop.

Dónde un módulo se gana su lugar y dónde no

Cuando tu diagnóstico apunta claramente al tiempo de respuesta del servidor, TTFB alto, cada página regenerada para cada visitante, ese es el caso para el que se creó una caché de página completa. En lugar de que PHP y la base de datos reconstruyan la misma página de categoría miles de veces al día, una caché de página completa sirve HTML ya preparado y el servidor apenas se esfuerza. Nuestro módulo Performance Revolution es nuestra respuesta a esa lectura concreta: cachea páginas completas para que el TTFB baje sin reescribir el tema ni cambiar de alojamiento. Entonces, ¿qué significa eso para ti? Las páginas a las que llegan en frío tus clientes y Google responden rápido, la instalación y configuración se hacen desde el panel de administración en lugar de mediante una factura de desarrollo y, como es el cuello de botella del servidor que has medido, la mejora se nota en todos los visitantes, no solo en los afortunados con una caché caliente.

El límite honesto: una caché de página completa corrige una respuesta lenta del servidor. No reduce una imagen principal de 5 MB ni arregla un diseño que salta; esos son problemas de front-end que marcó tu cascada, y pertenecen a la optimización de imágenes, no a la caché. Ajusta la solución a la lectura. Si lo que pide tu lectura del backend de caché es Redis, nuestro módulo Redis Cache Manager & Monitor cubre esa rama, y la guía dedicada de Redis explica cuándo es la elección correcta.

Mide, corrige, vuelve a medir: durante semanas, no días

Registra tu línea base antes de tocar nada: puntuación móvil de PageSpeed, los tres Core Web Vitals de Search Console, TTFB y tu tasa de conversión de carrito a pedido. Cambia una cosa y vuelve a medir, pero dale tiempo a los datos de campo. El informe de Core Web Vitals de Search Console funciona con una ventana móvil de 28 días, así que una corrección que publiques hoy no se verá por completo en campo hasta dentro de unas semanas. Juzgar una optimización con tres días de datos es la forma en que los comerciantes revierten un cambio que en realidad estaba funcionando. Combina los números de velocidad con el comportamiento: Google Analytics GA4 muestra los tiempos de carga de página, y Microsoft Clarity muestra si las páginas lentas coinciden con clics de frustración y salidas rápidas: el lado humano de un mal LCP.

Por qué merece la pena dedicarle una tarde

El trabajo de velocidad no es glamuroso, pero tiene una cualidad que el marketing rara vez tiene: ayuda a cada visitante, cada vez, sin ninguna campaña que gestionar. La cifra tan citada de que cada segundo extra de carga cuesta conversiones varía según el estudio y según la tienda; trátala como una orientación, no como una promesa, y mide tu propio antes y después en lugar de confiar en un número de blog. Lo fiable es el método: no adivines, comprueba; lee el TTFB para separar servidor de página; deja que la métrica fallida nombre el taller de reparación; aplica primero las dos correcciones gratuitas; y solo entonces gasta dinero en el cuello de botella que realmente has medido. Una tienda diagnosticada correctamente se vuelve rápida con una fracción del esfuerzo de otra optimizada por intuición.

Preguntas frecuentes

Mi puntuación de PageSpeed es buena, pero la tienda sigue pareciendo lenta. ¿Qué se me escapa?

Probablemente estás leyendo la puntuación de laboratorio y sintiendo la realidad de campo, o al revés. El gran círculo de color es una única carga simulada; lo que viven realmente tus clientes son los datos de campo de CrUX que aparecen más arriba en el informe y el informe de Core Web Vitals en Search Console. Comprueba también si estás probando con la sesión iniciada en el panel de administración: una caché caliente y la sesión de administrador favorecen tus números. Prueba en una ventana de incógnito con la red limitada a "Slow 4G" y la diferencia suele explicarse sola.

¿Un TTFB alto siempre es un problema de alojamiento?

No, y asumirlo es el error más caro aquí. Un TTFB alto solo te dice que la lentitud está del lado del servidor; no dice si la causa es la base de datos, un módulo pesado o el hardware. Ejecuta el perfilador: si una página lanza cientos o miles de consultas SQL, eso es la base de datos o un módulo en bucle, y un servidor más grande solo ejecutará las mismas consultas lentas un poco más rápido. Separa ambas cosas antes de gastar dinero: qué hace realmente lento a PrestaShop explica cómo distinguirlas.

¿Una caché de página completa arreglará una mala puntuación de PageSpeed?

Corrige una respuesta lenta del servidor: TTFB alto en páginas regeneradas para cada visitante, y nada más. No reducirá una imagen principal de 5 MB, no arreglará un diseño que salta (CLS) ni desenredará JavaScript que bloquea el renderizado; esos son problemas de front-end que señaló tu cascada. Ajusta la solución a la lectura: caché para la rama del TTFB, optimización de imágenes para la rama LCP/CLS.

¿Cuánto tiempo debe pasar antes de confiar en que un cambio ha funcionado?

Las herramientas de laboratorio reaccionan al instante, pero el informe de Core Web Vitals de Search Console funciona con una ventana móvil de 28 días, así que una corrección que publiques hoy no se verá por completo en campo hasta dentro de unas semanas. Juzgar una optimización con tres días de datos de campo es la forma en que los comerciantes revierten un cambio que en realidad estaba funcionando. Vuelve a ejecutar la prueba de laboratorio de inmediato como comprobación rápida, y después concede a los datos de campo su mes antes de concluir.

¿Es seguro activar el perfilador en mi tienda en producción?

Hazlo en una copia de staging. _PS_DEBUG_PROFILING_ expone información interna y la barra a cualquiera que cargue la página, y _PS_MODE_DEV_ puede filtrar detalles de errores; ninguno de los dos pertenece a producción. Actívalos, toma tus lecturas y vuelve a poner ambos en false. En PS8/9, la barra de Symfony en modo de desarrollo te da el mismo recuento de consultas con la misma advertencia: solo staging.

Lecturas relacionadas

• Performance Revolution, el módulo de caché de página completa + CSS crítico para la rama de TTFB alto, con métricas de antes/después en un único panel
• Qué hace realmente lento a PrestaShop, base de datos frente a módulos frente a alojamiento, una vez que tu lectura de TTFB dice "del lado del servidor"
• Ajuste de rendimiento: de consultas de base de datos a caché de página completa, la corrección profunda para un alto recuento de consultas SQL
• Limpieza de base de datos con el tiempo, para un TTFB que aumenta a medida que la tienda envejece