Core Web Vitals sense fum: com diagnosticar el rendiment real d’una web

Obris PageSpeed Insights, analitzes una web i apareix un 72 en groc. Tornes a provar i ix 84. Canvies d’ordinador, repetixes la prova i apareix un 91. Aleshores comencen les preguntes: la web és ràpida o lenta? Cal optimitzar-la? Eixe número afecta el SEO? Per què Google Search Console diu que hi ha URLs amb problemes si Lighthouse pareix estar prou content?

El problema comença quan reduïm el rendiment d’una web a una puntuació. Les Core Web Vitals no són un examen en què cal traure un 100. Són mètriques dissenyades per a descriure parts concretes de l’experiència real dels usuaris i, sobretot, són una ferramenta de diagnòstic.

Entendre-les bé permet respondre una pregunta molt més útil que “quina nota té la meua web?”: què està fent que alguns usuaris tinguen una mala experiència i on està exactament el coll de botella?

Què són realment les Core Web Vitals

Actualment hi ha tres Core Web Vitals:

• LCP — Largest Contentful Paint: mesura la velocitat de càrrega percebuda del contingut principal.
• INP — Interaction to Next Paint: mesura la capacitat de resposta de la pàgina davant de les interaccions de l’usuari.
• CLS — Cumulative Layout Shift: mesura l’estabilitat visual de la interfície.

Per a considerar bona l’experiència, les referències actuals són:

Mètrica	Bona	Necessita millorar	Dolenta
LCP	≤ 2,5 s	2,5–4 s	> 4 s
INP	≤ 200 ms	200–500 ms	> 500 ms
CLS	≤ 0,1	0,1–0,25	> 0,25

Però hi ha un detall important: no es tracta d’aconseguir eixos valors una vegada en el nostre portàtil. L’avaluació es fa pensant en l’experiència de la majoria d’usuaris i utilitza com a referència el percentil 75. És a dir, aproximadament tres de cada quatre experiències haurien de trobar-se dins del llindar considerat bo.

Això canvia completament la manera de diagnosticar el rendiment.

El primer error: obsessionar-se amb la puntuació de PageSpeed

PageSpeed Insights mostra molta informació, però la puntuació de Lighthouse que apareix de manera tan visible sol acaparar tota l’atenció. I no hauria de fer-ho.

Una web pot traure una puntuació excel·lent en una execució de laboratori i, al mateix temps, oferir una experiència mediocre a una part important dels usuaris reals. També pot passar el contrari. La raó és senzilla: laboratori i producció no estan mesurant exactament el mateix.

Una prova de laboratori utilitza unes condicions controlades: un dispositiu simulat, unes determinades condicions de xarxa i una càrrega concreta de la pàgina. Els usuaris reals, en canvi, arriben amb mòbils ràpids i mòbils de gamma baixa, Wi-Fi, fibra o connexions mòbils deficients, navegadors en condicions diferents, memòries cau fredes o calentes, extensions, sessions llargues i formes diferents d’interactuar amb la interfície.

Per això, abans de començar a optimitzar, cal mirar quin tipus de dades estem observant.

Les dades de laboratori i les dades de camp no són intercanviables

Esta diferència és probablement una de les claus més importants per a interpretar correctament les Core Web Vitals.

Dades de laboratori

Ferramentes com Lighthouse permeten reproduir una pàgina en condicions controlades i són especialment útils per a detectar recursos que bloquegen el renderitzat, analitzar JavaScript, estudiar la càrrega d’imatges, localitzar tasques llargues, comparar canvis durant el desenvolupament o evitar regressions abans de desplegar.

Però una prova de laboratori és una simulació concreta, no l’experiència acumulada dels teus usuaris.

Dades de camp

Les dades de camp provenen d’usuaris reals. Google utilitza, entre altres fonts, el Chrome User Experience Report (CrUX) per a alimentar ferramentes com PageSpeed Insights i l’informe de Core Web Vitals de Search Console.

Estes dades reflectixen situacions que un test aïllat difícilment pot reproduir: dispositius lents, condicions reals de xarxa, usuaris que passen prou de temps en una pàgina, interaccions que ocorren diversos segons després de la càrrega, contingut personalitzat o de tercers i comportaments que només apareixen en producció.

D’ací podem extraure una regla pràctica prou útil: les dades de camp servixen per a detectar el problema i les dades de laboratori ajuden a investigar-lo. Confondre les dos coses porta fàcilment a optimitzacions innecessàries.

LCP: no sempre és “la imatge pesa massa”

El Largest Contentful Paint indica quant tarda a mostrar-se l’element de contingut més gran que veu l’usuari inicialment. Pot ser una imatge principal, un bloc gran de text, una imatge de fons o determinats elements de vídeo.

Un LCP lent sol provocar la sensació que la pàgina tarda massa a estar realment disponible, però reduir el diagnòstic a “comprimix la imatge” és massa simplista. Un LCP dolent pot vindre de diverses fases diferents.

1. El servidor tarda massa a respondre

Abans de mostrar el contingut, el navegador necessita rebre el document inicial. Un TTFB elevat pot arrossegar tot el que passa després, de manera que caldria revisar aspectes com el backend, la generació dinàmica de pàgines, la memòria cau, la CDN, les redireccions o la infraestructura.

2. El navegador descobrix massa tard el recurs LCP

Imagina una imatge principal que només pot descobrir-se després de descarregar CSS o executar JavaScript. La imatge podria pesar poc i, tot i això, començar a descarregar-se massa tard.

En eixe cas tenim un problema de priorització, no necessàriament de mida.

3. El recurs tarda massa a descarregar-se

Ací sí que entren factors com un arxiu excessivament pesat, un format inadequat, dimensions superiors a les necessàries, un servidor lent o una CDN mal configurada.

4. El recurs ja existix, però tarda a renderitzar-se

La imatge pot haver-se descarregat correctament i continuar sense aparéixer perquè el navegador està ocupat processant CSS, JavaScript o renderitzat.

Per això, un bon diagnòstic de LCP hauria de separar, quan corresponga: TTFB → retard de càrrega del recurs → descàrrega → retard de renderitzat.

La pregunta correcta no és simplement “com baixe el LCP?”, sinó “en quina part del LCP estem perdent el temps?”

INP: quan la web carrega ràpid però respon tard

Una web pot paréixer ràpida en carregar i ser desesperant quan comences a utilitzar-la. Polses el menú i tarda a obrir-se, selecciones una opció i durant unes dècimes no passa res, escrius en un buscador i la interfície respon amb retard o afiges alguna cosa al carret i no saps immediatament si el clic ha funcionat.

Això és precisament el terreny d’Interaction to Next Paint.

INP analitza la latència de les interaccions realitzades durant la vida de la pàgina i intenta representar si la interfície respon de manera consistent. No es limita al primer clic després de carregar, i això és important perquè una pàgina pot carregar perfectament i degradar-se després.

Les causes habituals solen trobar-se en tasques JavaScript massa llargues, excés de treball en el fil principal, listeners costosos, renderitzats innecessaris, un DOM excessivament gran, scripts de tercers, càlculs síncrons o una hidratació pesada en determinades aplicacions.

Lighthouse no pot mesurar l’INP real dels teus usuaris

Lighthouse executa una càrrega automatitzada sense un usuari real interactuant durant tota la sessió. Per això no pot mesurar INP de la mateixa manera que les dades de camp.

En laboratori s’utilitzen altres senyals, com Total Blocking Time (TBT), per a trobar problemes que poden acabar afectant l’INP. Però TBT i INP no són la mateixa mètrica: un bon TBT pot ser una pista, mentre que l’INP real continua necessitant interaccions reals.

CLS: una web que es mou també és una web lenta

El Cumulative Layout Shift mesura els desplaçaments inesperats d’elements visibles. Segur que ho has patit alguna vegada: vas a polsar un botó i just abans apareix un altre element damunt; estàs llegint un paràgraf i de sobte baixa mitja pantalla; intentes obrir un enllaç i acabes polsant un anunci perquè el contingut ha canviat de posició.

Este tipus d’experiència no té a veure amb esperar tres segons que carregue una pàgina, però sí que té molt a veure amb el rendiment percebut.

Entre les causes freqüents trobem imatges sense espai reservat, vídeos o iframes sense dimensions, bàners afegits després de carregar, anuncis dinàmics, widgets externs, fonts que canvien notablement les dimensions del text o contingut inserit per JavaScript davant d’elements ja visibles.

En este cas, optimitzar sol significar una cosa molt concreta: donar estabilitat al layout abans que arribe el contingut.

Com diagnosticar Core Web Vitals sense optimitzar a cegues

Un diagnòstic seriós hauria de seguir un ordre.

1. Comença per les dades reals

Primer comprova quina Core Web Vital falla, si el problema apareix en mòbil, escriptori o en els dos, quin conjunt d’URLs està afectat, si hi ha prou dades de camp i si el problema és estable o puntual.

Search Console i PageSpeed Insights són bons punts de partida. No òbrigues encara el codi buscant alguna cosa que optimitzar: primer identifica quina experiència està fallant.

2. Busca patrons entre pàgines

Si vint URLs presenten un LCP semblant i compartixen la mateixa plantilla, probablement no tens vint problemes diferents. Tens un problema de plantilla.

Això resulta especialment útil en ecommerce, blogs, fitxes de producte, directoris, webs multilingües o aplicacions amb layouts reutilitzats. Agrupar abans d’analitzar estalvia moltíssim treball.

3. Reproduïx el problema en laboratori

Una vegada saps què estàs buscant, DevTools, Lighthouse i el panell Performance es tornen realment útils.

Ja no estàs preguntant “què puc optimitzar?”, sinó alguna cosa molt més precisa: “per què esta plantilla té un LCP alt en mòbil?” o “quina tasca bloqueja el següent frame quan l’usuari obri este menú?”

Eixe canvi de pregunta és la diferència entre mesurar i diagnosticar.

4. Identifica la causa, no el símptoma

Una recomanació automàtica pot indicar “reduïx JavaScript no utilitzat”. Pot ser correcte, però això encara no explica què està causant el problema.

Potser tenim 300 KB de JavaScript innecessari i eliminar-los a penes afecta la Core Web Vital que realment està fallant. Optimitzar rendiment no consistix a completar una llista de suggeriments, sinó a trobar quin recurs, tasca o decisió arquitectònica està condicionant la mètrica problemàtica.

5. Corregix una causa i torna a mesurar

Les optimitzacions haurien de poder relacionar-se amb una hipòtesi.

Per exemple: el hero es descobrix tard perquè està carregat com a background des d’una fulla CSS secundària. La intervenció seria fer que el recurs fora visible abans per al navegador i ajustar-ne la prioritat. El resultat esperat seria reduir el retard abans d’iniciar la descàrrega de l’element LCP.

Això és molt més útil que instal·lar tres plugins d’optimització i celebrar que PageSpeed ha pujat nou punts sense saber per què.

No perseguisques un 100 en Lighthouse

Un 100 pot ser agradable, però no hauria de ser l’objectiu del projecte. A partir d’un cert punt, perseguir la puntuació perfecta pot portar a dedicar moltes hores a canvis amb un impacte pràcticament imperceptible per a l’usuari.

Fins i tot pot provocar decisions equivocades: eliminar funcionalitats útils, carregar-ho tot de manera diferida sense criteri, retardar scripts que sí que necessita la interfície, complicar innecessàriament l’arquitectura o introduir hacks específics per a una auditoria.

L’objectiu hauria de ser un altre: que els usuaris tinguen una experiència ràpida, estable i reactiva de manera consistent.

Les mètriques existixen per a ajudar-nos a avaluar això, no al revés.

Tampoc optimitzes únicament la pàgina d’inici

Un altre error freqüent és analitzar exclusivament la home. Però una web pot tindre una portada molt optimitzada i, al mateix temps, fitxes de producte lentes, pàgines de categoria amb massa JavaScript, posts amb imatges enormes, formularis amb un INP dolent o layouts que generen CLS.

Els usuaris no experimenten “la web” com una única URL. Experimenten pàgines concretes.

Per això convé diagnosticar plantilles, tipologies de pàgina i recorreguts, no una captura aïllada de la portada.

Core Web Vitals i SEO: importants, però sense màgia

Google recomana aconseguir bones Core Web Vitals tant per experiència d’usuari com per a tindre èxit en Search, i estes senyals formen part del conjunt d’aspectes relacionats amb l’experiència de pàgina.

Però això no significa que baixar un LCP de 2,8 a 2,4 segons faça pujar automàticament una web deu posicions en Google.

Una pàgina ràpida no substituïx contingut rellevant, una bona arquitectura, una indexació correcta, autoritat, resposta a la intenció de busca o un SEO tècnic ben implementat.

Les Core Web Vitals tampoc haurien de tractar-se com un truc SEO. Són, sobretot, una manera prou útil de detectar experiències deficients, i arreglar una experiència deficient ja és una bona raó per a treballar-hi.

Aleshores, quan val la pena intervindre?

Quan les dades reals mostren un problema consistent, quan una plantilla completa està perjudicant una part significativa dels usuaris, quan la interacció se sent pesada, quan el contingut es desplaça, quan la càrrega principal tarda massa o quan una regressió recent empitjora mètriques que abans funcionaven bé.

El que no té massa sentit és optimitzar durant hores una mètrica verda únicament per a aconseguir que un cercle canvie de 97 a 100.

Mesurar rendiment és fàcil. Diagnosticar-lo és una altra cosa

Hui qualsevol persona pot introduir una URL en PageSpeed Insights i obtindre una llista de recomanacions. La part difícil comença després.

Cal saber distingir símptomes i causes, laboratori i producció, dades d’una URL i patrons de plantilla, optimitzacions amb impacte i canvis cosmètics, mètriques tècniques i experiència real.

És ací on les Core Web Vitals deixen de ser tres sigles i comencen a ser realment útils.

Una bona optimització no comença intentant aconseguir millors números. Comença entenent per què eixos números són dolents.

I quan el diagnòstic és correcte, moltes vegades no cal fer vint canvis. Cal fer els dos o tres que realment importen.

La teua web té problemes de Core Web Vitals i no saps d’on venen?

En Tornem desenvolupem i optimitzem projectes web analitzant el problema des de la implementació, no únicament des d’una puntuació automàtica.

Si Search Console mostra problemes de Core Web Vitals, PageSpeed oferix resultats contradictoris o una web simplement no respon com hauria de fer-ho, podem estudiar què està passant i prioritzar les millores que realment tinguen impacte.

Perquè fer una web més ràpida no consistix a perseguir un 100. Consistix a saber què està frenant l’experiència i arreglar-ho on toca.