Core Web Vitals el 2025: el que Google mira i tu probablement ignores
Google ha actualitzat els seus senyals de ranking. T'expliquem quins paràmetres mesura de veritat i com millorar-los sense canviar de stack.
Per Marc Puigdomènec

Els Core Web Vitals no són una moda de Google. Són senyals directes de qualitat d'experiència d'usuari que el cercador utilitza per prioritzar resultats des del 2021. El problema és que la majoria de webs —especialment les construïdes amb WordPress o eines de pàgina drag-and-drop— els falla sistemàticament sense que ningú s'en adoni fins que el trànsit cau. Si la teva web és lenta o inestable visualment, no només perds posicionament: perds conversions. Un estudi de Google mostra que cada segon addicional de càrrega redueix les conversions un 12% en mòbil.
Quins són els tres paràmetres que realment compten el 2025
El 2025 Google mesura tres mètriques principals. El LCP (Largest Contentful Paint) mesura quan tarda a apareixer l'element visual més gran de la pàgina —normalment la imatge hero o el titular principal. L'objectiu és menys de 2.5 segons en mòbil. Per aconseguir-ho, la imatge hero ha de tenir loading='eager' i fetchpriority='high', i les fonts no han de bloquejar el render.
L'INP (Interaction to Next Paint) va substituir el FID el 2024 i mesura la resposta visual de la pàgina a cada interacció de l'usuari —clics, taps, teclat. L'objectiu és menys de 200ms. Els principals culpables d'un INP alt són els scripts de tercers que s'executen al fil principal: analytics, xats, pixels de publicitat. Diferir-los o carregar-los de manera asíncrona és la solució més efectiva.
El CLS (Cumulative Layout Shift) mesura els salts visuals inesperats —quan el contingut es desplaça mentre carregues la pàgina perquè una imatge sense dimensions definides empeny el text. L'objectiu és menys de 0.1. La causa més habitual és imatges sense width i height definits al HTML, fonts que carreguen tard i canvien el text, o anuncis que apareixen sense espai reservat.
- LCP: afegeix loading='eager' i fetchpriority='high' a la imatge hero. Amb NuxtImg o next/image especifica :width i :height sempre.
- LCP: elimina fonts bloquejants del head. Usa media="print" onload="this.media='all'" per carregar Google Fonts de manera no bloquejant.
- INP: audita els scripts de tercers amb l'eina Coverage de Chrome DevTools. Cada script que no és crític ha de tenir defer o async.
- CLS: defineix width i height a totes les imatges, incloent les carregades via CMS. Reserva espai per a anuncis amb min-height.
- CLS: precarrega les fonts crítiques amb <link rel="preload" as="font">. Usa font-display: swap per evitar el FOIT (Flash of Invisible Text).
- Mesurar: usa PageSpeed Insights (real-world data del CrUX) i no només Lighthouse. Les puntuacions de lab i de camp poden diferir significativament.
- Prioritza mòbil: Google usa mobile-first indexing. Si el teu LCP en mòbil supera 4 segons, és crític independentment del resultat en desktop.
- Brotli: assegura que el teu servidor serveix compressió Brotli (no només Gzip). Redueix la mida del HTML/CSS/JS entre un 15-25% addicional.
Com prioritzar les millores si tens recursos limitats
No cal reescriure tota la web. La majoria de millores de Core Web Vitals es poden implementar en menys d'un dia si identifiques correctament els colls d'ampolla. Comença sempre pel LCP: és el que més impacte té al ranking i sol tenir solucions ràpides. Després va el CLS, que sol tenir fixes de CSS purs. Deixa l'INP per al final perquè requereix auditar scripts i pot tenir implicacions a tot el projecte.
Una cosa important: Google usa dades reals d'usuaris (CrUX dataset) per avaluar els Core Web Vitals, no els resultats de lab. Això vol dir que un Lighthouse de 90 no garanteix bones mètriques de camp si el teu públic usa dispositius d'entrada baixa o xarxes 3G. Mesura sempre amb Google Search Console → Experiència de la pàgina.
Si millores les tres mètriques de manera consistent durant 3 mesos, és habitual veure entre un 10 i un 30% d'increment de trànsit orgànic sense cap altra acció de SEO.