Caso real: colchoneriasgonzalez.com — tienda de colchones online en Madrid (PrestaShop 9, tema Hummingbird, CSS y plantillas propias, Plesk + nginx). El cliente quería mejorar PageSpeed Insights PrestaShop: la home se veía bien, pero el informe móvil salía en naranja.
Medí la homepage con PageSpeed Insights / Lighthouse 13.4.1, emulación Moto G Power y Slow 4G. No hay módulo mágico. Hay un Largest Contentful Paint alto, un CSS del tema de unos 100 KiB y un HTML enorme por el mega-menú. Este artículo es solo eso: laboratorio móvil en una tienda PrestaShop 9 en producción.
Qué se veía en PageSpeed Insights móvil
La home “pintaba”. El laboratorio no. En la captura del 21 de agosto de 2026 la puntuación de Performance era 71. El LCP de la foto del hero estaba en 5,8 s (rojo). El FCP, 2,7 s. El Speed Index, 4,4 s. Accesibilidad 92. Best Practices 100. SEO 100. TBT 130 ms. CLS 0.
Eso es lo que busca un dueño de tienda: un número naranja y un LCP que no baja.
Diagnóstico: el LCP era el hero, no un misterio
El Largest Contentful Paint de esta home es la foto del hero. Encima, el CSS que bloquea el renderizado: el bundle del tema Hummingbird (~100 KiB) más custom.css. PageSpeed seguía midiendo unos 1.030 ms de CSS bloqueante después del trabajo. Ese retraso se aceptó a propósito; más abajo explico por qué.
El HTML de la homepage es enorme. El mega-menú de Hummingbird va antes del hero en el DOM. Eso no se arregla instalando un módulo de velocidad. Es una realidad de PrestaShop + Hummingbird en un catálogo de verdad. El laboratorio de Lighthouse PrestaShop (móvil, Slow 4G) lo deja negro sobre blanco: primero parseas menú y CSS, después pintas la foto.
Qué encontramos
La imagen del hero
Una foto de hero a 1600 px en JPEG es peso muerto en un móvil de ~360 px de ancho. Aquí el arreglo fue quirúrgico: WebP al tamaño que se ve (hero-720.webp, unos 18 KiB para ~721×480), srcset 640/720/960, fetchpriority="high", preload y decoding="sync". El logo también a WebP con srcset. Los logos del footer, ancho y alto reales más loading="lazy".
El CSS del tema
Hummingbird sirve un CSS grande. PageSpeed dice: diferirlo y ahorras ~1.000 ms. En esta tienda, diferirlo destruye la puntuación. Lo dejo bloqueante, con caché larga en nginx, y custom.css?v=… para no servir CSS viejo.
Las fuentes
Manrope y Outfit autoalojadas en .woff2. Sin ida y vuelta a Google Fonts. El @font-face está fusionado en custom.css: una petición CSS menos.
La trampa del CSS asíncrono
Esta es la lección del caso. Probé los “trucos listos” que el propio informe sugiere. En LCP parecían una victoria. En la puntuación, un desastre. Los revertí.
| Intento | Qué pasó |
|---|---|
Cargar el CSS del tema con media="print" + onload |
Performance 69. TBT ~960 ms. FOUC. Se revirtió. |
Hero primero en el HTML (cabecera después de main) + CSS del tema en window.load |
LCP 2,5 s, pero CLS PrestaShop 0,237 y TBT 520 ms. Puntuación 71. Se revirtió. |
Retrasar el <img> del hero hasta window.load |
Lighthouse seguía contando la foto como LCP a ~3,3 s (descarga tarde). Inútil. |
Lección: en PrestaShop + Hummingbird, parsear ~100 KiB de CSS del tema después del primer pintado cuenta como Total Blocking Time. Mover la cabecera detrás del hero mejora el LCP en el informe y luego la cabecera “salta”: el CLS te mata la nota. El montaje estable es CSS bloqueante, cabecera primero en el HTML, TBT ~0, CLS 0, LCP ~3,4 s, puntuación 90. No persigas un 100 rompiendo la tienda.
Cómo mejorar PageSpeed Insights PrestaShop sin trucos que rompen la tienda
El trabajo fue en el tema, las imágenes y nginx. Archivos tocados (sin pegar muros de código):
themes/hummingbird/templates/_partials/head.tplthemes/hummingbird/templates/_partials/stylesheets.tplthemes/hummingbird/templates/_partials/cg/home.tplthemes/hummingbird/assets/css/custom.cssthemes/hummingbird/assets/img/cg/hero-*.webp- Directivas extra del vhost nginx para caché larga de estáticos
Tras cada despliegue, caché de compilación Smarty vaciada.
- Hero a tamaño real. WebP al ancho que se muestra,
srcset, preload yfetchpriority="high". No un JPEG de 1600 px. - Logo y footer. Logo en WebP con
srcset. Logos del pie con width/height yloading="lazy". - Fuentes propias. Manrope + Outfit en
.woff2dentro decustom.css. Una petición menos. - Caché de estáticos. nginx
expires 1y/immutablepara CSS, JS, fuentes e imágenes del tema. Después de cambiar CSS, subir el?v=. - Analytics.
gtagcomotype="text/plain"hasta el consentimiento (cg_cookies). No se ejecuta en el primer pintado. - CSS del tema: bloqueante a propósito. No
media="print", no aplazar el CSS awindow.load, no reordenar la cabecera detrás del hero.
Más tarde, un pase corto de accesibilidad (contraste de la tira de confianza, role="img" en valoraciones, alt de producto, H4 del footer a <p>, <aside> anidados a <div>). No es el centro de este artículo; sí entra en la captura del 26 de agosto.
Resultado
Captura del 26 de agosto de 2026, 20:13 GMT+2. Misma receta de laboratorio: móvil, Slow 4G, Moto G Power, Lighthouse 13.4.1.
- Performance 90 (antes ~71).
- FCP 1,7 s (antes 2,7 s).
- LCP 3,4 s (antes 5,8 s). Sigue en naranja. Es el Core Web Vital que queda.
- TBT 20 ms. CLS 0. Speed Index 3,1 s.
- Accesibilidad 100 en esta captura (el 21 de agosto estaba en 92).
Un 90 en laboratorio móvil es una puntuación fuerte para una tienda de catálogo. Un 100 en Slow 4G, con ~100 KiB de CSS de tema y un HTML de mega-menú, no es realista: es marketing. Los Core Web Vitals PrestaShop de esta home siguen teniendo el LCP como deberes; el siguiente trabajo seguro no es más CSS asíncrono, es no romper lo que ya está estable.
Sigue habiendo ~1.030 ms de CSS bloqueante (tema + custom). Está aceptado. Lo medí. Lo dejé.
Prevención: checklist para dueños de tienda
Si quieres optimizar velocidad PrestaShop sin improvisar en producción:
- Mide siempre en móvil con Slow 4G, no solo en escritorio.
- No hagas asíncrono todo el CSS del tema porque el informe lo pida. En Hummingbird eso infla el TBT o el CLS.
- Sirve WebP al tamaño que se ve. Un hero de 1600 px no “da calidad”: retrasa el LCP.
- Autoalojar fuentes. Menos idas y vueltas.
- Caché de estáticos a 1 año +
?v=cuando cambies CSS. - Vaciar la caché Smarty después de tocar plantillas.
- No persigas 100 a costa de un FOUC o de una cabecera que salta.
Hay una guía más general en cómo mejorar la velocidad de una tienda PrestaShop. Este caso es la parte que el informe no cuenta: lo que pasa cuando aplicas el consejo del CSS asíncrono en Hummingbird.
Preguntas frecuentes
¿Se puede sacar 100 en PrestaShop móvil?
En esta homepage, no de forma honesta. Un 90 con Slow 4G, CSS de tema de ~100 KiB y mega-menú ya es un resultado de tienda. El 100 en ese laboratorio es marketing, no este catálogo.
¿Por qué el LCP no baja de 2,5 s?
Porque bajarlo a 2,5 s en este stack exigió mover la cabecera y aplazar el CSS. El LCP mejoró y el CLS se fue a 0,237: la puntuación volvió a 71. El LCP estable es ~3,4 s, con CLS 0.
¿El CSS asíncrono mejora PageSpeed?
En esta tienda, no. media="print" + onload dejó Performance en 69 y el TBT cerca de 1 s. El CSS bloqueante, con TBT de 20 ms y CLS 0, da 90.
¿Hace falta un módulo de velocidad?
No para este resultado. El trabajo fue plantillas, WebP, fuentes propias y caché nginx. Un módulo no acorta el mega-menú ni convierte el hero al tamaño del móvil.
Conclusión
En Colchonerías González el PageSpeed móvil naranja no era “la tienda está mal”. Era un hero pesado, un CSS de Hummingbird que hay que dejar bloqueante y un HTML largo. Los atajos del informe empeoraron la nota. El montaje aburrido —CSS en el head, cabecera primero, imagen al tamaño que se ve— subió de 71 a 90 y dejó el CLS en 0.
Otro caso real, otro stack: spam SEO y plugin malicioso en el blog de iRepairPhone. Misma forma de trabajar: hechos, archivos, verificación.
Si la puntuación móvil está en naranja y quieres el mismo tipo de diagnóstico en producción, puedo revisar la home, el CSS del tema y las imágenes. Trabajo desde Madrid y en remoto en toda España.
Optimizar velocidad PrestaShop · Soporte técnico PrestaShop · Pedir presupuesto · WhatsApp