Core Web Vitals 2026: guia per a empreses - Ighenatt Blog

Tres mètriques. Tres llindars. I milers de llocs que els suspenen sense saber-ho.

Els Core Web Vitals no mesuren si la teva web és ràpida en el teu ordinador: mesuren l’experiència dels teus usuaris reals, en dispositius reals, amb connexions reals. En la pràctica, hem vist llocs que obtenen 95 a PageSpeed Insights i que fallaven en dades de camp perquè la majoria dels seus usuaris navegaven en mòbils de gamma baixa. La puntuació de laboratori no serveix de res si les dades de camp diuen una altra cosa.

Amb la consolidació de INP com a mètrica oficial el 2024, el panorama és clar. Aquesta guia desglossa què mesura cada mètrica, quins llindars exigeix Google i quines accions concretes milloraran les teves puntuacions en els propers 90 dies.

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

Els Core Web Vitals són tres mètriques que quantifiquen l’experiència real dels usuaris en interactuar amb una pàgina web. Google les va seleccionar perquè representen els tres aspectes més crítics de l’experiència de càrrega:

• LCP (Largest Contentful Paint): Velocitat amb la qual apareix el contingut principal.
• CLS (Cumulative Layout Shift): Estabilitat visual durant la càrrega.
• INP (Interaction to Next Paint): Rapidesa de resposta a les interaccions de l’usuari.

Google les va integrar al seu algorisme dins del senyal de Page Experience perquè correlacionen directament amb mètriques de negoci. Els llocs que compleixen els tres llindars tendeixen a rebre significativament més clics orgànics: els usuaris hi romanen més temps, reboten menys i generen senyals d’engagement més sòlids.

La lògica de Google és transparent: si dues pàgines competeixen per la mateixa paraula clau amb contingut i autoritat equivalents, la que ofereixi millor experiència tècnica guanya la posició. És un factor de desempat, però en mercats competitius, els desempats decideixen la primera pàgina.

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

El LCP mesura el temps que tarda a renderitzar-se l’element visible més gran dins del viewport. Pot ser una imatge hero, un bloc de text gran o un vídeo. Google estableix tres rangs:

• Bo: Menys de 2,5 segons
• Necessita millora: Entre 2,5 i 4,0 segons
• Deficient: Més de 4,0 segons

Causes freqüents d’un LCP lent

El LCP sol degradar-se per quatre raons principals: temps de resposta del servidor lents (TTFB alt), imatges hero sense optimitzar o servides sense formats moderns (WebP, AVIF), CSS i JavaScript que bloquegen el renderitzat, i renderitzat del costat del client que retarda l’aparició del contingut principal.

Per a una anàlisi detallada de cada causa i la seva solució tècnica, als apartats següents trobaràs les causes del LCP lent i com resoldre-les.

Optimitzacions d’alt impacte per al LCP

Les tres accions que més impacte tenen sobre el LCP són: implementar precàrrega (<link rel="preload">) per a la imatge o recurs LCP de cada pàgina, servir imatges en formats de nova generació amb dimensions explícites, i reduir el TTFB amb memòria cau a nivell de CDN i compressió Brotli.

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

El CLS quantifica els canvis inesperats de posició dels elements visibles durant la vida útil de la pàgina. Un CLS alt significa que el contingut “salta” mentre l’usuari intenta llegir o interactuar, generant frustració i errors de clic.

• Bo: Menys de 0,1
• Necessita millora: Entre 0,1 i 0,25
• Deficient: Més de 0,25

Els cinc responsables habituals del CLS

1. Imatges i vídeos sense dimensions declarades: El navegador no reserva espai fins que descarrega el recurs, provocant un reflow quan es renderitza.
2. Anuncis i embeds dinàmics: Els espais publicitaris que es carreguen tard empenten el contingut existent cap avall.
3. Fonts web sense font-display: Si la font es carrega després del text, el canvi de mida entre la font de substitució i la definitiva genera un layout shift.
4. Contingut injectat dinàmicament: Bàners de cookies, barres de notificació i elements inserits per JavaScript sense espai reservat.
5. Animacions que modifiquen propietats de layout: Fer servir top, left, width o height en animacions en lloc de transform i opacity.

La solució més efectiva és declarar sempre les dimensions dels elements multimèdia (width i height en HTML), fer servir aspect-ratio en CSS per a contenidors responsius, i reservar espai fix per a anuncis i embeds amb min-height.

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

El març de 2024, Google va reemplaçar FID (First Input Delay) per INP com a mètrica oficial d’interactivitat. El canvi va ser significatiu: FID només mesurava la latència del primer input de l’usuari, mentre que INP mesura la latència de totes les interaccions durant tota la sessió i reporta el percentil 75 de les pitjors.

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

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

FID era relativament fàcil d’aprovar perquè només considerava la primera interacció, que sol ocórrer quan la pàgina ja ha acabat de carregar el seu JavaScript. INP exposa problemes que FID ocultava: menús desplegables lents, formularis que bloquegen el fil principal en validar, i carrusels que s’encallen en fer swipe.

Com millorar INP

Les estratègies més efectives són: fragmentar tasques llargues de JavaScript en tasques més petites usant requestIdleCallback o scheduler.yield(), moure feina pesada a Web Workers, reduir la mida total de JavaScript eliminant dependències innecessàries, i usar content-visibility: auto per limitar la feina de renderitzat fora del viewport.

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

Existeixen dos tipus de mesurament, i és fonamental entendre la diferència:

Dades de camp (Field Data)

Provenen d’usuaris reals que naveguen amb Chrome i s’agreguen al Chrome UX Report (CrUX). Són les dades que Google utilitza per avaluar rànquings. Eines que les mostren:

• PageSpeed Insights: Mostra dades CrUX quan estan disponibles, juntament amb diagnòstics de Lighthouse.
• Google Search Console: L’informe de Core Web Vitals agrupa les URLs per estat (bo/millora/deficient).
• CrUX Dashboard (Looker Studio): Permet analitzar l’evolució històrica de les mètriques per origen o URL.

Dades de laboratori (Lab Data)

Es generen en entorns controlats i són útils per diagnosticar problemes específics, però no reflecteixen l’experiència real ni impacten directament en rànquings:

• Lighthouse (Chrome DevTools): Auditoria completa amb recomanacions tècniques.
• WebPageTest: Permet configurar localització, dispositiu i connexió per simular escenaris reals.
• Chrome DevTools Performance Panel: Anàlisi granular de JavaScript, renderitzat i xarxa.

La regla d’or: usa dades de laboratori per diagnosticar, però avalua l’impacte en rànquings amb dades de camp.

Benchmarks per sector: quines puntuacions aconsegueixen els líders

Les dades de l’HTTP Archive Web Almanac 2024 mostren diferències notables entre sectors. Conèixer-les ajuda a establir objectius realistes:

Ecommerce: Només el 57% dels llocs compleixen els tres llindars en mòbil. El LCP és la mètrica més problemàtica per les imatges de producte pesades i els scripts de tercers (analítica, remarketing, xat). Els líders del sector arriben a LCP < 1,8s mitjançant optimització agressiva d’imatges i lazy loading.

Mitjans i notícies: El CLS és el principal problema pels anuncis dinàmics. Els llocs que reserven espai fix per als espais publicitaris aconsegueixen CLS < 0,05. El LCP sol ser bo perquè el contingut principal és text.

SaaS i tecnologia: Generalment els millor posicionats, amb un 78% complint els tres llindars. L’arquitectura moderna (frameworks com Astro, Next.js amb SSR) i la menor dependència de scripts de tercers faciliten bones puntuacions.

Serveis professionals: El sector amb millors mètriques en proporció, ja que els llocs corporatius solen tenir poques dependències externes i contingut estàtic. El risc rau en temes de WordPress sobrecarregats amb connectors.

La relació entre velocitat web i SEO és directa: cada desena de segons compta quan la competència es troba als mateixos llindars.

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

Setmanes 1-2: Diagnòstic

Executa PageSpeed Insights a les 20 pàgines amb més trànsit. Registra els valors de LCP, CLS i INP tant en mòbil com en escriptori. Revisa l’informe de Core Web Vitals a Search Console per identificar les URLs agrupades com a “deficients”. Prioritza: les pàgines amb més trànsit i pitjors mètriques van primer.

Setmanes 3-4: LCP (l’impacte més ràpid)

Implementa preload per als recursos LCP de cada pàgina. Converteix imatges hero a WebP/AVIF amb dimensions explícites. Activa compressió Brotli al servidor. Si el TTFB supera els 600ms, avalua CDN o memòria cau a nivell de servidor. Aquestes accions solen reduir el LCP entre 0,5 i 2 segons.

Setmanes 5-6: CLS (correccions preventives)

Declara width i height en totes les imatges i vídeos. Reserva espai per a anuncis amb min-height. Implementa font-display: swap o optional en les fonts web. Usa aspect-ratio per a contenidors de vídeo incrustat. El CLS respon ràpidament perquè els canvis són preventius, no requereixen optimització de rendiment.

Setmanes 7-8: INP (la mètrica més tècnica)

Identifica tasques llargues amb el Performance Panel de Chrome DevTools. Fragmenta scripts que bloquegin el fil principal durant més de 50ms. Avalua si pots diferir o eliminar scripts de tercers no crítics. Implementa content-visibility: auto en seccions below-the-fold.

Setmanes 9-12: Monitoratge i ajust

Les dades de camp a CrUX s’agreguen en finestres de 28 dies. Espera almenys 4 setmanes després de les implementacions per veure reflectits els canvis. Configura alertes a Search Console i revisa l’evolució mensual. Documenta cada canvi i el seu impacte per justificar futures inversions.

Si el teu equip necessita ajuda amb la implementació tècnica, el nostre servei d’optimització de Core Web Vitals inclou diagnòstic, implementació i monitoratge continu.

Preguntes freqüents sobre Core Web Vitals

Els Core Web Vitals ja no són una novetat: són un estàndard consolidat que Google utilitza per decidir quins llocs mereixen la primera pàgina. Executa PageSpeed Insights a les deu pàgines amb més trànsit ara mateix. Si alguna dona un LCP per sobre de 2,5 segons o un CLS superior a 0,1, tens un problema concret a resoldre. Digues-nos què has trobat i t’indiquem per on començar.