L’experiència frustrant de fer clic a un botó que es mou
Heu viscut aquesta situació: esteu llegint un article al mòbil, arribeu a un enllaç que voleu seguir, el vostre dit es dirigeix cap a ell, i en l’instant exacte en què aneu a tocar-lo, un bàner publicitari es carrega per sobre i tot el contingut es desplaça cap avall. En lloc de fer clic a l’enllaç, heu premut un anunci que no volíeu veure. O pitjor encara: heu confirmat una compra en lloc de cancel·lar-la perquè el botó es va moure just abans que el vostre dit toqués la pantalla.
Aquesta frustració té un nom tècnic: Cumulative Layout Shift (CLS), una de les tres mètriques de Core Web Vitals que Google utilitza com a senyal de posicionament. El CLS quantifica quant es desplacen inesperadament els elements visibles d’una pàgina durant la seva càrrega i ús. Google estableix que un CLS inferior a 0.1 és bo, entre 0.1 i 0.25 necessita millora, i per sobre de 0.25 és deficient.
El rellevant per al SEO és que el CLS no només afecta l’experiència de l’usuari — cosa que ja seria motiu suficient per corregir-lo — sinó que és un factor de posicionament directe. Segons dades del Web Almanac de HTTPArchive publicades el 2025, el 38% dels llocs web en mòbil tenen un CLS superior a 0.1, cosa que significa que més d’un terç de la web lliura una experiència visual inestable que Google penalitza. I l’impacte en el negoci és mesurable: un retailer europeu va documentar un increment del 15% en conversions després de reduir el seu CLS de 0.25 a 0.05, un canvi que no va alterar el contingut ni el disseny, només l’estabilitat amb la qual es presentava.
Què és el CLS i per què Google el penalitza
El Cumulative Layout Shift és una mètrica que quantifica la suma de totes les puntuacions de layout shift inesperat que ocorren durant tota la vida d’una pàgina. Cada shift individual es calcula multiplicant dos factors: la fracció d’impacte (el percentatge del viewport que ocupen els elements desplaçats) i la fracció de distància (quant s’han mogut aquests elements respecte al viewport).
Un detall tècnic crític: el CLS només compta els shifts inesperats. Si l’usuari fa clic a un botó i el contingut s’expandeix com a resultat directe d’aquesta interacció, aquest moviment no compta com a CLS perquè és esperat per l’usuari. Només els desplaçaments que ocorren sense interacció de l’usuari — durant la càrrega, per injecció de contingut dinàmic, o per redimensionament d’elements — contribueixen a la puntuació.
Google va modificar la forma de calcular el CLS el 2021, passant del total acumulatiu a un model de “finestra de sessió” que agrupa els shifts ocorreguts en intervals de 5 segons, amb un màxim d’1 segon entre shifts. La puntuació final és la finestra amb major acumulació, no la suma total. Aquest canvi va beneficiar les single-page applications (SPAs) i les pàgines amb contingut que es carrega progressivament, ja que un shift tardà no arrossega tota la puntuació.
Google penalitza el CLS alt perquè l’estabilitat visual és un component fonamental de l’experiència de pàgina. Un document publicat per Google Search Central estableix que l’experiència de pàgina inclou els Core Web Vitals com a senyals de posicionament, i el CLS és una de les tres mètriques avaluades. No és el factor més determinant — la rellevància del contingut segueix sent prioritària — però en escenaris competitius, la diferència entre un CLS de 0.05 i un de 0.30 pot ser la diferència entre posicionar a la primera o segona pàgina.
Com mesurar el CLS: eines i què reporten
Mesurar el CLS correctament requereix entendre la diferència entre dades de laboratori i dades de camp, perquè els resultats poden ser significativament diferents.
Les dades de camp (CrUX) del Chrome UX Report recullen mesuraments reals d’usuaris de Chrome que visiten el lloc. Representen l’experiència real i són les que Google utilitza per al posicionament. S’hi accedeix a través de PageSpeed Insights (la secció “Descobriu el que experimenten els usuaris reals”), Google Search Console (informe de Core Web Vitals), i l’API CrUX. Les dades de camp s’actualitzen amb un període acumulatiu de 28 dies.
Les dades de laboratori — Lighthouse, DevTools Performance i WebPageTest — simulen una càrrega en condicions controlades. Són útils per al diagnòstic però tenen una limitació important: només mesuren el CLS durant la càrrega inicial, no durant la interacció de l’usuari. Una pàgina amb un CLS de 0 al laboratori pot tenir un CLS de 0.4 al camp si els anuncis s’injecten després de la càrrega o si una tipografia web causa un reflow tardà.
El Chrome DevTools és l’eina de diagnòstic més precisa. A la pestanya Performance, graveu una càrrega de pàgina i cerqueu les barres vermelles etiquetades com a “Layout Shift” a la secció Experience. Cada barra mostra quins elements es van moure, quants píxels es van desplaçar i la puntuació individual del shift. La vista de Rendering amb l’opció “Layout Shift Regions” activada ressalta visualment les zones que es mouen durant la càrrega.
La Web Vitals Extension de Chrome mostra el CLS en temps real mentre navegueu, actualitzant el valor amb cada shift que es produeix. És la forma més ràpida de verificar el CLS durant la interacció normal amb la pàgina.
El Search Console reporta el CLS a nivell de grup d’URLs, classificant-les com a “Bo”, “Necessita millora” o “Deficient”. És el panell de monitorització més important perquè reflecteix exactament el que Google avalua per al posicionament.
Les causes més freqüents de CLS alt
Les causes de CLS alt es poden agrupar en cinc categories, ordenades per freqüència segons dades del Web Almanac de HTTPArchive 2025:
Imatges i vídeos sense dimensions — 40% dels problemes
Quan una etiqueta <img> no té atributs width i height, el navegador no pot reservar espai per a la imatge abans de descarregar-la. En carregar-se, la imatge empeny tot el contingut que està a sota, generant un layout shift. El mateix problema afecta els elements <video> i <iframe>. La solució és declarar sempre width i height a l’HTML, o usar la propietat CSS aspect-ratio per reservar l’espai proporcionalment.
Contingut injectat dinàmicament — 25% dels problemes
Bàners de cookies, barres de notificació, anuncis que es carreguen després del contingut principal, widgets de xat, i elements de retargeting que s’insereixen al DOM sense espai reservat. Cada inserció empeny el contingut existent, acumulant CLS. La solució és reservar espai amb min-height als contenidors destinats a contingut dinàmic.
Tipografies web que causen FOUT — 15% dels problemes
Quan una tipografia personalitzada tarda a carregar-se i el navegador mostra primer una tipografia de sistema i després la reemplaça, les diferències de mida entre ambdues poden causar reflow del text. La directiva font-display: swap és necessària per evitar text invisible, però pot contribuir al CLS si la tipografia de respaldo té mètriques molt diferents de la definitiva. La solució és usar font-display: optional quan les tipografies no són crítiques, o aplicar size-adjust al @font-face de la tipografia de respaldo.
Elements amb mida dependent del contingut — 12% dels problemes
Components que calculen la seva alçada basant-se en contingut que es carrega asíncronament: carrusels, taules de preus amb dades dinàmiques, formularis amb validació que afegeix missatges d’error. La solució és definir dimensions mínimes que continguin el component en el seu estat més gran.
Animacions CSS que modifiquen propietats de layout — 8% dels problemes
Animacions que usen top, left, width, height o margin en lloc de transform causen reflow i, si afecten la posició d’altres elements, generen CLS. La solució és usar exclusivament transform i opacity per a animacions, ja que aquestes propietats es processen a la GPU sense afectar el layout d’altres elements.
Com corregir CLS causat per imatges sense dimensions
Les imatges sense dimensions són la causa més freqüent de CLS perquè el navegador, sense conèixer la mida de la imatge abans de descarregar-la, assigna a l’element una mida de 0x0 píxels i recalcula el layout quan la imatge finalment es carrega. El shift resultant és proporcional a la mida de la imatge: una imatge hero a pantalla completa pot generar un CLS de 0.5 per si sola.
La solució bàsica és afegir atributs width i height a cada etiqueta <img>. Els navegadors moderns (Chrome 79+, Firefox 71+, Safari 14.1+) utilitzen aquests atributs per calcular l’aspect ratio de l’element abans de descarregar la imatge, reservant l’espai correcte. No cal que els valors coincideixin amb la mida renderitzada; el que importa és que la proporció sigui correcta.
<!-- Correcte: el navegador reserva espai en proporció 16:9 -->
<img src="hero.webp" width="1600" height="900" alt="Descripció">
<!-- També correcte: CSS aspect-ratio -->
<img src="hero.webp" style="aspect-ratio: 16/9; width: 100%;" alt="Descripció">Per a imatges responsives amb srcset, els atributs width i height han de correspondre a les dimensions intrínseques de la imatge més gran del conjunt. El navegador calcularà l’aspect ratio a partir d’aquells valors.
Per a imatges de fons CSS, la tècnica canvia: el contenidor ha de tenir aspect-ratio o un padding-bottom percentual que reprodueixi la proporció de la imatge. Un contenidor per a una imatge 16:9 necessita padding-bottom: 56.25% (9/16 x 100).
Els CMS moderns generen automàticament width i height a les imatges de la biblioteca de mitjans, però les imatges inserides manualment a l’editor, les procedents d’APIs externes o les generades per JavaScript al costat del client solen mancar d’aquests atributs. Auditar l’HTML renderitzat és el pas previ necessari.
La diferència d’impacte és immediata: afegir dimensions a les cinc imatges above the fold d’un blog típic pot reduir el CLS de 0.15 a 0.02 sense cap altre canvi. Per a les imatges below the fold, l’impacte és menor però contribueix a mantenir l’estabilitat durant el desplaçament.
Com corregir CLS causat per anuncis i bàners dinàmics
Els anuncis programàtics són la segona causa més freqüent de CLS i una de les més difícils de resoldre perquè la mida de l’anunci no es coneix fins que la xarxa publicitària el lliura. Un slot definit per a un anunci de 300x250 pot rebre un creatiu de 300x600, duplicant l’alçada i empenyent tot el contingut inferior.
La primera línia de defensa és definir contenidors amb min-height igual a la mida més freqüent de l’anunci. Per a un slot de display estàndard, min-height: 250px. Per a un leaderboard, min-height: 90px. Si l’anunci és més petit que l’espai reservat, queda un marge visual que és preferible al CLS.
Moltes xarxes publicitàries ofereixen l’opció de col·lapsar el contenidor si no es serveix cap anunci. Si el contenidor té min-height i l’anunci no carrega, l’espai buit pot ser visualment indesitjable. La solució és usar un placeholder (un fons gris subtil amb text “Publicitat” o el logotip del mitjà) que es reemplaça per l’anunci quan es carrega.
Els anuncis en posicions sticky, en barres laterals amb posició absoluta, o en overlays no causen CLS perquè no desplacen altres elements del flux del document. Moure els slots de major impacte a aquestes posicions és la solució més radical però també la més eficaç.
Per als anuncis above the fold — els que més CLS causen perquè desplacen contingut visible — la millor pràctica és carregar-los de forma síncrona amb el contingut principal, no de forma diferida. Un anunci que es carrega 2 segons després del contingut principal garanteix un layout shift visible per a l’usuari. Si es carrega simultàniament, l’espai es reserva des de l’inici.
CLS en mòbil vs escriptori: diferències importants
El CLS en dispositius mòbils sol ser significativament pitjor que en escriptori, i les raons són estructurals:
Un layout de tres columnes en escriptori es converteix en una sola columna en mòbil. Els elements que en escriptori tenen dimensions fixes poden expandir-se verticalment en mòbil, empenyent contingut de formes impredictibles. Les imatges responsives que canvien d’aspect ratio entre breakpoints són particularment problemàtiques.
Les tipografies web solen renderitzar-se amb mides diferents en mòbil i escriptori. Si la tipografia de respaldo ocupa més espai vertical que la definitiva en un viewport estret, el reflow és major i el CLS resultant és més alt. En mòbil, on cada píxel d’alçada compta més proporcionalment, un reflow de text de 20px pot representar un shift significatiu.
En connexions 4G amb latència alta, els recursos es carreguen de forma més escalonada que en fibra. Això amplifica el CLS perquè els elements arriben en onades més separades, cadascuna causant el seu propi shift. Una pàgina que en fibra carrega tots els recursos en 500ms i té un sol shift pot tenir tres shifts separats en 4G.
Els bàners de cookies i barres de notificació solen injectar-se després de la càrrega i, en mòbil, poden ocupar el 20–30% de l’alçada del viewport. Si no tenen espai reservat, el shift és proporcionalment enorme.
La recomanació és auditar el CLS per separat en mòbil i escriptori, prioritzant mòbil perquè: (a) Google utilitza el mobile-first indexing, (b) el 73% del trànsit web global prové de dispositius mòbils, i (c) els problemes de CLS són estructuralment pitjors en pantalles petites. Google Search Console separa les dades de Core Web Vitals per tipus de dispositiu, cosa que permet identificar problemes específics de cada plataforma.
La velocitat web i l’estabilitat visual estan relacionades: les optimitzacions de rendiment que redueixen el temps de càrrega també tendeixen a reduir el CLS, perquè els recursos arriben més ràpid i es processen de forma més homogènia. Abordar ambdues mètriques de forma conjunta és més eficient que tractar-les per separat.