Core Web Vitals: Guia Completa per Millorar-los

Què són els Core Web Vitals i per què importen

Els Core Web Vitals són un conjunt de mètriques que Google fa servir per mesurar l’experiència real de l’usuari en una pàgina web. No són mètriques abstractes ni teòriques: reflecteixen com experimenten el teu web les persones reals que el visiten.

Des del 2021, Google els va incloure com a factor de ranking. El 2026, amb la consolidació d’INP (Interaction to Next Paint) com a mètrica oficial des de març del 2024, aquestes tres mètriques són més rellevants que mai per al teu posicionament orgànic.

Les tres mètriques actuals són:

LCP (Largest Contentful Paint): Mesura la velocitat de càrrega percebuda. Quant triga a renderitzar-se l’element més gran visible a la pantalla.
INP (Interaction to Next Paint): Mesura la capacitat de resposta. Quant triga la pàgina a reaccionar visualment a una interacció de l’usuari.
CLS (Cumulative Layout Shift): Mesura l’estabilitat visual. Quants canvis inesperats de disseny ocorren durant la càrrega i l’ús de la pàgina.

Segons dades del Chrome UX Report de finals del 2025, només el 42% dels llocs web compleixen els tres llindars de Core Web Vitals simultàniament. Això significa que més de la meitat dels llocs web estan oferint una experiència subòptima i potencialment perdent posicions per això.

Com mesurar els Core Web Vitals correctament

Abans d’optimitzar, necessites mesurar. I necessites entendre la diferència entre dos tipus de dades:

Dades de camp (Field Data)

Són mesuraments reals d’usuaris que visiten el teu web. Google les recopila a través de Chrome i les agrega al Chrome UX Report (CrUX). Aquestes són les dades que Google fa servir per avaluar el teu web a efectes de ranking.

S’avaluen al percentil 75: la teva puntuació és l’experiència del 75% dels teus usuaris. Si el 75% dels teus visitants tenen un LCP inferior a 2,5 segons, aproves aquesta mètrica.

On veure-les:

Google Search Console > Core Web Vitals: Vista general de totes les teves pàgines agrupades per estat.
PageSpeed Insights: Dades de camp per a URLs individuals (si tenen prou trànsit).
CrUX Dashboard (Looker Studio): Per a anàlisi històrica i tendències.

Dades de laboratori (Lab Data)

Són mesuraments simulats en un entorn controlat. No reflecteixen l’experiència real de l’usuari, però són extremadament útils per diagnosticar problemes i verificar millores abans de desplegar-les.

On obtenir-les:

Lighthouse (integrat a Chrome DevTools).
PageSpeed Insights (secció de laboratori).
WebPageTest (per a anàlisi més profund amb cascada de xarxa).

Important: Un error freqüent és optimitzar només per a les dades de laboratori i donar per fet que les dades de camp milloraran automàticament. No sempre és així. Les dades de camp depenen dels dispositius, connexions i comportaments reals de la teva audiència.

LCP: Largest Contentful Paint

Què és i com funciona

El LCP mesura quant de temps triga a renderitzar-se l’element de contingut més gran visible al viewport (la part visible de la pantalla). Pot ser una imatge, un bloc de text, un vídeo o un element SVG.

Llindars:

Bo: Menys de 2,5 segons.
Necessita millora: Entre 2,5 i 4 segons.
Pobre: Més de 4 segons.

Les 4 causes principals d’un LCP lent

1. Temps de resposta del servidor lent (TTFB)

Si el teu servidor triga més de 600 mil·lisegons a respondre, és pràcticament impossible tenir un bon LCP. Les causes comunes són hosting compartit de baixa qualitat, bases de dades sense optimitzar i absència de caché.

Solucions:

Migra a un hosting de major rendiment o fes servir un CDN com Cloudflare.
Implementa caché a nivell de servidor (Varnish, Redis, caché de pàgina completa).
Optimitza les consultes a la base de dades i activa la caché d’objectes.

2. Bloqueig de renderitzat per CSS i JavaScript

El navegador no pot pintar res fins que ha processat tots els arxius CSS crítics. Si carregues fulls d’estil pesats o JavaScript que bloqueja el renderitzat, el LCP es retarda.

Solucions:

Extreu i inline el CSS crític (above-the-fold) directament a l’HTML.
Carrega els arxius CSS no crítics de forma asíncrona.
Afegeix defer o async als scripts que no són essencials per al renderitzat inicial.
Elimina CSS i JavaScript no utilitzat. En molts llocs, més del 50% del CSS carregat no es fa servir a la pàgina.

3. Càrrega lenta de recursos (imatges, fonts)

Si l’element LCP és una imatge (que és el més habitual), necessites assegurar-te que es carregui com més aviat millor.

Solucions:

Fes servir formats moderns com WebP o AVIF. Poden reduir la mida un 30-50% respecte a JPEG.
Implementa fetchpriority="high" a la imatge LCP per indicar al navegador que la prioritzi.
Fes servir preload per a recursos crítics: <link rel="preload" as="image" href="hero.webp">.
No apliquis loading="lazy" a la imatge LCP. El lazy loading és per a imatges below-the-fold.
Defineix sempre width i height a les imatges perquè el navegador reservi l’espai.

4. Renderitzat del costat del client

Les aplicacions SPA (Single Page Applications) que depenen de JavaScript per renderitzar el contingut inicial solen tenir un LCP pobre perquè el navegador necessita descarregar, parsejar i executar JavaScript abans de mostrar res.

Solucions:

Fes servir SSR (Server-Side Rendering) o SSG (Static Site Generation) per generar l’HTML al servidor.
Implementa hidratació parcial per reduir la quantitat de JavaScript necessari a la càrrega inicial.
Frameworks com Astro, Next.js o Nuxt ofereixen aquestes capacitats de sèrie.

INP: Interaction to Next Paint

Què és i com funciona

INP (Interaction to Next Paint) va reemplaçar oficialment FID (First Input Delay) al març del 2024. Mentre FID només mesurava la primera interacció, INP avalua totes les interaccions de l’usuari durant la sessió completa i reporta la latència més alta (amb ajustaments estadístics per evitar outliers).

Una “interacció” inclou clics, tocs a pantalla i pulsacions de teclat. El scroll no es considera una interacció per a INP.

Llindars:

Bo: Menys de 200 mil·lisegons.
Necessita millora: Entre 200 i 500 mil·lisegons.
Pobre: Més de 500 mil·lisegons.

Per què INP és més exigent que FID

FID només mesurava el retard abans que el navegador comencés a processar la interacció. INP mesura el cicle complet: des que l’usuari interactua fins que el navegador pinta l’actualització visual a pantalla. Això inclou:

Input delay: El temps que la interacció espera en cua perquè el fil principal està ocupat.
Processing time: El temps que triguen els event handlers a executar-se.
Presentation delay: El temps que triga el navegador a calcular el layout i pintar l’actualització visual.

Segons dades de web.dev, quan es va produir el canvi de FID a INP, molts llocs que aprovaven amb FID van suspendre amb INP. La raó és que INP és una mètrica molt més representativa de l’experiència real de l’usuari.

Com millorar el INP

1. Redueix el treball del fil principal

JavaScript pesat és l’enemic número u de l’INP. Cada mil·lisegon que el fil principal està ocupat executant JavaScript és un mil·lisegon que l’usuari espera per veure la resposta a la seva interacció.

Solucions:

Divideix les tasques llargues (Long Tasks) en tasques més petites fent servir scheduler.yield() o setTimeout.
Elimina scripts de tercers innecessaris. Cada widget, tracker o xat que afegeixes competeix pel fil principal.
Fes servir Web Workers per moure càlculs pesats fora del fil principal.

2. Optimitza els event handlers

Si el codi que s’executa quan l’usuari fa clic és lent, el INP serà dolent independentment de la resta.

Solucions:

Evita manipulacions del DOM innecessàries als event handlers.
Fes servir requestAnimationFrame per separar la lògica de negoci de les actualitzacions visuals.
Implementa debounce o throttle en interaccions freqüents com scroll o resize.

3. Minimitza la mida del DOM

Un DOM excessivament gran alenteix totes les operacions de layout i pintura. Google recomana que el DOM no superi els 1.400 nodes.

Solucions:

Implementa virtualització per a llistes llargues (només renderitza els elements visibles).
Simplifica l’estructura HTML eliminant wrappers innecessaris.
Carrega seccions de contingut sota demanda quan són rellevants.

4. Redueix l’impacte dels scripts de tercers

Analytics, xats en directe, pixels de seguiment, widgets de xarxes socials. Cada script de tercers que afegeixes al teu web té un cost en INP.

En la meva experiència, el 40-60% del JavaScript que executa un web mig prové de scripts de tercers. Fes una auditoria de tots els scripts que carregues i elimina els que no aportin valor clar.

Solucions:

Carrega els scripts no essencials amb defer o dinàmicament després de la interacció de l’usuari.
Fes servir facades per a widgets pesats: mostra una imatge estàtica del xat o del mapa i carrega el widget real només quan l’usuari interactua.
Implementa una política de “pressupost de JavaScript”: defineix un límit màxim de KB de JS i no el superis.

CLS: Cumulative Layout Shift

Què és i com funciona

El CLS mesura quant es mou inesperadament el contingut visible de la pàgina. Aquells moments on estàs llegint un article i de sobte el text salta perquè s’ha carregat una imatge a dalt, o estàs a punt de fer clic en un botó i apareix un banner que desplaça tot.

Llindars:

Bo: Menys de 0,1.
Necessita millora: Entre 0,1 i 0,25.
Pobre: Més de 0,25.

El CLS es calcula multiplicant la fracció d’impacte (quin percentatge del viewport es desplaça) per la fracció de distància (quant es desplaça). Un valor de 0 significa que no hi ha cap moviment inesperat.

Les causes més comunes d’un CLS alt

1. Imatges i vídeos sense dimensions definides

Aquest és l’error més freqüent i el més fàcil de solucionar. Si no defineixes width i height als teus elements <img> i <video>, el navegador no pot reservar espai abans de carregar el recurs.

Solució: Defineix sempre les dimensions de les teves imatges. Amb CSS modern, pots fer servir aspect-ratio per mantenir les proporcions sense definir mides fixes:

img {
  width: 100%;
  height: auto;
  aspect-ratio: 16 / 9;
}

2. Anuncis, embeds i contingut injectat dinàmicament

Els banners publicitaris són una de les principals causes de CLS al web. Es carreguen després del contingut principal i empenyen tota la resta cap avall.

Solució: Reserva espai fix per als blocs de publicitat fent servir contenidors amb alçada mínima definida. Si no saps l’alçada exacta, fes servir la dimensió més freqüent de l’anunci com a mínim.

3. Fonts web que causen FOUT (Flash of Unstyled Text)

Quan una font web es carrega i reemplaça la font del sistema, pot causar un canvi de layout si totes dues fonts tenen mètriques diferents.

Solucions:

Fes servir font-display: optional per evitar el FOUT completament (la font web només es fa servir si ja és a caché).
Fes servir font-display: swap amb size-adjust perquè la font fallback tingui les mateixes mètriques que la font web.
Precarrega les fonts més importants: <link rel="preload" as="font" href="font.woff2" crossorigin>.

4. Contingut injectat sense reserva d’espai

Banners de cookies, barres de notificació, elements que apareixen condicionalment poden desplaçar el contingut si s’insereixen al flux del document.

Solució: Fes servir position: fixed o position: sticky per a elements que apareixen dinàmicament, de manera que no empenyin la resta del contingut. Els banners de cookies, per exemple, haurien d’anar sempre fixos a la part inferior de la pantalla.

Eines per diagnosticar i monitoritzar

Per a diagnòstic puntual

Chrome DevTools > Performance: Grava una sessió de càrrega i analitza exactament què causa els problemes. Pots veure el timeline de tasques del fil principal, els layout shifts i els esdeveniments LCP.
Lighthouse: Auditoria completa amb recomanacions específiques. Executa en mode “Mobile” amb throttling per simular condicions reals.
WebPageTest: Anàlisi més profund amb cascades de xarxa, filmstrip de càrrega i comparatives entre URLs.

Per a monitoratge continu

Google Search Console: Panell de Core Web Vitals amb dades de camp agrupades per estat. El millor lloc per veure la foto general.
CrUX Dashboard: Informes històrics amb Looker Studio per veure tendències al llarg del temps.
Eines RUM (Real User Monitoring): Si necessites dades més granulars, eines com web-vitals.js et permeten recopilar mètriques d’usuaris reals i enviar-les al teu sistema d’analytics.

Pla d’acció: prioritza correctament

Quan els tres Core Web Vitals necessiten millora, és important prioritzar. Basant-me en la meva experiència, aquest és l’ordre que recomano:

Ordre de prioritat per optimitzar Core Web Vitals: CLS primer, LCP segon, INP tercer

Prioritat 1: CLS

És la mètrica més ràpida de millorar en la majoria dels casos. Afegir dimensions a imatges, reservar espai per a anuncis i configurar correctament les fonts web són canvis que s’implementen en hores i tenen efecte immediat.

Prioritat 2: LCP

Els canvis de LCP (optimització d’imatges, caché, preload) solen tenir un impacte visible en 1-2 setmanes una vegada que el CrUX acumula prou dades noves.

Prioritat 3: INP

És la mètrica més complexa de millorar perquè generalment requereix refactoritzar JavaScript. Comença identificant les interaccions més lentes amb Chrome DevTools i aborda les tasques llargues una a una.

Impacte real al SEO

Els Core Web Vitals són un factor de ranking, però convé ser realista sobre el seu pes. No són el factor més important. El contingut rellevant, els backlinks i l’autoritat del domini segueixen tenint més pes a la majoria de consultes.

Tanmateix, en situacions de competència ajustada, els Core Web Vitals poden ser el factor diferencial. Si dues pàgines tenen contingut de qualitat similar i perfils d’enllaços comparables, Google afavorirà la que ofereixi millor experiència d’usuari.

A més, els Core Web Vitals afecten indirectament altres mètriques SEO. Un web ràpid i estable té:

Menor taxa de rebot (els usuaris no se’n van frustrats per la lentitud).
Major temps de permanència (naveguen més pàgines i llegeixen més contingut).
Major taxa de conversió (segons Google, per cada segon de millora a la velocitat de càrrega, les conversions poden augmentar fins a un 27%).

Millora l’experiència del teu web

Si els teus Core Web Vitals estan en vermell o groc i no saps per on començar, et podem ajudar. Al nostre servei de disseny i desenvolupament web construïm llocs optimitzats per al rendiment des de la base, i amb el nostre servei de SEO ens assegurem que la part tècnica del teu web no freni el teu posicionament.

Sol·licita una consulta gratuïta i analitzarem l’estat actual dels teus Core Web Vitals amb un pla de millora concret.