En un test A/B de Vodafone Italia amb dues pagines visualment i funcionalment identiques, millorar el LCP un 31% va ser suficient per generar un 8% mes de vendes, segons el cas d'estudi oficial de web.dev. No es un detall tecnic per al vostre equip de desenvolupament: es una variable directa d'ingressos. Els Core Web Vitals mesuren amb precisio aquella experiencia que decideix, en els primers segons, si un visitant compra, contacta o se'n va a la competencia.
Si gestioneu el lloc web d'una empresa B2B, aixo us concerneix tant com a un e-commerce. Un formulari de contacte que triga a respondre, un hero que salta mentre carrega o una pagina lenta en mobil son fuites silencioses de conversio. En aquesta guia veureu que son exactament els Core Web Vitals, quins llindars exigeix Google el 2026, com mesurar-los amb dades fiables i com optimitzar cada metrica pas a pas.
Que son els Core Web Vitals i per que importen per al SEO el 2026
Els Core Web Vitals son un subconjunt de les metriques d'experiencia de pagina que Google considera essencials per avaluar l'experiencia real de l'usuari en qualsevol lloc web. No mesuren si una pagina "es veu bonica", sino tres dimensions mesurables del seu comportament: quant triga a mostrar el contingut principal, com respon a la interaccio de l'usuari i quant es mou el disseny mentre carrega.
El 2026 son tres metriques:
- LCP (Largest Contentful Paint) — velocitat de carrega de l'element mes gran visible.
- INP (Interaction to Next Paint) — capacitat de resposta a les interaccions.
- CLS (Cumulative Layout Shift) — estabilitat visual del disseny.
Importen per al SEO perque formen part dels senyals d'experiencia de pagina que Google avalua. Pero importen encara mes per al negoci. Google ha documentat resultats com els d'iCook, que va augmentar un 10% els seus ingressos publicitaris en millorar el CLS un 15%; Tokopedia, amb un 23% mes de duracio mitjana de sessio despres de reduir el LCP un 55%; o Nykaa, que va aconseguir un 28% mes de trafic organic en millorar el LCP un 40%. Son xifres del propi repositori de casos d'estudi de web.dev, no estimacions d'agencia.
La conclusio practica: optimitzar els Core Web Vitals no es "feina de fontaneria" que nomes agrada a Google. Es un palanca de conversio, retencio i, en ultima instancia, de pipeline comercial.
LCP, INP i CLS: llindars recomanats per Google
Google no utilitza una escala continua: classifica cada metrica en tres categories —"bona", "necessita millorar" i "deficient"— a partir de llindars fixos. Per aprovar, l'objectiu es sempre la categoria "bona". Aquests son els valors oficials segons la documentacio de web.dev sobre definicio de llindars dels Core Web Vitals:
| Metrica | Que mesura | Bo | Necessita millorar | Deficient |
|---|---|---|---|---|
| LCP | Velocitat de carrega del contingut principal | <= 2,5 s | 2,5 s – 4,0 s | > 4,0 s |
| INP | Capacitat de resposta a interaccions | <= 200 ms | 200 ms – 500 ms | > 500 ms |
| CLS | Estabilitat visual (moviment del disseny) | <= 0,1 | 0,1 – 0,25 | > 0,25 |
Hi ha un matis que canvia completament com interpretar els vostres informes: Google avalua aquests llindars en el percentil 75 de les visites reals. Es a dir, perque una URL aprovi una metrica, almenys el 75% de les pagines vistes ha d'assolir el llindar "bo". Aixo significa que no n'hi ha prou que la pagina sigui rapida al vostre portatil d'alta gamma amb fibra: tambe ho ha de ser per al quart usuari mes lent de cada quatre, normalment alguna persona amb un mobil modest i una connexio mobil irregular.
Per aixo una pagina pot "semblar rapida" quan la proveu vosaltres i, malgrat aixo, suspendre els Core Web Vitals. El percentil 75 obliga a dissenyar pensant en el pitjor escenari raonable, no en el millor.
Per que INP va substituir FID el marc de 2024
Durant anys, la metrica de resposta va ser FID (First Input Delay), que nomes mesurava el retard de la primera interaccio de l'usuari i, a mes, unicament la demora fins que el navegador comencava a processar-la. Era una metrica generosa: la majoria de llocs la aprovaven amb facilitat, cosa que la feia poc util per distingir experiencies realment fluides de les que no ho eren.
INP (Interaction to Next Paint) va substituir oficialment FID com a Core Web Vital de resposta el 12 de marc de 2024, despres d'anunciar-se el 31 de gener del mateix any, segons el blog de web.dev. La diferencia es substancial:
- FID mesurava nomes la primera interaccio; INP observa totes les interaccions de la sessio i reporta (aproximadament) la pitjor.
- FID mesurava nomes el retard d'entrada; INP mesura el cicle complet, fins que el fotograma seguent (next paint) reflecteix visualment la resposta.
A la practica, INP es molt mes exigent i molt mes representatiu de com percep l'usuari l'agilitat del vostre lloc. Una pagina que obria menus amb lentitud, validava formularis amb retard o reaccionava tard als clics —coses invisibles per a FID— ara queda exposada. Per a llocs B2B amb formularis llargs, filtres de producte o configuradors, aquest canvi va ser especialment rellevant.
Com mesurar els vostres Core Web Vitals: PageSpeed Insights, CrUX i Search Console
Aqui esta l'error mes comu i mes car: confondre dades de laboratori amb dades de camp. No son el mateix i nomes unes d'elles compten per al ranking.
Dades de camp vs. dades de laboratori
- Dades de camp (field data): mesuraments d'usuaris reals que visiten el vostre lloc, recollides a traves del Chrome User Experience Report (CrUX). Es una mitjana mobil de 28 dies.
- Dades de laboratori (lab data): una simulacio controlada en un entorn fix, generada per Lighthouse.
Segons la documentacio de web.dev sobre per que difereixen les dades de laboratori i de camp, per al ranking Google utilitza exclusivament les dades de camp de CrUX, no les de laboratori de Lighthouse. Aquestes ultimes serveixen per al diagnostic: us diuen per que alguna cosa va malament, pero no son la nota que compta. Per aixo es perfectament possible obtenir un 100 a Lighthouse i, malgrat tot, suspendre els Core Web Vitals a CrUX si els vostres usuaris reals tenen una experiencia pitjor que la de l'entorn simulat.
Quina eina fer servir per a que
| Eina | Tipus de dada | Granularitat | Millor us |
|---|---|---|---|
| PageSpeed Insights | Camp (CrUX) + laboratori (Lighthouse) | URL individual; CrUX actualitzat diariament | Diagnostic d'una pagina concreta |
| Google Search Console | Nomes camp (CrUX) | Agregat per grups d'URL | Visio de salut del lloc i URLs problematiques |
| Lighthouse / DevTools | Nomes laboratori | URL individual, execucio puntual | Depurar i provar millores abans de desplegar |
Segons la documentacio de Google for Developers sobre PageSpeed Insights, l'eina mostra tant dades de camp de CrUX (actualitzades diariament a nivell d'URL) com dades de laboratori de Lighthouse. Google Search Console, en canvi, reporta exclusivament dades de camp de CrUX agregades per grups d'URL, cosa que la converteix en el tauler ideal per detectar a escala quines plantilles o seccions del vostre lloc fallen.
El flux de treball recomanat:
- Search Console per identificar quins grups d'URL suspenen.
- PageSpeed Insights per diagnosticar per que falla una URL representativa.
- Lighthouse / DevTools per iterar les correccions en local.
- Desplegar i esperar que la mitjana mobil de 28 dies de CrUX reculli la millora.
Aquest ultim punt es clau: com que CrUX es una mitjana de 28 dies, una correccio no es reflecteix a l'instant. Cal tenir paciencia i no revertir canvis bons per impaciencia.
Com optimitzar cada metrica pas a pas
Cada Core Web Vital te causes diferents i, per tant, solucions diferents. Aquesta es una checklist prioritzada per impacte tipic.
Optimitzar el LCP (<= 2,5 s)
El LCP sol estar limitat pel temps que triga a carregar i renderitzar-se l'element principal (normalment una imatge hero, un bloc de text gran o un video).
- Serviu la imatge LCP amb prioritat (
fetchpriority="high") i eviteu el lazy-loading en aquest element concret. - Optimitzeu el format d'imatge (AVIF o WebP) i dimensioneu correctament per a cada breakpoint.
- Precarregueu els recursos critics (fonts, imatge hero) i elimineu recursos que bloquegin el renderitzat.
- Reduiu el temps de resposta del servidor (TTFB) amb cache, CDN i rendering eficient.
- Minimitzeu el CSS i el JavaScript critics que retarden la primera pintura.
Optimitzar l'INP (<= 200 ms)
L'INP quasi sempre es trenca per JavaScript que bloqueja el fil principal quan l'usuari interactua.
- Dividiu les tasques llargues (long tasks) en fragments mes petits per no bloquejar el fil.
- Ajorneu o elimineu JavaScript de tercers no essencial (xats, widgets, tags de marketing pesants).
- Feu servir
content-visibilityi renderitzat diferit per al contingut fora de pantalla. - Eviteu re-renders innecessaris en frameworks com React optimitzant l'estat i la memoitzacio.
- Doneu retroalimentacio visual immediata a la interaccio encara que el processament continuï en segon pla.
Optimitzar el CLS (<= 0,1)
El CLS es el mes "barat" d'arreglar i el que mes molesta l'usuari: elements que salten just quan esta a punt de clicar.
- Reserveu espai per a imatges i videos amb atributs
widthiheightoaspect-ratio. - Reserveu lloc per a anuncis i embeds abans que carreguin.
- Precarregueu fonts i feu servir
font-display: optionaloswapper evitar reflows de text. - Mai inseriu contingut per damunt de l'existent excepte com a resposta directa a una accio de l'usuari.
- Animeu amb
transform, no amb propietats que provoquin recalcul del layout.
Aquest tipus de feina —mesurament amb dades de camp, pressupostos de rendiment i correccions prioritzades— es exactament el que abordem en un projecte de SEO tecnic ben governat, on el rendiment deixa de ser una incidencia puntual per convertir-se en un estandard de qualitat continua. I quan el problema esta a la base del codi, ho resolem a la capa de desenvolupament web, intervenint en l'arquitectura del front-end, el rendering i el lliurament de recursos.
Els Core Web Vitals influeixen realment en el posicionament?
Es la pregunta del milio, i la resposta honesta te dues parts.
Si, son un senyal de ranking, pero no el mes important. Segons la documentacio de Google Search Central sobre els Core Web Vitals, Google confirma que l'experiencia de pagina —inclosos els Core Web Vitals— es un dels molts senyals que el seu sistema valora. En la mateixa font, Google recorda de manera explicita que un gran contingut segueix sent prioritari per sobre de l'experiencia de pagina.
Com traduir aixo en una estrategia realista:
Els Core Web Vitals no posicionaran contingut mediocre per sobre de contingut excel·lent. Pero quan dues pagines competeixen amb contingut de qualitat comparable, l'experiencia de pagina pot ser el factor que inclini la balanca —i, sobretot, el que determini si el visitant que arriba es queda i converteix.
Per aixo el plantejament correcte no es perseguir un 100 a Lighthouse com a fi en si mateix, sino:
- Assegurar primer un contingut valuos que respongui a la intencio de cerca.
- Aprovar els Core Web Vitals en el percentil 75 d'usuaris reals com a estandard de qualitat no negociable.
- Tractar el rendiment com una variable de negoci, no nomes de SEO, pel seu impacte demostrat en conversio i retencio.
El risc mes gran no es quedar-se a unes decimes del llindar: es ignorar completament les dades de camp i descobrir, mes rere mes, per que els usuaris abandonen sense que les dades de laboratori expliquin res.
Voleu saber on perd rendiment el vostre lloc i quant us esta costant en conversio? A Technova Partners auditem els vostres Core Web Vitals amb dades de camp reals, prioritzem les correccions per impacte i les implementem fins a aprovar en el percentil 75. Parleu amb el nostre equip i convertiu el rendiment web en un avantatge mesurable davant la vostra competencia.
