Core Web Vitals 2026: Guia Completa de LCP, CLS i INP

Un botó de compra que ningú podia prémer

El director de màrqueting d’una botiga en línia de moda a Barcelona portava tres mesos buscant l’origen d’un problema que ningú sabia explicar: la taxa de conversió en mòbil havia caigut un 22%, però el trànsit, els preus i l’inventari es mantenien estables. El servei d’atenció al client reportava un increment de queixes sobre el lloc web “que no funciona al meu mòbil”, però l’equip de desenvolupament no podia reproduir cap error. El problema era invisible en proves funcionals perquè no era un error en el sentit tradicional. Era un problema de rendiment amb tres símptomes diferents.

Les pàgines de producte trigaven 4,7 segons a mostrar la imatge principal. Els bàners promocionals es carregaven després del contingut i empenyien el botó de “Afegir al cistell” cap avall mentre l’usuari ja estava navegant. Cada toc al selector de talla congelava el navegador durant gairebé 400 mil·lisegons. En termes de Core Web Vitals: LCP de 4,7 segons (el llindar de Google és 2,5), CLS de 0,28 (el llindar és 0,1) i INP de 380 ms (el llindar és 200). La botiga suspenia les tres mètriques, i l’efecte acumulat li costava aproximadament 2.300 euros diaris en vendes perdudes des del mòbil.

Aquesta guia desglossa cada mètrica amb dades actualitzades, explica com mesurar-les correctament, compara benchmarks reals per sector i proposa un full de ruta de 90 dies per portar les teves mètriques al rang que Google considera “bo”. Si el teu lloc web genera ingressos, els Core Web Vitals no són un tema tècnic opcional: són un factor de negoci quantificable.

Com mesurar els teus Core Web Vitals: eines gratuïtes i de pagament

Abans d’optimitzar qualsevol mètrica, cal saber exactament on ets. I aquí existeix una distinció que molts equips ignoren: les dades de laboratori i les dades de camp mesuren coses fonamentalment diferents, i Google només utilitza una de les dues fonts per al rànquing.

Dades de camp vs. dades de laboratori

Les dades de camp (també anomenades RUM, Real User Monitoring) provenen d’usuaris reals que visiten el teu lloc amb Chrome. Google recull aquestes mètriques a través del Chrome User Experience Report (CrUX) i les mostra a PageSpeed Insights, Search Console i BigQuery. Són aquestes dades —no les de laboratori— les que determinen si el teu lloc supera els llindars de Core Web Vitals a efectes de rànquing.

Les dades de laboratori simulen una càrrega en condicions controlades: un dispositiu emulat, una connexió de xarxa predefinida, sense extensions ni caché. Lighthouse, WebPageTest i el mode Lab de PageSpeed Insights generen dades de laboratori. Són eines de diagnòstic essencials per identificar causes específiques, però no representen el que experimenten els teus usuaris reals.

Segons Annie Sullivan, enginyera de l’equip de Chrome Performance, “les dades de camp i les dades de laboratori mesuren coses diferents. Un lloc pot superar totes les auditories de Lighthouse i continuar tenint males mètriques de camp perquè els seus usuaris reals estan en dispositius Android de gamma baixa amb 3G.”

Eines gratuïtes

El Google Search Console ofereix l’informe de Core Web Vitals amb dades de camp agrupades per estat (bo, necessita millora, deficient) i per tipus d’URL. És el punt de partida obligatori perquè mostra exactament com veu Google el teu rendiment.

El PageSpeed Insights combina dades de camp (CrUX) i dades de laboratori (Lighthouse) en una sola interfície. La secció superior mostra les dades de camp amb el veredicte real; la secció inferior detalla les oportunitats de millora amb diagnòstics de laboratori.

El Chrome DevTools Performance Panel permet gravar interaccions en temps real i analitzar el desglossament de cada mètrica fins al nivell de traces individuals. És l’eina més potent per diagnosticar problemes d’INP.

La Web Vitals Extension per a Chrome mostra les mètriques en temps real mentre navegues per qualsevol lloc, superposades a la cantonada de la pantalla.

Eines de pagament

Calibre, SpeedCurve i DebugBear ofereixen monitorització contínua amb alertes, tendències històriques i segmentació per dispositiu, país i tipus de pàgina. Per a llocs amb milers d’URLs, aquestes eines permeten identificar patrons que les eines puntuals no detecten.

CrUX Dashboard (gratuït, basat en Google Data Studio i BigQuery) permet crear panells personalitzats amb dades de camp històriques, segmentades per origen i tipus de connexió. És l’opció més potent sense cost, tot i que requereix coneixements bàsics de SQL.

HTTPArchive publica dades globals de Core Web Vitals que permeten contextualitzar les teves mètriques davant el rendiment general de la web. Segons el seu informe de 2025, només el 42% dels llocs web superen simultàniament els llindars de les tres mètriques Core Web Vitals.

Què són els Core Web Vitals i per què Google els usa com a senyal

Els Core Web Vitals són un conjunt de tres mètriques que quantifiquen aspectes concrets de l’experiència de l’usuari en una pàgina web: velocitat de càrrega visual, estabilitat del disseny durant la càrrega i capacitat de resposta davant interaccions. Google els va introduir el maig de 2020 i els va convertir en senyal de rànquing el juny de 2021 com a part del “page experience update”.

La documentació oficial de Google a web.dev és clara sobre el propòsit: “Web Vitals és una iniciativa de Google per proporcionar una guia unificada dels senyals de qualitat que són essencials per oferir una gran experiència d’usuari a la web.” No es tracta de mètriques arbitràries sinó d’indicadors seleccionats perquè correlacionen directament amb el comportament de l’usuari: abandonament, conversió i satisfacció.

El 2026, les tres mètriques Core Web Vitals són:

• LCP (Largest Contentful Paint): mesura la velocitat de càrrega percebuda. Llindar bo: < 2,5 segons.
• CLS (Cumulative Layout Shift): mesura l’estabilitat visual. Llindar bo: < 0,1.
• INP (Interaction to Next Paint): mesura la capacitat de resposta. Llindar bo: < 200 ms.

Aquestes tres mètriques no operen de forma aïllada. Google avalua l’experiència de pàgina com un conjunt de senyals que inclou els Core Web Vitals juntament amb HTTPS, absència d’intersticials intrusius i compatibilitat mòbil. Però els Core Web Vitals són l’única part d’aquesta equació que requereix mesurament continu amb dades de camp reals.

La pregunta que els equips de màrqueting han de respondre no és “els Core Web Vitals són importants?” sinó “quants diners estem deixant de guanyar per no optimitzar-los?”. Les dades del cas Rakuten ho quantifiquen: un 33% més de conversions i un 53% més d’ingressos per visitant. Aquestes xifres no són excepcionals. Són representatives del que passa quan un lloc passa de “deficient” a “bo” en les tres mètriques.

Per a una visió més àmplia de com els Core Web Vitals s’emmarquen dins l’estratègia tècnica general, consulta la nostra guia sobre velocitat web i SEO.

INP (Interaction to Next Paint): la mètrica que va substituir FID

El març de 2024, Google va reemplaçar FID (First Input Delay) per INP (Interaction to Next Paint) com la mètrica oficial de capacitat de resposta dins els Core Web Vitals. Aquest canvi no va ser cosmètic: va representar una evolució fonamental en com Google avalua la interactivitat d’una pàgina.

Per què Google va descartar FID

FID només mesurava el retard de la primera interacció de l’usuari amb la pàgina. Si l’usuari feia clic en un botó durant la càrrega inicial i el navegador trigava 300 ms a respondre, FID registrava 300 ms. Però si totes les interaccions posteriors —scroll, clics en menús, enviaments de formularis— també eren lentes, FID no les captava. Un lloc podia tenir un FID excel·lent i una experiència d’interactivitat terrible.

INP corregeix aquesta limitació. Mesura la latència de totes les interaccions de l’usuari durant tota la visita i reporta el percentil 98 (tècnicament, la pitjor interacció excloent outliers extrems). Això significa que INP reflecteix l’experiència real d’interactivitat completa, no només el primer contacte.

Llindars i diagnòstic

• Bo: INP < 200 ms
• Necessita millora: INP entre 200 i 500 ms
• Deficient: INP > 500 ms

Segons les dades de HTTPArchive, INP és la mètrica on més llocs fallen. Mentre que aproximadament el 80% dels llocs superen el llindar de LCP i el 75% superen CLS, només el 65% compleixen el llindar d’INP. La raó és estructural: durant anys, els equips de desenvolupament van prioritzar la velocitat de càrrega inicial (optimitzar LCP) i l’estabilitat visual (evitar CLS) sense prestar atenció a la latència de les interaccions posteriors a la càrrega.

Les causes més freqüents d’un INP deficient són: event handlers de JavaScript que executen massa codi al fil principal, reflows del DOM provocats per manipulacions d’estils dins d’event handlers, i scripts de tercers (analytics, A/B testing, widgets de xat) que competeixen pel fil principal durant les interaccions de l’usuari.

Com depurar INP

El Chrome DevTools Performance Panel és l’eina més eficaç. Grava una sessió d’interacció i examina l’API de Long Animation Frame (LoAF) per identificar quins scripts bloquegen el fil principal durant cada interacció. Busca tasques que superin els 50 ms i descompon cadascuna per localitzar el codi responsable.

Una tècnica efectiva és el “yielding”: dividir les tasques llargues de JavaScript en parts més petites utilitzant scheduler.yield() o setTimeout per retornar el control al navegador entre cada fragment. Aquesta pràctica permet que el navegador processi les actualitzacions visuals sense esperar que acabi tota la computació.

LCP (Largest Contentful Paint): què mesura i llindars el 2026

LCP mesura el temps que triga a renderitzar-se l’element de contingut més gran visible al viewport. Aquest element pot ser una imatge, un bloc de text, un vídeo o un element SVG. És la mètrica que millor captura la percepció de l’usuari sobre “quant triga a carregar la pàgina”, perquè reflecteix el moment en què el contingut principal es torna visible.

Llindars

• Bo: LCP < 2,5 segons
• Necessita millora: LCP entre 2,5 i 4 segons
• Deficient: LCP > 4 segons

Google mesura el LCP al percentil 75 de les dades de camp: si el 75% de les càrregues d’una URL tenen un LCP inferior a 2,5 segons, aquesta URL supera el llindar.

Les quatre fases del LCP

Segons la documentació de web.dev, el temps de LCP es descompon en quatre subfases que guien el diagnòstic:

1. Time to First Byte (TTFB): temps des de la sol·licitud HTTP fins que arriba el primer byte de resposta. Depèn del servidor, la CDN i les redireccions.
2. Resource Load Delay: temps entre el TTFB i l’inici de la descàrrega del recurs LCP. Si la imatge LCP no és al HTML inicial (sinó que es descobreix després d’analitzar CSS o executar JavaScript), aquest retard s’amplia.
3. Resource Load Duration: temps de descàrrega del recurs LCP. Depèn de la mida del fitxer i de l’ample de banda.
4. Element Render Delay: temps entre la descàrrega completa del recurs i el seu renderitzat a pantalla. CSS bloquejant i JavaScript que modifica el DOM poden ampliar aquesta fase.

Causes freqüents i solucions

La causa més comuna d’un LCP lent són imatges hero de gran mida sense optimització. Una imatge de 2 MB en format JPEG que podria ser un WebP de 200 KB afegeix segons innecessaris al LCP. Les solucions directes són: utilitzar formats moderns (WebP, AVIF), implementar responsive images amb srcset, precarregar la imatge LCP amb <link rel="preload"> i evitar el lazy loading a la imatge above-the-fold.

La segona causa més freqüent és el CSS render-blocking. Si la teva pàgina carrega 300 KB de CSS abans de renderitzar qualsevol contingut, el LCP es retarda proporcionalment. La solució és inlinear el CSS crític (el necessari per renderitzar el contingut above-the-fold) i diferir la resta amb media="print" o càrrega asíncrona.

Les dades de web.dev confirmen que el TTFB és freqüentment el component més gran del LCP en llocs amb servidors lents: “Si el vostre TTFB és lent, és difícil assolir els objectius de la resta de mètriques.” Utilitzar una CDN amb edge caching i optimitzar les consultes de base de dades del servidor són els dos passos més efectius per reduir el TTFB.

Benchmarks per sector: puntuacions dels líders del mercat

Saber que el llindar de LCP és 2,5 segons és necessari, però no suficient. Les empreses necessiten context competitiu: quines puntuacions aconsegueixen realment els llocs del seu sector? Les dades de HTTPArchive i CrUX permeten respondre aquesta pregunta amb xifres reals.

Comerç electrònic

El sector del comerç electrònic és on els Core Web Vitals tenen l’impacte empresarial més directe i documentat. Les dades de 2025 mostren que les botigues en línia que superen els tres llindars tenen una taxa de conversió un 24% superior a les que no els superen.

Els líders del sector (Amazon, Zalando, ASOS) mantenen un LCP medià inferior a 1,8 segons, un CLS per sota de 0,04 i un INP inferior a 150 ms. Aquests llocs inverteixen en equips dedicats de rendiment amb monitorització en temps real i pressupostos de rendiment (performance budgets) que bloquegen els desplegaments quan una mètrica supera un llindar definit.

Per als comerços electrònics de mida mitjana, el benchmark realista és: LCP < 2,2 segons, CLS < 0,08 i INP < 180 ms. Assolir aquestes xifres requereix optimització d’imatges de producte, gestió de scripts de tercers i server-side rendering o pre-rendering per a les pàgines de categoria.

Mitjans de comunicació i contingut editorial

Els llocs de contingut s’enfronten a un repte particular en CLS: els anuncis dinàmics que es carreguen després del contingut editorial desplacen els elements de la pàgina, generant puntuacions de CLS que freqüentment superen 0,2. Els mitjans amb millor rendiment (The Guardian, Financial Times) han implementat slots d’anunci amb dimensions reservades i lazy loading controlat per minimitzar els layout shifts.

En LCP, els llocs de contingut solen tenir avantatge perquè els seus elements principals són textos, no imatges pesades. El benchmark dels líders és LCP < 1,5 segons per a articles de text.

SaaS i B2B

Els llocs SaaS solen tenir bons Core Web Vitals a les pàgines de màrqueting (landing pages estàtiques) però dolents a les aplicacions web. Atès que Google avalua les pàgines que els usuaris troben a través de la cerca, les landing pages són les que importen per al rànquing. El benchmark del sector és LCP < 2,0 segons i CLS < 0,05.

El cas Rakuten, documentat per web.dev, és el referent més citat del sector tecnològic: un 33% més de conversions i un 53% més d’ingressos per visitant després d’optimitzar els Core Web Vitals. Annie Sullivan de l’equip de Chrome va comentar sobre aquest cas: “És un exemple perfecte de com les mètriques centrades en l’usuari es tradueixen directament en resultats de negoci.”

Serveis professionals i llocs corporatius

És el sector amb més variabilitat. Els llocs corporatius amb CMS empresarials (Adobe Experience Manager, Sitecore) freqüentment tenen LCP > 3 segons per la complexitat del stack tecnològic. Els que millor rendiment aconsegueixen són els que han adoptat arquitectures de generació estàtica (Astro, Next.js) amb CDN edge: LCP < 1,2 segons és assolible per a llocs institucionals amb poc dinamisme de contingut.

CLS (Cumulative Layout Shift): què mesura i causes freqüents

CLS mesura la suma de tots els desplaçaments inesperats d’elements visibles durant la vida de la pàgina. Cada vegada que un element del DOM canvia de posició sense que l’usuari hagi interactuat (per exemple, una imatge que es carrega i empeny el text cap avall, o un bàner que apareix des de dalt), es genera un layout shift que contribueix a la puntuació CLS.

Llindars

• Bo: CLS < 0,1
• Necessita millora: CLS entre 0,1 i 0,25
• Deficient: CLS > 0,25

Com es calcula

El CLS no és una simple suma de tots els shifts. Google utilitza un sistema de “finestres de sessió” que agrupa els shifts que passen en ràfegues ràpides (menys d’1 segon entre cadascun, amb un màxim de 5 segons per finestra). El CLS final és la puntuació màxima de totes les finestres de sessió. Aquest càlcul, actualitzat el 2021, corregeix una limitació del mètode original que penalitzava injustament les pàgines on l’usuari passava molt de temps (aplicacions web, feeds infinits).

Cada shift individual es calcula com: fracció d’impacte (percentatge del viewport afectat) x fracció de distància (distància del desplaçament com a percentatge del viewport). Una imatge que ocupa el 50% del viewport i es desplaça un 20% genera un shift de 0,1.

Les cinc causes més freqüents de CLS alt

Les imatges i vídeos sense dimensions declarades provoquen el shift més freqüent: si una imatge no té atributs width i height a l’HTML, el navegador no pot reservar espai abans de descarregar-la. Quan la imatge es carrega, empeny tot el contingut inferior. La solució és declarar sempre les dimensions o utilitzar la propietat CSS aspect-ratio.

Els anuncis dinàmics i embeds gestionen el segon factor de CLS alt. Els slots d’anunci de Google AdSense, ad managers o xarxes programàtiques freqüentment canvien de mida després de la càrrega inicial. Reservar l’espai del slot amb un contenidor d’alçada fixa o la propietat min-height redueix l’impacte.

Les fonts web que provoquen FOUT/FOIT ocasionen el tercer cas. Quan una font web es carrega després del text, el navegador pot canviar de la font fallback a la font web, provocant un shift visible. Combinar font-display: swap amb size-adjust a la font fallback minimitza el canvi de mida.

El contingut injectat dinàmicament (bàners de cookies, barres de notificació, widgets de xat) inserit al DOM després de la càrrega inicial pot desplaçar el contingut existent. La solució és reservar espai o usar posicionament fix/sticky per a aquests elements.

Les imatges lazy-loaded above the fold tanquen la llista. Si s’aplica lazy loading a imatges que estan al viewport inicial, el navegador primer renderitza la pàgina sense elles i després les insereix, causant un shift. Les imatges above-the-fold mai han de tenir loading="lazy".

La millora de CLS és una de les optimitzacions amb major retorn immediat. Segons dades citades a l’estudi de cas de web.dev, una reducció de CLS de 0,25 a 0,05 pot elevar les conversions en un 15% perquè els usuaris deixen de fer clic accidentalment en elements que no eren el seu objectiu.

Full de ruta per millorar els teus Core Web Vitals en 90 dies

Millorar els Core Web Vitals no és un projecte d’un dia. Requereix un enfocament seqüencial que prioritzi les mètriques segons el seu impacte en negoci i la seva complexitat de resolució. Aquest full de ruta està dissenyat per a equips amb recursos limitats que necessiten resultats mesurables en un trimestre.

Fase 1: Diagnòstic i Quick Wins (Setmanes 1-2)

L’objectiu d’aquesta fase és establir la línia base i resoldre els problemes que se solucionen sense canvis arquitectònics.

1. Executa PageSpeed Insights a les 20 URLs amb més trànsit orgànic. Documenta LCP, CLS i INP de camp per a cadascuna.
2. Creua amb Google Search Console > Core Web Vitals per identificar grups d’URLs amb patrons comuns.
3. Implementa les optimitzacions d’imatge immediates: conversió a WebP/AVIF, dimensions explícites a l’HTML, preload de la imatge LCP, eliminació del lazy loading above-the-fold.
4. Afegeix font-display: swap i size-adjust a totes les fonts web.
5. Reserva espai per a slots d’anunci i embeds amb min-height.

Resultat esperat: millora de LCP en un 20-30% i de CLS en un 40-60% només amb aquests canvis.

Fase 2: Optimització de LCP i CLS (Setmanes 3-6)

L’objectiu d’aquesta fase és portar LCP i CLS al rang “bo” en el 90% de les URLs.

1. Audita el CSS render-blocking: inlinea el CSS crític i difereix la resta. Eines com Critical (d’Addy Osmani) automatitzen l’extracció.
2. Implementa una CDN si no en tens. Una CDN edge redueix el TTFB entre un 40% i un 70% depenent de la distància geogràfica al servidor origen.
3. Optimitza la cadena de descobriment del recurs LCP: assegura que la imatge o recurs LCP està referenciat directament a l’HTML, no descobert després d’analitzar CSS o executar JavaScript.
4. Revisa tots els scripts de tercers: analytics, A/B testing, widgets de xat, píxels de xarxes socials. Difereix els que no siguin crítics amb async o defer. Considera carregar els no essencials després de la interacció de l’usuari.
5. Implementa performance budgets: defineix llindars màxims de mida per a JavaScript (< 200 KB comprimit), CSS (< 50 KB crític) i imatges per pàgina.

Fase 3: Optimització d’INP (Setmanes 7-10)

L’objectiu d’aquesta fase és portar INP al rang “bo” identificant i resolent les interaccions lentes.

1. Utilitza Chrome DevTools amb l’API de Long Animation Frames (LoAF) per identificar les interaccions que superen 200 ms.
2. Implementa code splitting per a JavaScript: carrega només el codi necessari per a cada pàgina i difereix la resta.
3. Aplica yielding en event handlers llargs: divideix les tasques que superen 50 ms en chunks més petits utilitzant scheduler.yield().
4. Mou les computacions pesades fora del fil principal utilitzant Web Workers quan sigui possible.
5. Audita els scripts de tercers que bloquegen el fil principal durant les interaccions. Les eines d’A/B testing i els tag managers són els infractors més freqüents.

Fase 4: Monitorització i Manteniment (Setmanes 11-12)

L’objectiu d’aquesta fase és establir un sistema d’alerta que previngui regressions.

1. Configura alertes automàtiques (DebugBear, SpeedCurve o CrUX Dashboard) per detectar regressions en qualsevol de les tres mètriques.
2. Integra Lighthouse CI al teu pipeline de desplegament per bloquejar releases que empitjorin els Core Web Vitals.
3. Programa una revisió mensual de l’informe de Core Web Vitals a Search Console per detectar tendències.
4. Documenta les decisions de rendiment en un “performance budget” que l’equip de desenvolupament consulti abans d’afegir nous scripts o funcionalitats.

Per a una implementació específica de Core Web Vitals en botigues en línia, consulta la nostra guia sobre Core Web Vitals en e-commerce. Si el teu lloc és a WordPress, la guia de Core Web Vitals a WordPress cobreix les particularitats d’aquest ecosistema. I si necessites suport professional, el nostre servei d’optimització de Core Web Vitals inclou auditoria completa, implementació i monitorització contínua.

Conclusió: Core Web Vitals com a llenguatge entre negoci i tecnologia

Els Core Web Vitals van resoldre un problema que la indústria del SEO arrossegava des de feia més d’una dècada: la manca de mètriques objectives, estandarditzades i públiques per mesurar l’experiència de l’usuari a la web. Abans de 2020, cada eina mesurava la “velocitat” d’una forma diferent, els equips de màrqueting i desenvolupament parlaven idiomes distints, i els directius no tenien manera de saber si el seu lloc era ràpid o lent sense dependre d’opinions subjectives.

El 2026, LCP, CLS i INP són l’estàndard de facto. Google els utilitza per al rànquing. Els equips de desenvolupament els utilitzen per establir performance budgets. Els directius els utilitzen per justificar inversions en infraestructura. I les dades mostren consistentment que millorar-los té un impacte directe en conversions, ingressos i satisfacció de l’usuari.

L’error més freqüent és tractar els Core Web Vitals com un projecte puntual: “hem passat l’auditoria, ho donem per fet”. La realitat és que cada nou script de tercers, cada canvi de disseny, cada actualització de contingut pot introduir una regressió. Les empreses que mantenen les seves mètriques al rang “bo” de forma sostinguda són les que han integrat la monitorització de rendiment al seu flux de treball diari, no les que fan una optimització massiva un cop l’any.

Les dades són clares. Les eines estan disponibles. Els llindars són públics i estables. L’única variable és si el teu equip prioritza l’experiència de l’usuari com un factor de negoci o la relega a una tasca tècnica secundària. Els Core Web Vitals converteixen aquesta decisió en quelcom mesurable.