PageSpeed 99/100 en una tienda PrestaShop 9.1 real con más de 80 módulos
La mayoría de los estudios de caso sobre PageSpeed hacen trampa. Muestran un tema de demostración casi vacío, con una imagen principal, tres productos y ningún módulo real, sacan 100 puntos y lo presentan como una prueba. Eso no demuestra nada: cualquier PrestaShop vacío puntúa bien. La pregunta difícil que de verdad se hace cualquier propietario de tienda es otra: ¿puede una tienda que trabaja de verdad, carruseles, megamenú, proceso de pago en una sola página, búsqueda en tiempo real, blog, ventanas emergentes, fidelización, analítica, seguir siendo rápida? Este artículo responde a esa pregunta con nuestra propia tienda en producción, no con un entorno de pruebas.
Revisado con la página de inicio activa de mypresta.rocks sobre PrestaShop 9.1. Las puntuaciones que aparecen abajo proceden de Google PageSpeed Insights en nuestro sitio en producción, no de una copia de preproducción ni de una herramienta local.
mypresta.rocks funciona con PrestaShop 9.1 y más de 80 módulos activos, y no precisamente del tipo ligero que solo añade configuración. Son módulos que incluyen su propio CSS y JavaScript, se integran en el front office y renderizan elementos visibles e interactivos: carruseles animados, un megamenú desplegable, un proceso de pago completo en una sola página, un motor de blog con comentarios y opciones para compartir, un widget de búsqueda en tiempo real, flujos de redes sociales, galerías de producto, ventanas emergentes de ventas, temporizadores de cuenta atrás, un banner de consentimiento de cookies, fidelización y paneles de analítica. Es exactamente el tipo de pila que normalmente destroza una puntuación de PageSpeed. La nuestra se mantiene en 99.
Este artículo es el estudio de caso: los números reales de nuestra página de inicio en vivo y cómo está estructurado el pipeline que los produce. No pretende ser otro tutorial genérico de "hacer que PrestaShop vaya rápido": para la mecánica de fondo enlazamos a las guías hermanas que tratan cada tema con el detalle que merece, para que puedas profundizar tanto como necesites sin que repitamos lo mismo.
Las puntuaciones, medidas por Google, no por nosotros
Estos datos vienen de Google PageSpeed Insights, que ejecuta Lighthouse en la propia infraestructura de Google contra nuestra página de inicio activa. No son cifras de una herramienta local que puedas maquillar; son lo que devuelve ahora mismo el mismo informe que consulta cualquier comerciante.
| Categoría | Móvil | Escritorio |
|---|---|---|
| Rendimiento | 99 | 99 |
| Accesibilidad | 97 | 97 |
| Buenas prácticas | 100 | 100 |
| SEO | 100 | 100 |
La puntuación de rendimiento es una combinación ponderada de las métricas de laboratorio de Core Web Vitals, así que las métricas que hay detrás del número importan más que el número en sí. Este es el desglose completo para ambos formatos.
| Métrica | Móvil (4G lento, Moto G Power) | Escritorio |
|---|---|---|
| First Contentful Paint (FCP) | 1.2s | 0.3s |
| Largest Contentful Paint (LCP) | 1.5s | 0.9s |
| Total Blocking Time (TBT) | 110ms | 30ms |
| Cumulative Layout Shift (CLS) | 0 | 0.011 |
| Speed Index (SI) | 1.4s | 0.5s |
La columna móvil es la que cuenta. Google indexa primero en móvil y limita la prueba móvil a 4G lento en un teléfono de gama media, algo durísimo frente a la ejecución de escritorio con una conexión rápida. Un LCP de 1,5s y un CLS de exactamente 0 bajo esa limitación, con más de 80 módulos en vivo, es el resultado que queríamos demostrar. ¿Y qué te aporta eso? Una tienda en la que la página se puede usar en alrededor de un segundo en un teléfono real y con una red real, justo donde ocurre la mayor parte de tu tráfico y también buena parte de tus abandonos.
Por qué los más de 80 módulos son el punto clave
El número de módulos es la variable que todo el mundo teme y casi nadie mide con honestidad. Cada módulo de front office en PrestaShop tiende a añadir tres costes: CSS extra, JavaScript extra y ejecución adicional de hooks en cada renderizado de página. El sistema CCC de PrestaShop (Parámetros avanzados → Rendimiento, "Combinar, comprimir y cachear") reduce y combina el CSS y el JS elegibles, a menudo en muchos menos archivos generados, cuántos exactamente depende de cómo el tema y los módulos registren sus recursos, tipos de medio y exclusiones, lo que resuelve buena parte del problema del número de peticiones, pero crea un problema de peso: en nuestra tienda, la hoja de estilos combinada superaba los 850KB antes de tratarla, y la inmensa mayoría eran reglas que nunca se activaban en la página de inicio.
Esa es la verdadera razón por la que las tiendas pesadas se sienten lentas: no "demasiados módulos" como si fuera un pecado, sino megabytes de CSS/JS combinados que bloquean el primer pintado mientras el navegador analiza reglas y scripts que el visitante nunca va a activar. Si quieres la versión de diagnóstico de esto, cómo saber qué capa te está perjudicando de verdad, ese es un tema hermano, cubierto en qué hace realmente lento a PrestaShop y en el flujo de comprobación de si tu tienda es lenta, cómo comprobarlo. El punto aquí es que mantuvimos los más de 80 módulos y atacamos el peso de los recursos en lugar de eliminar funciones.
Cómo está construido el pipeline, capa por capa
No hay un único interruptor. El 99 es la suma de un pipeline disciplinado que toca la ruta de renderizado en cada capa. A continuación explicamos qué hace cada etapa y, más importante aún, por qué mueve la aguja, con la teoría más profunda enlazada allí donde una guía hermana se ocupa bien del tema.
Extracción de CSS crítico y carga asíncrona
El CSS que bloquea el renderizado es el mayor enemigo de un primer pintado rápido: el navegador no pintará nada hasta tener la hoja de estilos. Incrustar el archivo completo de más de 500KB sería peor, no mejor. En su lugar extraemos el CSS crítico above-the-fold de la página e incrustamos solo ese pequeño fragmento directamente en el HTML; después, la hoja de estilos combinada completa se carga de forma asíncrona con el patrón de intercambio media="print" onload, de modo que se descarga en segundo plano sin bloquear. El navegador pinta inmediatamente usando los estilos críticos incrustados y luego pasa a la hoja completa cuando llega. El beneficio: la página es visible en alrededor de un segundo en lugar de esperar a medio megabyte de CSS y, como el fragmento crítico ya da estilo a lo que se ve en pantalla, el intercambio no provoca ningún desplazamiento de diseño.
Purga de CSS
Con más de 80 módulos, el CSS combinado arrastra miles de selectores que nunca coinciden con nada en una página concreta. Ejecutamos PurgeCSS contra el HTML real renderizado de los tipos de página clave, además de cada archivo JavaScript y de plantilla del tema y los módulos, para que sobrevivan las clases que se activan dinámicamente. En nuestra tienda, eso redujo la hoja de estilos de 852KB a 548KB: un recorte del 36%. Menos CSS significa menos que descargar en 4G lento, menos que analizar en una CPU de gama media y un intercambio más rápido y sin saltos.
División y aplazamiento de JavaScript
No todo el JavaScript necesita ejecutarse antes de que la página sea interactiva. Dividimos el paquete JavaScript de CCC en dos:
- Paquete síncrono (~140KB / 41KB gzip): solo el núcleo que la página realmente necesita al principio: jQuery y los scripts principales de PrestaShop.
- Paquete diferido (~497KB / 111KB gzip): Bootstrap, scripts del tema y scripts no críticos de módulos, cargados con el atributo defer para que se ejecuten después de analizar el documento.
Aplazar el paquete pesado lo mantiene fuera del hilo principal durante la ventana crítica, que es lo que reduce el Total Blocking Time a 110ms en móvil y 30ms en escritorio. TBT es la métrica donde más fallan las tiendas con muchos módulos, porque todos los scripts de cada módulo quieren ejecutarse a la vez al cargar.
Carga inteligente de recursos según la página
El patrón más derrochador en el rendimiento de PrestaShop es enviar JavaScript de pago y métodos de pago a visitantes que están leyendo el blog. Cargamos según el contexto: el JavaScript del proceso de pago (más de 180KB minificado) se difiere por completo en páginas que no son de pago, se incorpora mediante requestIdleCallback en la página de inicio y en páginas de contenido para que esté preparado si hace falta pero nunca compita durante el primer pintado, y se carga de inmediato solo en páginas de producto, carrito y pago, donde realmente se utiliza. El JavaScript de pago de Stripe se elimina por completo de las páginas que no son de pago. ¿Y eso qué implica? Un cliente que aterriza en una entrada de blog o en una categoría no paga el coste de descarga y ejecución de un proceso de pago en el que aún no está.
Optimización de imágenes sin sobrecarga de PHP
Las imágenes suelen ser el elemento LCP, así que deciden la métrica con más peso. Cada imagen de producto y banner se sirve en AVIF mediante negociación de contenido en Apache: el cambio al formato moderno ocurre en la capa del servidor web, con cero sobrecarga de PHP por petición. Nuestro conversor por lotes procesó 5.399 imágenes y redujo el almacenamiento total de imágenes de 994MB a 44MB (un 95,6% menos). El banner principal móvil termina pesando 25KB y la versión de escritorio 56KB, ambos con una calidad en la que no notarías la compresión.
La parte de Apache es solo negociación de contenido: servir un .jpg.avif o .png.avif pregenerado únicamente cuando el navegador anuncia soporte AVIF, y mantener Vary: Accept para que las cachés no mezclen formatos.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/avif
RewriteCond %{DOCUMENT_ROOT}/$1.$2.avif -f
RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.avif [T=image/avif,E=avif:1,L]
</IfModule>
<IfModule mod_headers.c>
Header append Vary Accept env=avif
</IfModule>
La vista general de optimización de recursos muestra tarjetas de estado para optimización de recursos, Critical CSS, PurgeCSS y lazy loading, además de paneles CSS, JavaScript e imagen con recuentos de archivos y tamaños en cero, sobre una lista de recursos vacía.
Una lección contraintuitiva vale más que cualquier ajuste: precargamos solo la imagen LCP móvil y nada más. En 4G lento, a unos 200KB/s, cada precarga adicional compite con el CSS crítico por el mismo conducto estrecho. Precargar una fuente web o el banner de escritorio empeoró de hecho nuestro FCP móvil: lo medimos, lo revertimos, y esa contención forma parte de por qué el LCP llega a 1,5s.
Accesibilidad como objetivo deliberado, no como efecto secundario
La puntuación de 97 en Accesibilidad está diseñada, no es suerte. Exigió mantener cada elemento dentro del contraste WCAG 2.1 AA (4,5:1 para texto normal, 3:1 para texto grande), indicadores de foco visibles en elementos interactivos, una jerarquía de encabezados correcta con etiquetas ARIA y un uso adecuado de una utilidad visualmente oculta para que los lectores de pantalla reciban contenido que no se muestra visualmente. Por qué debería importarle a un propietario de tienda: la misma disciplina que hace accesible una página, contraste honesto, sin saltos de diseño, foco predecible, es la disciplina que mantiene el CLS en 0 y evita que clientes reales hagan clic donde no querían. Accesibilidad y conversión empujan en la misma dirección.
Un punto caliente de renderizado que provocamos y luego corregimos: la parte honesta
Nada de esto salió limpio al primer intento, y la lección más útil vino de una regresión que introdujimos nosotros mismos. En cierto momento, nuestros propios renderizados de página empezaron a subir hasta aproximadamente 2,2 segundos en el servidor: lo bastante lento como para que el trabajo de front-end anterior quedara anulado antes de que saliera un solo byte de la máquina. La causa no era el tema ni la base de datos. El pipeline de recursos estaba calculando el hash de cada paquete combinado en cada petición para construir su clave de caché: con el CSS/JS combinado dividido en muchos archivos, estaba haciendo sha1 de unos 670 paquetes en cada carga de página. Ese hashing era sobrecarga pura repetida en cada visita, y dominaba el renderizado.
La solución fue dejar de recalcular lo que no cambia entre peticiones, cachear las huellas de los paquetes en lugar de volver a calcular el hash de los archivos cada vez, y el tiempo de renderizado volvió a donde debía estar. Lo mencionamos porque es el tipo de coste que nunca aparece en una prueba de laboratorio de PageSpeed sobre una página caliente; solo lo detectas observando el tiempo real de generación del lado del servidor bajo tráfico. Si tu TTFB es alto mientras tus métricas de front-end parecen correctas, el cuello de botella es algo que el servidor repite en cada petición, y la única forma de encontrarlo es medir el tiempo de generación de página, no la puntuación destacada.
La otra mitad de mantener una puntuación estable es asegurarse de que los visitantes y Google lleguen a una página caliente, no fría. Ejecutamos un calentador de caché sobre todo nuestro conjunto de URL, del orden de 6.625 URL, para que el primer visitante real de cualquier página no sea quien pague el coste de regenerarla. Una caché solo ayuda a las peticiones que llegan después de estar llena; calentarla deliberadamente es lo que convierte "rápida para el segundo visitante" en "rápida para el primero".
Qué no cubre deliberadamente este estudio de caso
La optimización del renderizado front-end es solo la mitad de la velocidad de una tienda. La otra mitad es lo que ocurre en el servidor antes de que un solo byte llegue al navegador: tiempo de consulta de base de datos, caché de objetos, caché de página completa y alojamiento. Cada uno de esos temas tiene suficiente profundidad como para merecer su propia guía, no un párrafo aquí. Tratarlos bien en otros lugares también es la forma de evitar decirte lo mismo cinco veces en cinco artículos.
- Base de datos y carga de consultas. Una capa de consultas lenta limita lo rápida que puede sentirse cualquier interfaz, y una tienda que era ágil el primer día se vuelve más pesada a medida que crecen las tablas. La mecánica está en optimización del rendimiento desde consultas de base de datos hasta caché de página completa, y el ángulo de "por qué se degrada con el tiempo" en limpieza de base de datos.
- Caché de página completa. Servir una página HTML cacheada evita PHP y la base de datos por completo para visitas anónimas repetidas; qué hacen realmente los módulos FPC y cuáles son sus compromisos está en explicación de los módulos de caché de página completa para PrestaShop.
- Caché de objetos del lado del servidor con Redis. Por qué ayuda y qué puedes esperar está en Redis para PrestaShop, con la configuración práctica en configuración de caché Redis y mejoras de rendimiento.
- Alojamiento. Incluso el front-end más rápido se apoya en un servidor; qué importa de verdad frente a lo que es marketing está en elegir alojamiento para PrestaShop.
Cómo reproducir esto en tu propia tienda
Si tomas las cifras anteriores e intentas verificar un cambio en tu tienda, hazlo de una forma que resista el análisis, no de una forma que te engañe. Antes de tocar nada, ejecuta PageSpeed Insights en la página que te importa y anota por separado las cuatro métricas de laboratorio que impulsan la puntuación, LCP, TBT, CLS y Speed Index, para móvil y escritorio, porque se mueven de forma independiente. Haz una categoría de cambios cada vez (CSS, luego JS, luego imágenes), vuelve a probar y conserva el cambio solo si la métrica a la que apunta mejoró de verdad. La lección de la precarga anterior es la advertencia: un cambio que suena a optimización puede hacer retroceder el FCP móvil, y solo lo detectas si mides antes y después en lugar de confiar en el folleto.
Una advertencia honesta sobre las puntuaciones en sí: los resultados de laboratorio de PageSpeed varían unos puntos de una ejecución a otra y dependen de la página probada y de la carga actual del servidor. Trata 99 como "excelente de forma constante", no como una constante fija: lo que se mantiene estable es la forma del resultado, un LCP móvil por debajo de 2 segundos y un CLS casi cero en una tienda con todas sus funciones.
Las preguntas que suele provocar este estudio de caso
¿Eliminasteis módulos para llegar a 99? No: ese es precisamente el punto. Los más de 80 módulos de front office siguieron activos: carruseles, megamenú, proceso de pago en una sola página, búsqueda en tiempo real, blog, ventanas emergentes, fidelización, analítica. Atacamos el peso de los recursos, CSS crítico, purga, división y aplazamiento de JS, AVIF, no la lista de funcionalidades. Una puntuación que consigues eliminando funciones no es un resultado que una tienda real pueda usar.
¿Son solo trucos de front-end o el servidor también importa? Ambas cosas, y son dos mitades separadas. Todo lo que aparece en este estudio de caso es optimización del renderizado front-end: hace que la página se pinte rápido una vez que PHP ha producido el HTML. El servidor aún tiene que producir ese HTML con rapidez, y ahí entran la base de datos, la caché de objetos (Redis), la caché de página completa y el alojamiento, cubiertos en las guías hermanas. El punto caliente de renderizado anterior es la prueba: un tiempo lento de generación del lado del servidor hundirá una buena puntuación de front-end, y solo lo ves midiendo TTFB, no el número principal.
¿Mi puntuación se mantendrá o irá saltando? Los resultados de laboratorio de PageSpeed varían unos puntos entre ejecuciones y dependen de la página probada y de la carga actual del servidor. Trata 99 como "excelente de forma constante", no como una constante fija. Lo que se mantiene estable es la forma, un LCP móvil por debajo de 2 segundos y un CLS casi cero, porque eso viene del pipeline, no de una ejecución con suerte.
¿Esto se rompe cuando actualizo PrestaShop o el tema? El pipeline trabaja en la capa de recursos en lugar de bifurcar tu tema, así que no pelea con una actualización del núcleo o del tema como lo hace un tema editado a mano. Es deliberado: una optimización de renderizado que se rompe en la siguiente actualización no vale la puntuación que te dio.
¿Por qué precargar solo la imagen LCP móvil? Porque en 4G lento, a unos 200KB/s, cada precarga adicional compite con el CSS crítico por el mismo conducto estrecho. Medimos que precargar una fuente web o el banner de escritorio hacía que el FCP móvil fuera peor, lo revertimos, y esa contención forma parte de por qué el LCP llega a 1,5s. La precarga es un bisturí, no una opción por defecto.
Dónde entran los módulos
La razón por la que existe este estudio de caso es que cada técnica anterior no es una solución puntual que construimos a mano para nuestro propio sitio y nos guardamos para nosotros: está empaquetada. En la configuración que medimos para este estudio, el módulo Performance Revolution es el pipeline detrás de estos números; el informe PageSpeed en vivo de nuestra página de inicio es la prueba: la extracción de CSS crítico y el intercambio asíncrono, la purga de CSS, la división de JavaScript síncrono/diferido, el aplazamiento del proceso de pago y Stripe según la página, y la entrega de imágenes AVIF. ¿Y qué significa eso para ti? Obtienes desde tu back office la optimización front-end que consiguió este 99, en lugar de pagar a un desarrollador para reconstruir a mano un pipeline de renderizado; y como funciona en la capa del pipeline de recursos en lugar de bifurcar tu tema, no se rompe en la siguiente actualización.
El front-end es la mitad de la pila, así que lo combinamos con Redis Cache Manager & Monitor para caché de objetos del lado del servidor: el pipeline front-end hace que la página se renderice rápido una vez que PHP la ha producido, y Redis hace que PHP la produzca más rápido. Juntos cubren las dos mitades del problema de velocidad que describen este artículo y sus guías hermanas del lado del servidor.
La conclusión es concreta y honesta: una tienda PrestaShop 9.1 real, con más de 80 módulos activos y pesados en front-end, puede sacar 99/100 en la misma prueba de Google que usas para juzgar la tuya. No requiere eliminar funciones ni usar un tema de demostración vacío. Requiere atacar el peso de los recursos en lugar de la lista de funcionalidades, medir cada cambio en el perfil móvil que Google realmente pondera y tratar las capas del lado del servidor, base de datos, caché de página completa, Redis, alojamiento, como la otra mitad del trabajo, no como una ocurrencia tardía.