El que Google mesura realment amb els Core Web Vitals
Els Core Web Vitals són tres mètriques que descriuen l’experiència de càrrega tal com la viu un usuari real. El LCP mesura el temps d’exhibició del contingut principal. El CLS quantifica els salts de disseny mentre la pàgina es construeix. L’INP mesura el retard entre una acció de l’usuari i la resposta visible de la interfície.
El matís que gairebé tothom passa per alt es troba en el mètode d’avaluació. Google no reté la mitjana de les vostres visites. Reté el 75è percentil, en una finestra lliscant de 28 dies, i separa el mòbil de l’escriptori. Dit d’una altra manera, tres de cada quatre visitants han de quedar per sota del llindar perquè la mètrica sigui validada. Un lloc ràpid per a la majoria però catastròfic per al quart d’usuaris amb 4G degradada falla.
Aquesta mecànica explica per què tants llocs web mostren una puntuació de Lighthouse de 95 en local i es mantenen en vermell a la Search Console. La puntuació de Lighthouse simula una visita en condicions fixes. Els Core Web Vitals, en canvi, provenen del Chrome User Experience Report, la base de dades que Chrome alimenta amb les visites reals dels usuaris que han acceptat l’enviament d’estadístiques.
Els llindars oficials de Google: LCP inferior o igual a 2,5 segons, CLS inferior o igual a 0,1, INP inferior o igual a 200 mil·lisegons. Entre 2,5 i 4 segons, entre 0,1 i 0,25, entre 200 i 500 mil·lisegons, la mètrica es classifica com a «millorable». Més enllà, es classifica com a «deficient». Una URL només es considera conforme si les tres mètriques passen simultàniament.
Aquests tres indicadors tenen una història canviant. El FID, First Input Delay, va ser substituït per l’INP el 12 de març de 2024 perquè només mesurava el retard abans del processament de la primera interacció, cosa que deixava passar interfícies realment pesades. L’INP va fer caure immediatament en vermell milers de llocs WordPress sobrecarregats de scripts que fins aleshores mostraven un FID confortable. En les auditories que realitzem des de llavors, és la mètrica que falla més sovint.
LCP: l’element visible més gran decideix la vostra percepció de velocitat
El Largest Contentful Paint registra el moment en què l’element de contingut més gran visible a la finestra inicial s’acaba de mostrar. A la pràctica, es tracta gairebé sempre de la imatge de capçalera, d’un vídeo de fons o del bloc de títol principal. Google ha triat aquesta mètrica perquè correspon al moment en què el visitant considera que la pàgina ja hi és.
Identificar l’element LCP abans d’intentar res
Optimitzar sense saber quin element s’està mesurant fa perdre setmanes. La pestanya Performance de les DevTools de Chrome mostra un marcador LCP directament a la línia de temps, i PageSpeed Insights anomena l’element afectat a la secció de diagnòstics. En una web corporativa, és la imatge hero en el 80% dels casos. En una fitxa de producte, és la imatge principal del producte. En un article de blog, sovint és el mateix títol H1 quan la imatge destacada es carrega en diferit.
Descompondre el LCP en quatre segments
Un LCP de 4,8 segons no diu res fins que no es desglossa. El primer segment és el TTFB, el temps que triga el vostre servidor a retornar el primer byte. El segon és el retard abans del descobriment del recurs, és a dir, la diferència entre l’arribada de l’HTML i el moment en què el navegador entén que ha de descarregar aquesta imatge. El tercer és la descàrrega del recurs. El quart és el retard de renderització, sovint causat per un CSS o un JavaScript que bloqueja.
Aquesta descomposició ho canvia tot, perquè cada segment requereix una correcció diferent. Un TTFB d’1,2 segons se soluciona des de l’allotjament i la memòria cau del servidor, mai comprimint imatges. Un retard de descobriment elevat se soluciona eliminant el lazy loading de l’element LCP i afegint un atribut fetchpriority="high". Un temps de descàrrega excessiu requereix WebP o AVIF, un redimensionament real i un CDN. Un retard de renderització llarg delata una fulla d’estil massa pesada o una font web mal declarada.
El precarregament mereix una menció especial perquè sovint s’utilitza malament. Declarar una desena de recursos en preload equival a no prioritzar res: el navegador es troba amb deu urgències simultànies i l’ample de banda es reparteix entre elles. Un sol precarregament ben orientat a la imatge LCP, associat a un preconnect cap al domini que l’allotja quan prové d’un CDN, produeix un guany net. Més enllà d’això, l’efecte s’inverteix.
loading="lazy" a totes les imatges del lloc, inclosa la de l’hero. El navegador llavors posposa la descàrrega de l’element LCP i la mètrica es dispara. La imatge visible en carregar-se no s’ha de diferir mai.Google recomana un TTFB per sota dels 800 mil·lisegons per deixar un marge suficient als altres tres segments. En un WordPress compartit amb PHP 7.4 sense memòria cau d’objectes, aquest llindar és inabastable independentment del treball realitzat al front-end. És el primer punt que verifiquem durant una auditoria SEO tècnica, abans fins i tot de mirar el contingut.
CLS: l’instabilitat visual que els vostres visitants pateixen sense dir-ho
El Cumulative Layout Shift mesura els desplaçaments inesperats dels elements durant la càrrega. Cada desplaçament rep una puntuació que combina la fracció de la pantalla afectada i la distància recorreguda per l’element. El CLS retingut és el de la pitjor finestra de sessió, una finestra de 5 segons com a màxim, amb un interval d’un segon entre dos desplaçaments.
Ningú es queixa d’un CLS elevat, i això és precisament el que el fa perillós. El visitant que apunta a un botó i clica en un bàner publicitari perquè la pàgina s’ha mogut no omple cap formulari de contacte per informar-ne. Se’n va. En els llocs d’e-commerce que auditem, un CLS superior a 0,25 acompanya gairebé sistemàticament una taxa d’abandonament anormal a la fitxa de producte.
Les quatre causes que produeixen el 90% del CLS
Les imatges sense atributs width i height encapçalen la llista. Sense aquestes dimensions, el navegador no pot reservar l’espai i el text puja bruscament quan la imatge es carrega. La correcció consisteix en dos atributs, i WordPress els afegeix nativament des de la versió 5.5 per a les imatges inserides mitjançant l’editor, però no sempre per a les injectades per un tema o un constructor de pàgines.
A continuació venen els continguts injectats dinàmicament per sobre de la part superior de la pàgina: bàners de consentiment, barres de promoció, notificacions d’estoc. Cadascun empeny tota la resta cap avall. La solució consisteix a reservar l’alçada prèviament amb un contenidor de dimensió fixa, o a superposar l’element en lloc d’inserir-lo en el flux.
Les fonts web constitueixen la tercera causa. Quan una font personalitzada substitueix la font de reserva, les mètriques tipogràfiques canvien i el text es reajusta. La combinació de font-display: swap i size-adjust limita el fenomen, a condició de precarregar el fitxer de la font i allotjar-lo al vostre propi domini en lloc d’anar a buscar-lo a un tercer.
Els iframes i les integracions de tercers tanquen la llista. Un mapa, un reproductor de vídeo o un giny d’opinions de clients que es dimensiona a posteriori provoca un desplaçament sistemàtic. Reservar la ràtio d’exhibició en CSS soluciona el problema sense tocar el servei de tercers.
«Un CLS net no es corregeix a posteriori, es dissenya. En un lloc construït correctament des de la maqueta, amb ràtios d’imatge definides i zones reservades per a cada element asíncron, la mètrica cau naturalment per sota de 0,05.»
INP: la mètrica que sanciona els llocs sobrecarregats de scripts
L’Interaction to Next Paint mesura el temps entre una interacció i l’actualització visible de la pantalla. A diferència del FID al qual ha substituït, observa totes les interaccions de la visita, no només la primera, i reté la més lenta o gairebé. En les pàgines que superen la cinquantena d’interaccions, l’algoritme ignora un cas extrem per cada tram de cinquanta per evitar que un incident aïllat penalitzi el conjunt.
Tres components, tres responsables diferents
L’INP es descompon en retard d’entrada, temps de processament i retard de presentació. El retard d’entrada correspon a l’espera abans que el navegador pugui tan sols començar a processar el clic, perquè el fil d’execució principal està ocupat amb una altra cosa. El temps de processament és la durada d’execució dels vostres gestors d’esdeveniments. El retard de presentació cobreix el recàlcul del disseny i la renderització.
En la gran majoria dels casos trobats a WordPress, el culpable és el retard d’entrada, i el culpable darrere del culpable és un script de tercers. Un gestor d’etiquetes que carrega sis eines de seguiment, un giny de xat en directe, un mòdul d’opinions, un píxel publicitari: cadascun afegeix tasques llargues que monopolitzen el fil principal. El visitant clica, no passa res durant 600 mil·lisegons, i torna a clicar.
Reduir l’INP sense trencar les funcionalitats
La primera mesura consisteix a fer l’inventari dels scripts de tercers i eliminar aquells dels quals ningú consulta les dades. En els llocs que gestionem en manteniment WordPress, no és estrany desactivar tres eines de seguiment redundants instal·lades en èpoques diferents per proveïdors successius.
La segona consisteix a diferir el que es pugui. Un giny de xat no té cap motiu per carregar-se abans de la primera interacció del visitant. Carregar-lo al primer desplaçament o en passar el ratolí per sobre del botó allibera el fil principal durant la fase crítica.
La tercera consisteix a fragmentar les tasques llargues. Un gestor d’esdeveniments que executa 400 mil·lisegons de càlcul d’un bloc ha de retornar el control al navegador entre dues etapes, amb scheduler.yield() quan estigui disponible o un simple ajornament de l’execució. El treball total continua sent el mateix, però la interfície respon entre els segments.
Mesurar els Core Web Vitals: dades de camp contra dades de laboratori
Confondre aquestes dues fonts és l’error metodològic més estès. Les dades de camp provenen dels vostres visitants reals i constitueixen l’única font utilitzada per Google per a l’avaluació. Les dades de laboratori provenen d’una simulació executada a petició, en un entorn estandarditzat. Les primeres diuen on sou. Les segones diuen per què.
PageSpeed Insights, el punt de partida
L’eina mostra els dos blocs a la mateixa pàgina. A la part superior, l’avaluació de l’experiència d’usuari real, extreta del Chrome User Experience Report durant 28 dies. A la part inferior, el diagnòstic de Lighthouse i la seva llista d’oportunitats. El bloc superior és el que compta per al posicionament. El bloc inferior és el que us diu què heu de corregir.
Una pàgina amb poc trànsit no té prou visites per alimentar l’informe. PageSpeed Insights llavors passa a les dades de tot el domini, cosa que oculta totalment el comportament de la URL provada. Una fitxa de producte lenta pot així mostrar un verd tranquil·litzador heretat de la pàgina d’inici.
La Search Console, per analitzar a escala de tot el lloc
L’informe de Core Web Vitals agrupa les URL per similitud d’estructura i assenyala els grups que fallen. És l’eina que permet entendre que un problema prové d’una plantilla i no d’una pàgina. Quan 240 fitxes de producte apareixen en el mateix grup en vermell, la correcció es fa una vegada a la plantilla i cobreix tot el catàleg. Aquest raonament per plantilla és central en un projecte de SEO e-commerce, on el volum d’URL fa impossible qualsevol correcció unitària.
Cal comptar 28 dies després d’una correcció per veure com la Search Console passa al verd. La finestra lliscant de l’informe integra progressivament les noves visites. Validar un correctiu es fa al laboratori en una hora; confirmar-lo sobre el terreny triga un mes.
Mesurar en els vostres propis visitants
La biblioteca oficial web-vitals de Google permet recollir les tres mètriques directament al navegador dels vostres visitants i enviar-les a la vostra eina d’anàlisi. L’interès és segmentar per tipus de dispositiu, per navegador, per pàgina i per país, cosa que l’informe agregat no permet. En un lloc multilingüe que serveix a Andorra, França i Espanya, aquesta segmentació revela de vegades que el problema es limita a una zona geogràfica mal coberta pel CDN.
Corregir els Core Web Vitals a WordPress i Elementor
WordPress no és lent per naturalesa. Es torna lent per acumulació: un tema genèric carregat de funcionalitats no utilitzades, trenta extensions de les quals dotze injecten el seu CSS a totes les pàgines, un constructor de pàgines configurat per defecte, un allotjament compartit. Cada capa afegeix uns quants centenars de mil·lisegons.
L’allotjament i el TTFB, la base
Cap optimització front-end pot compensar un servidor lent. PHP 8.2 o superior, OPcache actiu, memòria cau d’objectes persistent amb Redis, memòria cau de pàgina completa, HTTP/2 com a mínim: aquesta base sol dividir el TTFB per tres. En un lloc amb trànsit internacional, un CDN que serveixi els recursos estàtics des d’un punt de presència proper al visitant completa el dispositiu. Això és exactament el que cobreix una oferta d’allotjament gestionat, a diferència d’un allotjament compartit d’uns pocs euros al mes on el vostre lloc comparteix recursos amb centenars d’altres.
Les imatges, el recurs més rendible
Tres accions en ordre. Servir WebP o AVIF en lloc de JPEG, cosa que redueix el pes entre un 30 i un 50% amb una qualitat visual constant. Redimensionar realment els fitxers en lloc de deixar que el navegador redueixi una imatge de 3000 píxels d’ample en un contenidor de 800. Aplicar el lazy loading a tot arreu excepte a l’element LCP, amb fetchpriority="high" en aquest últim.
El CSS i el JavaScript, la disciplina de la càrrega
El principi es resumeix en una frase: carregar en una pàgina només el que aquesta pàgina utilitza. Un formulari de contacte que injecta el seu CSS i el seu JavaScript a tot el lloc quan només apareix en una URL representa un malbaratament pur. La càrrega condicional dels recursos per extensió, la publicació del CSS crític al document i l’ajornament de la resta constitueixen el gruix del treball.
Elementor, els ajustos que marquen la diferència
Elementor Pro arrossega una reputació de pesadesa heretada en gran part de les seves versions antigues i de configuracions deixades per defecte. Les funcionalitats experimentals que cal activar són conegudes: càrrega optimitzada de recursos, càrrega de CSS sota demanda, icones de font en línia, sortida DOM optimitzada. Aquestes eliminen diverses desenes de kilobytes a cada pàgina.
La resta depèn del mètode de construcció. Els contenidors flexbox substitueixen amb avantatge l’antiga estructura de secció, columna i giny, que multiplicava els nivells d’imbricació i sobrecarregava l’arbre del document. Desactivar les biblioteques d’icones i les animacions no utilitzades elimina peticions senceres. En els nostres projectes de web a mida, limitem voluntàriament el nombre de ginys de tercers i reescrivim en HTML i CSS natius els blocs la versió de giny dels quals costa massa en rendiment.
Aquesta disciplina té un límit que cal assumir. En un lloc que acumula vuit anys de continguts, tres redissenys parcials i una biblioteca d’extensions heretada, l’optimització marginal arriba a un sostre. Un redisseny de lloc web sovint costa menys que dotze mesos de correctius successius sobre una base estructuralment compromesa, i dona un resultat que el pedaç mai no assolirà.
La base de dades i les extensions, el punt que ningú mira
Una instal·lació de WordPress de diversos anys acumula silenciosament un pes invisible des del front-end. Les revisions d’articles de vegades es compten per desenes de milers de línies, les taules de les extensions desinstal·lades es mantenen al seu lloc, les entrades transitòries caducades mai no es purguen. Cada petició de pàgina travessa aquesta massa i el TTFB s’allarga unes quantes desenes de mil·lisegons a cada capa.
La neteja es fa amb una còpia de seguretat prèvia, mai en calent en un lloc en producció. Limitar el nombre de revisions conservades, purgar les taules òrfenes, indexar correctament les columnes consultades per les extensions exigents: el guany rarament és espectacular per si sol, però se suma als altres i evita la deriva lenta que es constata en els llocs deixats sense seguiment. Això és precisament el que cobreix un contracte de manteniment seriós, a diferència d’una simple vigilància de disponibilitat.
Queda la qüestió del nombre d’extensions, sobre la qual circulen moltes aproximacions. Trenta extensions lleugeres i ben programades pesen menys que cinc extensions que carreguen cadascuna la seva biblioteca JavaScript completa a totes les pàgines del lloc. El criteri útil no és la quantitat, sinó el pes realment injectat pàgina per pàgina, que la pestanya Xarxa de les DevTools revela en pocs minuts.
L’impacte real en el vostre posicionament, sense exageracions
Cal ser honest sobre el pes d’aquestes mètriques en l’algoritme. Els Core Web Vitals són un senyal de classificació, confirmat i documentat per Google, però un senyal entre centenars. Un lloc perfectament optimitzat tècnicament i buit de contingut útil mai no passarà per davant d’una pàgina de referència lenta en una cerca competitiva. La rellevància i l’autoritat continuen sent el més important.
La seva influència es manifesta en dues situacions precises. La primera és l’arbitratge entre pàgines de qualitat comparable: a rellevància equivalent, l’experiència de pàgina decideix. En una cerca on deu resultats tracten el mateix tema amb la mateixa serietat, la diferència es juga aquí. La segona és el pressupost de rastreig. Un servidor lent redueix el nombre de pàgines que Google explora per sessió, cosa que retarda la indexació de les novetats en els llocs voluminosos.
L’efecte indirecte, però, pesa més que l’efecte directe. Una pàgina lenta augmenta la taxa de rebot, redueix el nombre de pàgines vistes per visita i fa caure la taxa de conversió. Aquests comportaments s’acaben reflectint en les dades que Google recull a escala web. Un procés de compra que triga quatre segons a reaccionar a cada clic perd cistelles abans fins i tot de perdre posicions.
Aquesta és també la raó per la qual tractem el rendiment com una restricció de disseny i no com una fase d’optimització final. Un lloc dissenyat amb un pressupost de rendiment definit des de la maqueta no necessita ser corregit a posteriori. Els projectes visibles a les nostres realitzacions es lliuren directament en verd, sense extensions miracle instal·lades a l’últim minut.
El mètode d’intervenció, en l’ordre que produeix resultats
L’ordre compta tant com les accions. Molts projectes fallen perquè comencen pel més visible en lloc del més determinant.
- Mesurar el punt de partida sobre el terreny. Recollir les tres mètriques a la Search Console, grup de pàgines per grup de pàgines, i no només a la pàgina d’inici.
- Tractar el servidor. Versió de PHP, memòria cau d’objectes, memòria cau de pàgina, TTFB per sota de 800 mil·lisegons. Res més no avança fins que aquest punt estigui resolt.
- Corregir l’element LCP per cada plantilla. Precarregament, prioritat de recuperació, format i dimensions reals de la imatge.
- Eliminar els desplaçaments. Dimensions en totes les imatges, espai reservat per als elements asíncrons, fonts precarregades i allotjades localment.
- Fer l’inventari dels scripts de tercers. Eliminar, diferir o carregar en la interacció. Aquest és el punt que desbloqueja l’INP.
- Alleugerir el CSS i el JavaScript de les extensions. Càrrega condicional, CSS crític en línia, ajornament de la resta.
- Esperar 28 dies i tornar a mesurar. Sobre les dades de camp, mai sobre una puntuació de laboratori.
Aquesta seqüència s’aplica tant a una web corporativa de dotze pàgines com a un catàleg de milers de referències. Només canvia l’abast del treball per etapa. En un lloc d’e-commerce, l’etapa tres i l’etapa cinc representen per si soles la major part de l’esforç, perquè les fitxes de producte concentren les imatges pesades i els scripts de personalització.
Una observació sobre el pressupost. El rendiment no és una línia opcional del pressupost, és una conseqüència de les eleccions d’arquitectura fetes al principi. Un projecte construït sobre un tema genèric comprat per 60 euros costarà més de corregir en tres anys que un desenvolupament net. El nostre simulador de preus de llocs web dona una forquilla realista en pocs minuts, i l’article que detalla quant costa un lloc web el 2026 explica què cobreix cada partida.
El que heu de recordar
Els Core Web Vitals no recompensen el rendiment teòric, recompensen el rendiment viscut pel quart menys afavorit dels vostres visitants. Aquesta diferència de perspectiva explica la discrepància permanent entre una puntuació de Lighthouse afalagadora i un informe de la Search Console en vermell.
Tres prioritats es desprenen del centenar d’auditories que hem realitzat. El servidor primer, perquè condiciona tota la resta i cap ajustament front-end compensa un TTFB degradat. L’element LCP després, perquè es corregeix ràpidament i produeix un guany immediatament mesurable. Els scripts de tercers finalment, perquè s’han convertit en la primera causa de fallada des de l’arribada de l’INP i ningú els vigila.
La resta depèn de la higiene del projecte: dimensions a les imatges, fonts allotjades localment, un espai reservat per a tot el que arriba després de la primera renderització, i el rebuig a les extensions que prometen solucionar-ho tot amb una casella de selecció. Un lloc ràpid no és un lloc optimitzat a posteriori, és un lloc construït correctament. Si les vostres mètriques continuen bloquejades malgrat les correccions, el problema és estructural i la discussió llavors és sobre l’arquitectura, no sobre els ajustos.
