Les Core Web Vitals serveixen per mesurar tres aspectes força concrets de l'experiència d'una web:
- quant triga a aparèixer el contingut principal;
- com respon quan algú hi interactua;
- i quant es mou de manera inesperada mentre carrega.
Són LCP, INP i CLS.
Google recomana aconseguir bones Core Web Vitals i explica que estan alineades amb el que els seus sistemes de rànquing volen recompensar. Però també deixa clar que no hi ha un únic senyal d'experiència de pàgina i que intenta mostrar el contingut més rellevant encara que l'experiència de la pàgina sigui millorable.
Una web ràpida amb contingut poc rellevant continua tenint aquest problema.
I un 100 a Lighthouse tampoc no s'hauria de convertir en l'objectiu del projecte.
Les tres Core Web Vitals
| Mètrica | Què intenta mesurar | Bo |
|---|---|---|
| LCP | Quan apareix el contingut principal | ≤ 2,5 s |
| INP | Com respon la pàgina a les interaccions | ≤ 200 ms |
| CLS | Quant es mou el contingut inesperadament | ≤ 0,1 |
Google avalua aquests valors al percentil 75 de les visites, per separat al mòbil i a l'ordinador.
Vol dir que la web no es jutja per una única càrrega perfecta des del teu ordinador.
S'intenta observar quina experiència té la majoria d'usuaris reals.
LCP: quan apareix el que importa
Largest Contentful Paint mesura quan es mostra l'element més gran visible a la primera pantalla: normalment una imatge, un bloc de text o un vídeo.
Si triga massa, algunes causes habituals són:
- una imatge principal pesada o mal servida;
- un servidor que respon lent;
- fonts, CSS o JavaScript que endarrereixen el renderitzat;
- carregar amb
lazyun element que hauria d'aparèixer de seguida.
No es tracta que tota la pàgina acabi de carregar en 2,5 segons.
LCP mesura una cosa molt més concreta.
INP: com respon quan fas alguna cosa
Interaction to Next Paint mesura quant triga la pàgina a mostrar una resposta visual després d'interaccions com fer clic, tocar la pantalla o fer servir el teclat.
Un INP alt sol fer que una web se senti maldestra encara que aparentment hagi carregat de pressa.
JavaScript pesat, tasques llargues o scripts de tercers en són causes habituals.
INP va substituir FID com a Core Web Vital el 2024.
CLS: que la pàgina no es mogui sota els teus dits
Cumulative Layout Shift mesura els desplaçaments inesperats.
L'exemple típic: vas a prémer un botó, carrega una imatge, tot baixa i acabes prement una altra cosa.
Reservar espai per a imatges i elements incrustats, controlar com carreguen les fonts i evitar inserir elements inesperadament damunt del contingut ajuda a reduir-lo.
PageSpeed Insights barreja dos tipus de dades
Aquesta distinció importa més que perseguir el número gran de dalt.
Dades de camp
Són experiències d'usuaris reals recollides a través del Chrome UX Report (CrUX).
Quan n'hi ha prou, PageSpeed Insights les pot mostrar i Search Console les fa servir per al seu informe de Core Web Vitals.
Són les dades més útils per saber què els passa realment a les persones que visiten la web.
Una web nova o amb poc trànsit pot no tenir-ne prou.
Això no vol dir que hi hagi un problema.
Vol dir que encara no hi ha una mostra suficient.
Dades de laboratori
Són una prova feta en condicions controlades.
Lighthouse entra aquí.
Serveixen moltíssim per trobar problemes i provar canvis durant el desenvolupament, però no reprodueixen tots els dispositius, connexions i interaccions dels usuaris reals.
Per això pots tenir un Lighthouse excel·lent i unes dades de camp millorables, o a l'inrevés.
A més, en una prova de càrrega normal Lighthouse no mesura INP, perquè ningú no interactua amb la pàgina durant la prova. Fa servir altres mètriques, com Total Blocking Time, com a aproximació per detectar problemes relacionats, tot i que no el substitueixen.
I el TTFB?
Time to First Byte mesura quant triga a començar a arribar la resposta del servidor.
No és una Core Web Vital.
Pot ser útil per diagnosticar un LCP lent, perquè tot el que passa després depèn que la resposta comenci a arribar.
Com a orientació, web.dev situa 0,8 segons o menys com un bon objectiu per a moltes webs.
Però jo no perseguiria aquest número de manera aïllada si l'experiència real ja és bona.
Com les revisaria
El meu ordre seria força senzill:
- Mira primer si hi ha dades de camp. Search Console i PageSpeed Insights et poden dir si usuaris reals tenen un problema.
- Identifica quina mètrica falla. LCP, INP i CLS solen tenir causes força diferents.
- Fes servir el laboratori per investigar. DevTools i Lighthouse ajuden a trobar quina imatge, script o comportament ho provoca.
- Prioritza les pàgines que de debò importen. Una landing principal, un servei o una botiga mereixen atenció abans que una URL residual sense trànsit.
- Corregeix la causa i torna a mesurar.
Les dades de camp no canvien immediatament després de publicar una millora.
Necessiten visites noves i temps per reflectir-la.
No optimitzis una web contra la seva pròpia funció
Hi ha millores evidents: una imatge enorme que es pot servir millor, JavaScript innecessari, un disseny que salta, una font mal carregada.
Fes-les.
Però eliminar una fotografia necessària, un formulari útil o una funcionalitat important només per guanyar unes dècimes pot estar resolent el problema equivocat.
Les Core Web Vitals serveixen per detectar experiències millorables.
No per decidir què ha de tenir el teu negoci a la web.
El que importa al final
Intentaria aconseguir bons valors en totes tres.
Però no faria servir les Core Web Vitals com una puntuació de qualitat global de la web ni com una promesa de SEO.
Són una part d'una cosa més àmplia: contingut, estructura, usabilitat, accessibilitat, funcionament i experiència real.
Si vols saber quins problemes val la pena prioritzar abans de començar a tocar res, és el que revisem en una Auditoria web.
I si treballes amb Next.js i busques una revisió tècnica més àmplia, també tens la nostra checklist de SEO tècnic per a Next.js.
Escrivim sobre decisions que apareixen en projectes reals: com estructurar una web, com captar demanda i quan la tecnologia pot simplificar un negoci.