Cada 100 mil·lisegons de retard et costen vendes
Hi ha un número que hauria d’estar a la paret de l’oficina de tot responsable d’ecommerce: 0,1 segons. Segons l’estudi conjunt de Google i Deloitte publicat com “Milliseconds Make Millions”, cada 0,1 segons de millora en la velocitat de càrrega d’un lloc retail augmenta les conversions un 8%. En travel, l’impacte puja al 10%. No són projeccions teòriques: són dades observades en llocs amb milions de visitants mensuals.
Tradueix aquest número a la teva botiga en línia. Si factures 50.000 euros mensuals i el teu LCP passa de 4,2 segons a 2,4 segons —una millora d’1,8 segons—, l’increment potencial en conversions és de l’ordre del 15-25%. Són entre 7.500 i 12.500 euros mensuals addicionals amb el mateix trànsit, el mateix catàleg i el mateix pressupost publicitari. L’única diferència és que els usuaris completen la compra en lloc d’abandonar per frustració.
Els Core Web Vitals en ecommerce tenen una particularitat que els diferencia de qualsevol altre tipus de lloc web: l’impacte de cada mètrica es multiplica perquè el recorregut de l’usuari implica múltiples interaccions amb la pàgina. Un usuari d’un blog llegeix un article i marxa. Un comprador en línia navega categories, filtra productes, amplia imatges, selecciona talles, afegeix a la cistella, introdueix dades d’enviament, aplica cupons i confirma el pagament. Cadascun d’aquests passos és una oportunitat perquè un LCP lent, un CLS inesperat o un INP deficient provoquin l’abandonament.
Per què els Core Web Vitals importen més en ecommerce
L’ecommerce té una relació més directa entre rendiment web i resultats de negoci que qualsevol altre sector. En un blog, un LCP lent pot costar una lectura. En un mitjà de comunicació, pot costar un clic. En una botiga en línia, costa diners reals mesurables a l’informe de vendes del dia.
Les dades d’HTTPArchive de 2025 revelen que només el 39% dels llocs ecommerce aprova els tres Core Web Vitals simultàniament, tres punts per sota de la mitjana global del 42%. La raó és estructural: les botigues en línia carreguen més recursos per pàgina que la majoria de llocs web. Una pàgina de categoria típica mostra entre 20 i 60 imatges de producte, executa JavaScript per a filtres dinàmics, carrega scripts de remarketing i analítica, mostra bàners promocionals animats i connecta amb sistemes de gestió d’inventari en temps real.
Però l’argument més poderós no és tècnic sinó financer. Vodafone va documentar un augment del 8% en vendes en millorar el seu LCP un 31%. Rakuten va incrementar les conversions un 33% i els ingressos per visitant un 53% després d’optimitzar els seus tres Core Web Vitals. NDTV va reduir la seva taxa de rebot un 55% millorant el LCP. Aquests casos no són excepcions aïllades; són representatius d’un patró documentat per Google: la velocitat de càrrega és un factor de conversió directe, independent del disseny, el preu o l’oferta de productes.
Per a les botigues en línia a Catalunya i Espanya, on la competència en cerques transaccionals com “comprar [producte] en línia” és cada vegada més intensa, els Core Web Vitals funcionen com un factor diferenciador. Quan dues botigues competeixen per la mateixa keyword amb autoritat i contingut similars, Google afavoreix la que ofereix una millor experiència d’usuari. I els Core Web Vitals són la mètrica objectiva que Google utilitza per mesurar aquesta experiència.
Els reptes específics de l’ecommerce: imatges, filtres i bàners
Les botigues en línia enfronten problemes de Core Web Vitals que altres tipus de lloc web rarament troben. Aquests reptes estan directament vinculats a les funcionalitats que fan que una botiga en línia sigui una botiga en línia: catàlegs visuals amb desenes d’imatges, sistemes de filtratge interactius, bàners promocionals rotatius i processos de checkout amb múltiples passos.
Imatges de producte a escala
Un catàleg de 5.000 productes amb 4 imatges per producte genera 20.000 imatges que necessiten optimització. Cada pàgina de categoria mostra entre 20 i 60 d’aquestes imatges simultàniament. Si cada imatge pesa 300 KB en lloc de 80 KB, una pàgina de categoria carrega 6 MB només en imatges. El problema s’agreuja perquè les imatges de producte necessiten qualitat suficient perquè l’usuari vegi els detalls: textura del teixit, color exacte, acabat del material. La compressió agressiva que funciona per a imatges decoratives no sempre és acceptable per a fotografies de producte.
Filtres dinàmics
Els filtres de categoria, talla, color, preu i marca són essencials per a l’experiència de compra, però cada interacció amb un filtre dispara una operació de JavaScript que recalcula els resultats, actualitza el DOM i en molts casos fa una petició Ajax al servidor. Si aquella operació triga més de 200 ms a completar-se, l’INP de l’usuari es degrada. Les botigues amb filtres implementats en frameworks JavaScript reactius (React, Vue) sense optimització solen tenir INP de 300 a 500 ms.
Bàners i sliders promocionals
Els bàners de descompte, ofertes flash i sliders de productes destacats són omnipresents a l’ecommerce. El problema amb el CLS és doble: els bàners que es carreguen de forma asíncrona empenyen el contingut cap avall quan apareixen, i els sliders que canvien de slide mouen elements adjacents si no tenen alçada reservada. Un sol bàner d’oferta sense dimensions explícites pot generar un CLS de 0,15 a 0,25, superant per si sol el llindar de 0,1 que Google considera acceptable.
Preus dinàmics i disponibilitat
Les botigues que mostren preus amb descompte calculats en JavaScript o que verifiquen disponibilitat d’estoc en temps real afegeixen dos problemes: el preu que es pinta inicialment pot canviar quan el JavaScript s’executa (CLS), i la verificació d’estoc pot bloquejar el fil principal si no està ben implementada (INP).
Optimització del LCP a pàgines de producte i categoria
El LCP en ecommerce té dos contextos dominants: les pàgines de categoria i les pàgines de producte. Cadascuna té un element LCP diferent i requereix una estratègia d’optimització diferent.
A les pàgines de categoria, l’element LCP sol ser la primera imatge de producte visible o el bàner principal de la categoria. L’optimització segueix quatre principis: servir imatges en WebP o AVIF amb compressió adaptada al tipus d’imatge (lossy per a fotos de producte, lossless per a gràfics amb text), definir width i height a l’HTML perquè el navegador reservi espai, implementar srcset amb almenys tres mides (mòbil, tauleta, escriptori), i no aplicar loading="lazy" a les primeres 4-6 imatges visibles al viewport inicial.
A les pàgines de producte, l’element LCP és gairebé sempre la imatge principal. L’optimització té un matís addicional: la imatge LCP sol estar dins d’un component de galeria JavaScript que pot retardar la seva renderització. La solució és pre-renderitzar la primera imatge com a HTML estàtic fora del component de galeria, amb les dimensions exactes declarades, i deixar que JavaScript prengui el control després per a les funcionalitats interactives (zoom, canvi d’imatge, vista 360).
Un patró tècnic que marca la diferència: el preload de la imatge LCP. Afegir <link rel="preload" as="image" href="producte-hero.webp"> al <head> indica al navegador que comenci a descarregar la imatge LCP abans que el parser HTML arribi a l’element <img>. En proves documentades, aquest patró redueix el LCP entre 0,3 i 0,8 segons a pàgines de producte.
El TTFB també és crític per al LCP en ecommerce. Les plataformes que generen les pàgines dinàmicament (WooCommerce consultant MySQL, PrestaShop processant PHP) tenen un TTFB base de 300-600 ms sense memòria cau. La memòria cau de pàgina completa redueix això a 50-150 ms, però requereix invalidació intel·ligent quan canvien preus, estoc o promocions. Les plataformes SaaS com Shopify gestionen això automàticament amb el seu CDN global.
CLS en ecommerce: sliders, bàners promocionals i preus dinàmics
El CLS (Cumulative Layout Shift) és la mètrica més traidora en ecommerce perquè els canvis de layout que el causen solen ser invisibles per a l’equip de desenvolupament —ocorren durant la càrrega, quan ningú està mirant amb atenció— però són perfectament percebuts pels usuaris, especialment en mòbil on la pantalla és petita i qualsevol desplaçament de contingut desubica l’usuari.
L’slider de productes destacats és un clàssic generador de CLS. El problema ocorre quan es renderitza per JavaScript després que l’HTML inicial ja s’ha pintat: l’espai que ocupa no existia al layout inicial i en aparèixer empeny tot el que està a sota. La solució té dues parts: reservar l’espai exacte de l’slider amb CSS abans que JavaScript l’ompli (usant aspect-ratio o min-height al contenidor), i si l’slider carrega imatges de forma asíncrona, definir width i height a cada imatge.
Les barres d’enviament gratuït, les notificacions de descompte per temps limitat i els avisos d’estoc baix solen injectar-se mitjançant JavaScript després de la càrrega inicial. Cadascun d’aquests elements empeny el contingut cap avall i genera CLS. La solució és reservar l’espai per a aquests bàners a l’HTML inicial (fins i tot si estan buits) o posicionar-los de forma fixa (position: fixed o position: sticky) perquè no afectin el flux del document.
Quan el preu amb descompte es calcula en JavaScript (descomptes per volum, cupons aplicats automàticament, preus de soci), el preu pot canviar visualment després de la càrrega inicial. Si el preu amb descompte ocupa més espai que el preu original (mostra el preu ratllat i el nou preu a sota), el contingut inferior es desplaça. La solució és renderitzar ambdós preus al servidor o reservar espai per al format de preu més llarg.
Les fonts tipogràfiques personalitzades que no estan pre-carregades causen un efecte FOUT (Flash of Unstyled Text) o FOIT (Flash of Invisible Text) que pot generar CLS si la mida del text amb la font del sistema difereix de la mida amb la font personalitzada. Usar font-display: swap combinat amb <link rel="preload" as="font"> per a les fonts crítiques minimitza aquest efecte.
INP a botigues en línia: filtres, cistella i checkout
L’INP (Interaction to Next Paint) mesura la capacitat de resposta de la pàgina davant les interaccions de l’usuari. En ecommerce, on cada interacció té un impacte directe en la conversió, un INP deficient no és només un problema tècnic: és un problema de negoci. Quan un usuari toca “Afegir a la cistella” i la pàgina triga 350 ms a respondre, la incertesa genera desconfiança. “S’ha afegit? He de prémer un altre cop?” Aquella fracció de segon de dubte és una bretxa per la qual s’escapen conversions.
Els filtres de categoria són la interacció més freqüent a pàgines de categoria i una de les principals fonts d’INP deficient. Cada canvi de filtre sol desencadenar una consulta al servidor (si és server-side) o un recàlcul del DOM (si és client-side), una actualització del llistat de productes, un canvi en els comptadors de filtres disponibles, i potencialment un canvi d’URL per a SEO. Si tot això ocorre de forma síncrona al fil principal, l’INP puja a 300-500 ms. La solució és usar requestAnimationFrame o scheduler.yield() per dividir el treball en tasques més petites, i actualitzar primer la resposta visual (feedback immediat que el filtre s’ha aplicat) abans de processar el resultat complet.
Afegir un producte a la cistella dispara una petició Ajax al servidor, una actualització del comptador al header, potencialment una animació del mini-cistella i un recàlcul de preus amb impostos. Si el JavaScript que gestiona la cistella no està optimitzat, l’INP de la interacció “Afegir a la cistella” pot superar els 200 ms. L’optimització inclou respondre visualment de forma immediata (animació del botó, increment del comptador) mentre la petició al servidor es resol en background, i usar requestIdleCallback per a operacions no crítiques com el seguiment d’analítica.
El checkout és la pàgina amb major impacte en conversió i, paradoxalment, sol ser la pitjor optimitzada per a INP. Els camps de formulari amb validació en temps real, els selectors de mètode d’enviament que recalculen preus, els camps de cupó que fan peticions al servidor i els botons de mètode de pagament que carreguen iframes de passarel·les externes contribueixen tots a l’INP. L’estratègia és prioritzar la resposta visual immediata a cada interacció i delegar els càlculs al servidor o a web workers fora del fil principal.
Benchmarks CWV per plataforma: Shopify, WooCommerce, PrestaShop
Les dades d’HTTPArchive i CrUX permeten comparar el rendiment de les principals plataformes ecommerce amb dades reals de camp, no amb proves de laboratori.
El Shopify lidera amb una taxa d’aprovació del 52% en els tres Core Web Vitals simultàniament. El seu avantatge és estructural: infraestructura controlada amb CDN global de Cloudflare integrat, temes que passen revisió de rendiment abans de publicar-se al Theme Store, i un runtime JavaScript optimitzat (Liquid + Alpine.js en lloc de frameworks pesants). Les limitacions: menys control sobre el servidor, dependència d’apps de tercers que poden degradar el rendiment, i restriccions en personalització profunda del checkout.
El WooCommerce té una taxa d’aprovació del 31%, llastrada per la variabilitat inherent a WordPress. Els llocs WooCommerce amb allotjament gestionat, tema lleuger (GeneratePress + WooCommerce, Kadence) i plugins optimitzats poden assolir el 90-95% a PageSpeed. Però la realitat de l’ecosistema és que moltes botigues WooCommerce corren sobre allotjament compartit amb temes multipropòsit i 30+ plugins actius. La plataforma no és el problema; la configuració típica ho és.
El PrestaShop registra una taxa d’aprovació del 28%. Els seus principals reptes tècnics: un frontend amb dependència històrica de jQuery que penalitza l’INP, generació de pàgines PHP sense memòria cau a nivell d’aplicació per defecte, i un ecosistema de mòduls amb control de qualitat variable. PrestaShop 8 va millorar significativament el rendiment base, però moltes botigues segueixen en versions anteriors.
El Magento/Adobe Commerce té la taxa d’aprovació més baixa entre plataformes enterprise (aproximadament 22%), explicada per la seva complexitat arquitectònica: múltiples capes de memòria cau (Varnish, Redis, Full Page Cache), un frontend pesat basat en RequireJS i Knockout.js (a Magento 2 Luma), i un TTFB base de 500-1.000 ms sense la stack de memòria cau completa configurada. El nou frontend Hyva millora substancialment aquests números en substituir tot el frontend per Alpine.js i Tailwind CSS.
La conclusió per a equips avaluant plataformes: la plataforma estableix un terra i un sostre de rendiment. Shopify té el terra més alt (difícil fer-ho molt malament) i un sostre raonablement bo. WooCommerce i PrestaShop tenen un terra més baix (fàcil fer-ho malament) però un sostre potencialment més alt amb configuració experta. L’elecció depèn de si l’equip té capacitat tècnica per optimitzar una plataforma open-source o prefereix la predictibilitat d’una solució SaaS.
ROI de millorar els Core Web Vitals en ecommerce: dades reals
El retorn d’inversió d’optimitzar els Core Web Vitals en ecommerce és l’argument més sòlid per convèncer la direcció que assigni pressupost a rendiment web. No és un projecte tècnic abstracte: és una inversió amb retorn mesurable en setmanes.
Els estudis de cas publicats permeten construir un model de ROI fonamentat. L’estudi de Google i Deloitte estableix que cada 0,1 segons de millora en velocitat de càrrega augmenta les conversions un 8% en retail. Aplicat a una botiga amb 100.000 visites mensuals, una taxa de conversió del 2% i un tiquet mitjà de 60 euros: millorar el LCP en 1 segon (equivalent a 10 increments de 0,1 s) podria incrementar la taxa de conversió fins a un 2,16%. Aquell 0,16% addicional sobre 100.000 visites representa 160 conversions addicionals al mes, o 9.600 euros de facturació extra mensual.
El cost de l’optimització varia segons la plataforma i l’estat actual del lloc. Una auditoria de Core Web Vitals amb pla d’implementació costa entre 1.500 i 5.000 euros segons la complexitat. La implementació de les millores (memòria cau, optimització d’imatges, CSS/JS, allotjament si cal) sol costar entre 3.000 i 15.000 euros en un projecte tancat. Si el retorn mensual és de 5.000-10.000 euros addicionals, la inversió es recupera en 1-3 mesos.
Més enllà del retorn financer directe, la millora de Core Web Vitals en ecommerce genera beneficis compostos: millor posicionament orgànic (més trànsit gratuït a llarg termini), menor taxa de rebot (més usuaris que interactuen amb el catàleg), major engagement (més pàgines vistes per sessió) i millor experiència en campanyes de pagament (els mateixos anuncis generen més conversions quan la landing page és ràpida).
Consulta la nostra guia sobre velocitat web i SEO per aprofundir en la relació entre rendiment web, posicionament orgànic i resultats de negoci.