Los Core Web Vitals (CWV) se convirtieron en 2024 en un factor de posicionamiento directo para Google, y su peso en el ranking de páginas e-commerce sigue aumentando en 2026. En PrestaShop 8, optimizar los CWV es a la vez un trabajo SEO y de calidad de experiencia: un LCP que pasa de 4,2 s a 1,8 s implica mecánicamente un +20-40% de tasa de conversión en móvil. Sin embargo, la optimización de los CWV sigue malinterpretada. La mayoría de los comerciantes lanzan un Lighthouse, ven un resultado en rojo, instalan un módulo de caché genérico y comprueban que la puntuación apenas se mueve, porque las palancas reales no están en el caché sino en detalles técnicos precisos.
Esta checklist detalla las optimizaciones de CWV que realmente producen resultados en PrestaShop 8 en 2026, con código PHP y SQL real adaptado a la arquitectura PrestaShop, no consejos genéricos copiados de la documentación de Google.
Los 3 Core Web Vitals 2026 y sus umbrales
LCP (Largest Contentful Paint): tiempo desde el inicio de carga hasta el renderizado del elemento visible más grande. Umbral bueno: bajo 2,5 s; mejorable: 2,5-4 s; malo: por encima de 4 s.
INP (Interaction to Next Paint): sustituyó al FID en marzo de 2024. Mide la latencia entre una interacción del usuario y el próximo renderizado visible. Umbral bueno: bajo 200 ms; mejorable: 200-500 ms; malo: por encima de 500 ms.
CLS (Cumulative Layout Shift): mide los desplazamientos visuales inesperados durante la carga. Umbral bueno: bajo 0,1; mejorable: 0,1-0,25; malo: por encima de 0,25.
Para que una página alcance «Bueno» en Search Console, las tres métricas deben estar en verde en el percentil 75 de las cargas reales. Google calcula la puntuación sobre usuarios reales (Field Data vía Chrome User Experience Report). Configura Real User Monitoring (RUM) con la library web-vitals de Google que se integra en pocas líneas de JS y envía las medidas a GA4.
LCP: las optimizaciones que realmente funcionan
1. Identificar con precisión el elemento LCP
La extensión Chrome Web Vitals Extension resalta el elemento LCP en tiempo real en cualquier página. En una ficha de producto de PrestaShop, el LCP es casi siempre la imagen principal del producto.
2. Precarga de la imagen LCP
Añadir un <link rel="preload"> en el head para la imagen principal del producto gana 200-500 ms en el LCP, porque el navegador empieza a descargar la imagen antes de parsear el HTML que la contiene. Implementación en la plantilla Twig de la ficha de producto:
{if isset($product.cover.bySize.large_default.url)}
<link rel="preload" as="image"
href="{$product.cover.bySize.large_default.url}"
imagesrcset="..." imagesizes="..." fetchpriority="high">
{/if}3. Conversión WebP / AVIF con dimensiones correctas
Servir imágenes en WebP reduce el peso un 25-35% respecto al JPEG a igual calidad visual. Verifica que las dimensiones servidas coincidan con las mostradas: servir una imagen de 2000×2000 mostrada en 400×400 desperdicia ancho de banda. Usa srcset para ofrecer varias tallas según el viewport.
4. TTFB y consultas SQL del servidor
Activa el profiling de PrestaShop (Configuración > Rendimiento > activar modo debug + profiler) y revisa la pestaña Base de datos. Si ves la misma consulta ejecutada 50 veces por carga de página de producto, es probablemente una consulta N+1 en un módulo mal codificado. Ese módulo debe parchearse o desactivarse.
INP: el asesino moderno del rendimiento (y el menos comprendido)
El INP reemplazó al FID en marzo de 2024 y es ahora la métrica más difícil de optimizar en PrestaShop. FID solo medía la primera interacción; INP mide todas y conserva el peor percentil 98. Un solo clic lento en un filtro de categoría que bloquea 500 ms pesa más que 49 interacciones rápidas.
1. Identificar las interacciones lentas
La extensión Chrome Web Vitals Extension muestra el INP en tiempo real. Haz clic en todos los elementos de tu tienda (filtros, añadir al carrito, pop-ups, acordeones FAQ, swiper de producto) y observa qué interacciones superan los 200 ms.
2. Long tasks y ceder el main thread
Una interacción lenta es casi siempre causada por una «long task» JavaScript (función que bloquea el main thread más de 50 ms). Solución moderna: fragmentar las long tasks con scheduler.yield() o setTimeout(fn, 0):
async function processProducts(products) {
for (let i = 0; i < products.length; i += 50) {
const chunk = products.slice(i, i + 50);
chunk.forEach(processProduct);
if ('scheduler' in window && 'yield' in scheduler) {
await scheduler.yield();
} else {
await new Promise(r => setTimeout(r, 0));
}
}
}3. Debounce y throttle en los inputs
En filtros de búsqueda, selects de variantes, inputs de cantidad: no lances AJAX en cada pulsación. Aplica debounce de 200-300 ms antes de enviar la petición.
4. Code splitting JS y carga diferida
Muchos módulos de PrestaShop cargan su JS en todas las páginas cuando solo se usan en algunas. Audita tus controladores y usa $this->context->controller->registerJavascript() con el controlador correcto. Para funcionalidades realmente pesadas, carga el JS de forma lazy mediante import() dinámico en el momento de la primera interacción.
CLS: la estabilidad visual
1. Reservar espacio para las imágenes. Toda imagen en el HTML debe tener atributos width y height explícitos. Todo <img src="..." /> sin estas dimensiones es sospechoso.
2. Fuentes web y FOIT/FOUT. font-display: optional para fuentes secundarias, y font-display: swap con un fallback métrico-compatible usando size-adjust CSS.
3. Banners y pop-ups diferidos. Los banners de cookies, pop-ups de newsletter y top bars que aparecen 1-3 segundos después de la carga son fuentes frecuentes de CLS. Reserva el espacio en CSS desde el inicio, o hazlos aparecer como overlays (posición fixed/absolute).
4. Iframes externos y embeds. Reserva sistemáticamente su espacio con un wrapper en aspect-ratio: 16/9.
Optimizaciones SQL y de base de datos específicas de PrestaShop
Cuando el profiler de PrestaShop revela una consulta lenta (más de 50 ms), pásala por MySQL con EXPLAIN. Si ves type: ALL con muchas filas escaneadas, probablemente falta un índice. Las consultas N+1 son el patrón más destructivo: en lugar de hacer una consulta por producto en el hook displayProductMiniature, el módulo debe recoger todos los IDs de productos vía actionProductListBefore y hacer una sola consulta WHERE id_product IN (1, 2, 3, ...).
La trampa de los módulos de terceros
En las tiendas que auditamos, el 60-80% de los problemas de CWV vienen de módulos de terceros mal codificados. Auditoría a realizar regularmente: desactiva todos los módulos de terceros y lanza Lighthouse → esa es tu base «PrestaShop puro». Reactívalos uno a uno volviendo a ejecutar Lighthouse cada vez. Identifica los módulos que hacen caer la puntuación más de 5 puntos.
Varios módulos de nuestro catálogo fueron desarrollados con estas restricciones en mente, como el módulo DataFirefly SideCart (JS cargado solo en las páginas donde se muestra) y el módulo DataFirefly Cross-Sell — tema tratado en nuestro artículo sobre el cross-sell que contribuye al carrito medio.
Conclusión: un trabajo continuo, no un proyecto puntual
La optimización de los Core Web Vitals en PrestaShop 8 raramente es un trabajo de unos días que se hace una vez y se olvida. El buen reflejo es configurar una monitorización permanente (Search Console + RUM vía web-vitals.js + GA4) y revisar las métricas de forma rutinaria. Para profundizar, consulta nuestras categorías Performance & Core Web Vitals y Tutoriales PrestaShop.