Su tienda parece lenta para los visitantes y no sabe por dónde empezar. La página de inicio puede parecer correcta, mientras que las categorías, las fichas de producto o el carrito cargan mal. En esos casos, cambiar ajustes al azar suele hacer perder tiempo.
El buen reflejo es diagnosticar en el orden correcto. Medir primero, luego aislar el cuello de botella: alojamiento, módulos, base de datos, imágenes, caché o tema. Este artículo se centra en el front-office. El back-office lento es otro asunto.
Al final sabrá qué comprobar, en qué páginas y cuándo conviene pasar del diagnóstico a una intervención técnica.
Comience por medir la lentitud, no por cambiar ajustes al azar
La primera trampa es simple: activar un caché, comprimir archivos o culpar al tema sin un punto de partida fiable. El 13 de octubre de 2026, la documentación para desarrolladores de PrestaShop recomienda hacer benchmarks antes de cualquier modificación, para disponer de una referencia y luego verificar si los cambios mejoran realmente la tienda: documentación desarrollador PrestaShop sobre optimización.
Este punto de referencia debe enfocarse en el front-office. Si su problema es la velocidad para el visitante, no lo mezcle con problemas de administración o del back-office.
Distinguir puntuación de laboratorio y datos reales de visitantes
Una puntuación por sí sola no indica la causa de una tienda lenta. El 13 de octubre de 2026, Google explica cómo funciona PageSpeed Insights: la herramienta combina datos de laboratorio y datos reales de usuarios. Los datos de campo provienen del Chrome User Experience Report y cubren un periodo móvil de 28 días.
En la práctica, los datos de laboratorio sirven para reproducir un problema en un entorno estandarizado. Los datos reales muestran lo que han sufrido sus visitantes a lo largo del tiempo. Los umbrales “Good” mencionados por Google son, entre otros, un LCP ≤ 2,5 s, un INP ≤ 200 ms y un CLS ≤ 0,1. Si una puntuación es mala, aún hay que entender en qué página y en qué recurso se concentra el problema.
Elegir las páginas a probar: inicio, categoría, ficha producto, carrito
No pruebe una sola URL. Tome como mínimo una página de inicio, una categoría, una ficha de producto y el carrito. Esta selección evita un diagnóstico falso del tipo “la web va bien” cuando solo las páginas más rentables son las lentas.
Mantenga la misma selección antes y después de cada cambio. Anote las métricas que realmente se degradan y detecte si la lentitud afecta a toda la tienda o solo a ciertas páginas. Ese cribado le dirá si debe mirar primero el servidor, un módulo, la base o el tema.
El alojamiento y la pila PHP suelen ser el primer cuello de botella
Cuando varios tipos de páginas están lentos al mismo tiempo, el servidor y la pila PHP suelen ser lo primero que conviene revisar. El objetivo no es recomendar cambiar de alojamiento por reflejo; primero hay que aislar el cuello de botella y confirmarlo mediante medición.
Si duda entre problema de servidor, configuración PHP o sobrecarga a nivel de aplicación, mantenga la misma metodología: un cambio y luego un benchmark. Sin esa disciplina, cambia muchas cosas sin poder afirmar cuál mejoró realmente la tienda.
Señales que apuntan a un problema de servidor
La señal más útil es una lentitud bastante transversal: inicio, categorías, fichas de producto y carrito se degradan conjuntamente. En ese caso, culpar de inmediato a las imágenes o al tema suele ser prematuro.
Otro punto práctico: haga un benchmark antes de modificar el entorno. La recomendación de PrestaShop aplica también aquí. Sin una medición antes/después, puede ajustar el alojamiento o PHP y luego no saber si el problema real se resolvió.
Ajustes técnicos a comprobar en PHP y ficheros
El 13 de octubre de 2026, la documentación para desarrolladores de PrestaShop cita dos palancas concretas en PHP y sistema de ficheros: realpath_cache, que evita repetir comprobaciones de ficheros, y OPCache, que guarda el bytecode PHP compilado en memoria compartida. Son puntos concretos a revisar antes de concluir que la tienda es “naturalmente pesada”.
Un error frecuente es modificar varios parámetros a la vez. Haga lo contrario: un cambio, un benchmark y luego validación. Es la única forma de saber si la lentitud venía del entorno o de otra capa.
Los módulos no son problemáticos por su número, sino por lo que cargan en sus páginas
Decir que un sitio es lento “porque hay demasiados módulos” suele ser una afirmación demasiado vaga para ser útil. PrestaShop indica que ciertos módulos ralentizan la tienda, sobre todo si están enganchados en zonas críticas del front-office. La cuestión real no es solo el número, sino qué ejecutan, dónde se ejecutan y con qué caché.
Los hooks de front-office que cuestan caro
Empiece por las páginas que más importan a sus visitantes: categorías, fichas de producto y carrito. Un módulo conectado a esas zonas puede pesar mucho si carga código, realiza consultas o añade recursos donde no es necesario.
La documentación de usuario de PrestaShop 8 recuerda también que algunas funcionalidades pueden desactivarse si no se usan, porque pueden ralentizar la tienda. Es un buen criterio de selección: todo lo que siga activo debe tener una utilidad clara en la página correspondiente.
Señales de que un módulo está realmente ralentizando la tienda
El 13 de octubre de 2026, PrestaShop cita varias señales útiles: consumo excesivo de recursos, ausencia de caché, sobrecarga por caché mal gestionada y módulo activado en demasiadas páginas. Estos indicios son más fiables que el mero recuento de módulos instalados.
Si sospecha de un módulo concreto, compruebe primero su perímetro de activación y la calidad de su integración. También puede comparar con los signos que permiten detectar un módulo PrestaShop mal codificado. El error frecuente es desactivar en bloque sin método y luego perder la pista del verdadero culpable.
La base de datos puede ralentizar sobre todo las fichas de producto y las categorías
La base de datos no es el culpable automático de un PrestaShop lento. Sin embargo, se convierte en una pista creíble cuando ciertas páginas métier sufren más que otras. Un caso frecuente: la página de inicio sigue siendo aceptable, pero las categorías y fichas de producto arrastran la velocidad hacia abajo.
Cuándo sospechar de la base de datos
Si la lentitud se concentra en las páginas que solicitan más al catálogo, combinaciones, precios o listados de producto, la base merece una comprobación. En cambio, si todas las páginas están lentas al mismo nivel, conviene mirar antes al servidor o a los módulos.
La buena práctica sigue siendo la misma: medir primero y luego aislar. Afirmar que la base es la culpable porque es “grande” suele llevar a prioridades equivocadas.
Lo que la documentación de PrestaShop recomienda antes de un benchmark
El 13 de octubre de 2026, la documentación para desarrolladores de PrestaShop recomienda, si es posible, un innodb_buffer_pool_size superior al tamaño de la base. También aconseja ejecutar un ANALYZE TABLE tras una importación y antes del benchmark. Estos dos puntos evitan una prueba sesgada por un entorno mal preparado.
Si la base contiene muchos datos ya inútiles, una limpieza controlada puede simplificar el análisis. El módulo gratuito de limpieza de base de datos PrestaShop puede servir como punto de partida, pero no sustituye a la medición antes/después.
Las imágenes penalizan sobre todo el LCP cuando se sirven mal, no solo cuando pesan mucho
Reducir el tema de las imágenes a la compresión es insuficiente. Una imagen ya optimizada puede seguir ralentizando una página si se carga en el momento equivocado o con la prioridad incorrecta. Esto es especialmente cierto para la recurso que impacta el LCP.
No lazy-loadear la imagen hero o la imagen LCP
La recomendación de web.dev es clara: las imágenes situadas por debajo del pliegue pueden cargarse en lazy loading, pero no la imagen hero o la imagen LCP que está por encima del pliegue. Esta imagen crítica debe cargarse eager: guía web.dev sobre imágenes responsive y prioridad de carga.
Es un error frecuente en temas e-commerce: todo se pone en lazy loading “por seguridad”, incluida la imagen que debería llegar primero. Como resultado, el visitante espera el elemento principal de la página cuando no debería demorarse.
Qué cargar de forma diferida y qué dejar como prioritario
Para las imágenes verdaderamente secundarias, el lazy loading nativo es un buen comienzo en la mayoría de los casos, sobre todo porque evita añadir una dependencia JavaScript dedicada: explicaciones web.dev sobre lazy loading nativo de imágenes.
En cambio, una imagen realmente crítica puede recibir fetchpriority="high", con moderación. La palabra clave es moderación. Si da prioridad alta a demasiados recursos, solo mueve el problema en vez de corregirlo.
Caché, tema y plan de acción: lo que confirma el diagnóstico
En PrestaShop, el caché y la compresión de assets ayudan, pero no corrigen por sí solos una arquitectura lenta. El centro de ayuda de PrestaShop indica que el caché Smarty acelera los tiempos de carga al servir una página desde caché en visitas sucesivas. Añade que la compresión CSS y JS se configura en la página Rendimiento de la tienda.
El 13 de octubre de 2026, la documentación para desarrolladores de PrestaShop recomienda usar el tipo de caché “File System” y activar el caché Smarty. También precisa no activar la sección “Cache” si MySQL (<8) o MariaDB se ejecutan en la misma máquina, ya que el query cache de MySQL puede ser más eficiente allí. En otras palabras, no todos los cachés deben activarse en todas partes sin probar.
Lo que un tema puede romper en el front-office sin ser “malo” visualmente
Un tema puede parecer correcto visualmente y, sin embargo, concentrar varias causas de lentitud: assets demasiado pesados, JavaScript invasivo, dependencias innecesarias, gestión inadecuada de imágenes o compresión mal configurada. El problema no es solo el diseño, sino todo lo que el tema incorpora y desencadena.
Cuando analice un tema, considérelo como un punto de encuentro entre servidor, módulos, imágenes y caché. Ahí es donde con frecuencia problemas separados se hacen visibles en el front-office.
El orden de verificación para decidir si corrige internamente o si encarga intervención
He aquí el orden más útil para mantener un diagnóstico comprensible:
- medir en varios tipos de páginas;
- verificar si la lentitud es global o localizada;
- comprobar el entorno servidor y PHP;
- aislar los módulos presentes en las páginas críticas;
- examinar la base si las categorías y fichas de producto sufren más;
- corregir la prioridad de carga de las imágenes;
- validar las opciones de caché y compresión;
- volver a probar tras cada cambio.
Si sus mediciones siguen siendo confusas o si se acumulan varias causas, deténgase en el diagnóstico antes de modificar la producción. Una serie de pequeños ajustes mal coordinados empaña rápidamente el análisis.
Si desea que alguien ordene estas causas en el orden correcto, KLN-WEB ofrece un diagnóstico para sitio PrestaShop lento centrado en el front-office. Obtendrá un diagnóstico gratuito, respuesta en 24 h y una tarifa horaria anunciada de antemano.
Preguntas frecuentes
¿Cómo saber si la lentitud viene del alojamiento o de un módulo PrestaShop?
Empiece por medir varias páginas: inicio, categoría, ficha de producto y carrito. Si todo está lento de forma bastante uniforme, el servidor o la configuración PHP suelen ser lo primero a comprobar. Si la lentitud se concentra en páginas concretas, mire antes los módulos activos en esas zonas, su caché y su perímetro de ejecución.
¿Debo fiarme de la puntuación PageSpeed o de los datos reales de los visitantes?
Hay que usar ambos, sin confundirlos. La puntuación de laboratorio ayuda a reproducir un problema en un entorno estandarizado. Los datos reales muestran lo que han experimentado sus visitantes durante un periodo móvil de 28 días. Una mala puntuación no basta para señalar la causa: hay que identificar la página afectada y el cuello de botella.
¿Tener demasiados módulos ralentiza siempre un sitio PrestaShop?
No. El número por sí solo no explica la lentitud. Lo que realmente pesa es lo que los módulos cargan en las páginas críticas del front-office, la calidad del código, su uso del caché y su presencia en demasiadas páginas. Un pequeño número de módulos mal integrados puede causar más problemas que muchos bien gestionados.
¿Una base de datos muy grande puede ralentizar el front-office?
Sí, pero no de forma automática. La base se convierte en una pista seria cuando las categorías y fichas de producto son claramente más lentas que la página de inicio. Entonces conviene confirmarlo con mediciones, preparar el benchmark y evitar culpar a la base por defecto mientras no se hayan descartado servidor, módulos y tema.
¿Por qué mis imágenes siguen ralentizando la tienda aunque ya estén comprimidas?
Porque el problema no es siempre su peso. Una imagen crítica puede degradar el LCP si está lazy-loadeada cuando debería cargarse inmediatamente, o si su prioridad de carga está mal gestionada. En cambio, las imágenes bajo el pliegue pueden cargarse de forma diferida para no retrasar lo esencial.