El llindar de 2,5 s que decideix la visibilitat de la teva pàgina
Imagineu la següent situació: un usuari cerca “sabatilles running pronació” a Google, fa clic a la teva pàgina de producte i durant 3,8 segons veu una pantalla en blanc o un layout parcial sense la imatge principal. Segons dades de Think with Google, la probabilitat que aquest usuari abandoni la pàgina ha crescut un 32% només per haver superat els 3 segons d’espera. Aquell element visual que no va carregar a temps — la imatge hero, el bàner principal, el vídeo de capçalera — és exactament el que Google mesura amb el LCP.
El Largest Contentful Paint és la mètrica de Core Web Vitals que quantifica quant tarda a renderitzar-se l’element visual més gran visible al viewport. Google estableix un llindar clar: per sota de 2,5 segons és bo, entre 2,5 i 4 segons necessita millora, i per sobre de 4 segons és deficient. El 2026, segons HTTPArchive, només el 58% dels llocs web a nivell global aconsegueixen un LCP inferior a 2,5 segons en mòbil, cosa que significa que el 42% restant està lliurant una experiència que Google considera millorable o directament dolenta.
El rellevant per al SEO és que Google avalua el LCP amb dades de camp reals — el percentil 75 de les visites recollides pel Chrome UX Report durant els últims 28 dies — i l’utilitza com a senyal de posicionament dins de l’experiència de pàgina. No és un factor teòric: és una mètrica que influeix directament en la posició que la teva pàgina ocupa als resultats de cerca.
Diagnòstic: com identificar l’element LCP de la teva pàgina
Abans d’optimitzar el LCP, cal saber amb exactitud quin element s’està mesurant. L’error més freqüent és assumir que el LCP correspon sempre a la imatge hero, quan en realitat depèn del contingut visible al viewport en el moment de la càrrega. En una pàgina de blog, l’element LCP pot ser un bloc de text H1. En una fitxa de producte, sol ser la imatge principal. En una landing page, pot ser un vídeo o un bàner promocional.
Chrome DevTools ofereix el diagnòstic més directe. Obriu la pestanya Performance, graveu una càrrega de pàgina i cerqueu el marcador LCP a la secció Timings. DevTools us assenyala exactament quin node del DOM és l’element LCP, quant ha trigat a renderitzar-se i quins recursos estaven a la ruta crítica. Aquest diagnòstic de laboratori és el punt de partida, però no substitueix les dades de camp.
PageSpeed Insights (pagespeed.web.dev) combina dades de laboratori amb dades de camp de CrUX. La secció “Diagnòstic” identifica l’element LCP i les oportunitats de millora ordenades per impacte estimat. La dada més valuosa és el LCP de camp — el percentil 75 real — perquè és el que Google utilitza per al posicionament.
Google Search Console reporta l’estat dels Core Web Vitals a nivell de domini, agrupant URLs amb experiència similar. Si veieu un grup d’URLs marcades com a “Deficient” en LCP, és probable que comparteixin una causa arrel: la mateixa plantilla, les mateixes imatges sense optimitzar, el mateix servidor lent.
La Web Vitals Extension de Chrome mostra el LCP en temps real mentre navegueu, marcant visualment l’element mesurat. És la forma més ràpida de verificar quin element s’està avaluant a qualsevol pàgina.
Un diagnòstic complet ha de cobrir tant escriptori com mòbil, perquè l’element LCP pot variar entre dispositius. Una imatge que a escriptori és la tercera més gran del viewport pot ser l’element dominant a la vista mòbil, alterant completament el LCP reportat.
Causa 1 — Imatges LCP sense optimitzar (WebP, preload, srcset)
Les imatges són responsables del 72% dels elements LCP a la web, segons una anàlisi de HTTPArchive sobre 8 milions d’URLs publicada el 2025. Això converteix l’optimització d’imatges en l’acció de major impacte per millorar el LCP a la majoria dels llocs.
Els problemes d’imatge que causen un LCP lent s’agrupen en quatre categories:
Format inadequat
Servir imatges en JPEG o PNG quan WebP ofereix una reducció de mida del 25–35% i AVIF del 40–50% sense pèrdua perceptible de qualitat. El 2026, WebP té un suport del 97% en navegadors i AVIF del 92%, cosa que elimina les excuses tècniques per no usar-los. Un retailer europeu va reportar que migrar les seves imatges de producte de JPEG a WebP va reduir el pes mitjà d’imatge de 380 KB a 112 KB, millorant el LCP de 3,2 a 2,1 segons en connexions 4G.
Absència de preload
El navegador no pot sol·licitar una imatge fins que descobreix l’etiqueta <img> o la referència CSS que la conté, cosa que ocorre després de parsejar l’HTML i potencialment després de descarregar i processar fulls d’estil. Afegir <link rel="preload" as="image" href="hero.webp"> al <head> permet al navegador començar la descàrrega immediatament, sense esperar al descobriment natural. Segons web.dev, el preload de la imatge LCP pot estalviar entre 200 i 600 ms en connexions típiques de mòbil.
Falta de srcset i sizes
Servir la mateixa imatge de 1920px a un dispositiu mòbil de 375px d’ample és malgastar fins al 80% de l’amplada de banda. L’atribut srcset amb múltiples resolucions i sizes amb les dimensions reals de l’element permet al navegador seleccionar la imatge més adequada. La combinació de WebP + srcset és l’optimització d’imatge més completa.
Dimensions no declarades
Les imatges sense atributs width i height explícits obliguen al navegador a recalcular el layout quan la imatge carrega, generant no només un LCP tardà sinó també CLS addicional.
Causa 2 — Servidor lent i TTFB alt
El Time to First Byte (TTFB) és el temps que transcorre des que el navegador envia la sol·licitud HTTP fins que rep el primer byte de resposta del servidor. És el punt de partida de tota la cascada de càrrega: si el TTFB és lent, absolutament tot el que ve després es retarda proporcionalment.
Google recomana un TTFB inferior a 800 ms com a objectiu, i web.dev el documenta com una de les sub-mètriques més determinants del LCP. La raó és matemàtica: si el servidor tarda 1.200 ms a respondre, el navegador té menys de 1.300 ms per descarregar, parsejar i renderitzar tot el contingut visible abans de superar el llindar de 2,5 segons del LCP. A la pràctica, amb aquest TTFB, és gairebé impossible aconseguir un bon LCP.
Les causes d’un TTFB alt són variades però ben documentades. Els servidors compartits de baix cost solen tenir temps de resposta entre 800 i 2.000 ms durant pics de trànsit. Els CMS com WordPress amb múltiples plugins que executen consultes a base de dades a cada petició poden afegir 300-800 ms al TTFB. Les aplicacions amb renderitzat dinàmic que no implementen memòria cau a nivell de servidor regeneren tota la pàgina a cada visita.
Les solucions escalen en complexitat i cost:
CDN (Content Delivery Network)
Distribuir el contingut des de servidors geogràficament propers a l’usuari pot reduir el TTFB entre 100 i 400 ms. Cloudflare, Fastly i AWS CloudFront són les opcions més comunes. Per a llocs estàtics o amb memòria cau agressiva, el CDN és la solució de major impacte-cost.
Memòria cau a nivell de servidor
Implementar memòria cau de pàgina completa (full-page cache) amb Varnish, Redis o la pròpia memòria cau del CDN elimina la necessitat de generar la pàgina dinàmicament a cada petició. Un lloc WordPress amb WP Super Cache o LiteSpeed Cache pot reduir el seu TTFB de 1.200 ms a 150 ms.
Actualització d’allotjament
Quan el servidor és el coll d’ampolla real — CPU insuficient, memòria limitada, discos lents — l’única solució és migrar a un allotjament amb més recursos. Els VPS amb NVMe i 4+ GB de RAM solen oferir TTFB consistentment per sota de 300 ms.
Generació estàtica (SSG)
Per a llocs el contingut dels quals no canvia a cada petició — blogs, documentació, catàlegs amb actualitzacions periòdiques — generar l’HTML en temps de build elimina completament el processament al servidor. Frameworks com Astro, Next.js (exportació estàtica) o Hugo lliuren TTFB de 20–80 ms des de CDN.
Millorar la velocitat web requereix abordar el TTFB com a primer pas, ja que condiciona el sostre de rendiment de totes les altres optimitzacions.
Causa 3 — Render-blocking resources (CSS, fonts, JS)
Fins i tot amb imatges optimitzades i un TTFB ràpid, el LCP pot ser alt si recursos a la ruta crítica de renderitzat bloquegen el navegador. Els tres tipus de recursos que més freqüentment causen bloqueig són els fulls d’estil CSS, les tipografies web i els scripts JavaScript síncrons.
CSS render-blocking
Els fulls d’estil són render-blocking per defecte: el navegador no pintarà cap contingut fins que hagi descarregat i processat tots els fulls CSS referenciats al <head>. En llocs amb múltiples fitxers CSS o un sol full de 200+ KB sense minificar, aquest bloqueig pot afegir 300–800 ms al LCP. Les solucions inclouen: inserir en línia el CSS crític (el necessari per al contingut above the fold) al <head>, carregar la resta amb media="print" onload="this.media='all'", i eliminar CSS no utilitzat amb eines com PurgeCSS. Segons dades de web.dev, l’extracció de CSS crític pot reduir el LCP entre 150 i 500 ms.
Tipografies web bloquejants
Les tipografies personalitzades es descarreguen després que el navegador processa el CSS que les referencia. Sense la directiva font-display: swap, el navegador pot ocultar el text durant la descàrrega de la tipografia, causant un flash de text invisible (FOIT) que retarda el LCP si l’element principal és text. La directiva swap indica al navegador que mostri el text amb una tipografia de sistema immediatament i canviï a la personalitzada quan estigui disponible. Combinada amb <link rel="preload" as="font" crossorigin>, aquesta configuració pot reduir l’impacte de les tipografies en el LCP en 100–300 ms.
JavaScript síncron
Els scripts sense atributs async o defer bloquegen tant el parsing de l’HTML com el renderitzat. Un script d’analítica de 150 KB carregat de forma síncrona al <head> pot retardar tot el renderitzat de la pàgina en 200–500 ms. La solució és carregar scripts de tercers amb defer (s’executen després del parsing) o async (s’executen quan acaben de descarregar-se), i moure els scripts que no són necessaris per al renderitzat inicial al final del <body>.
L’eina més eficaç per diagnosticar recursos bloquejants és la pestanya Coverage de Chrome DevTools, que mostra exactament quants bytes de cada fitxer CSS o JS s’utilitzen realment durant la càrrega de la pàgina. Percentatges d’ús inferiors al 30% indiquen fitxers que són candidats a optimització o divisió en chunks.
Causa 4 — Lazy loading incorrecte a l’element above the fold
Aquesta és la causa de LCP lent més irònica perquè s’origina en una bona intenció. El lazy loading amb loading="lazy" és una tècnica d’optimització legítima que retarda la càrrega d’imatges fora del viewport fins que l’usuari es desplaça cap a elles, estalviant amplada de banda i accelerant la càrrega inicial. El problema sorgeix quan s’aplica indiscriminadament a totes les imatges, inclosa la imatge que és l’element LCP.
Quan l’atribut loading="lazy" és present a la imatge hero — la que generalment és l’element LCP — el navegador l’exclou intencionalment de la càrrega prioritària. En lloc de començar la seva descàrrega immediatament, espera a confirmar que està al viewport, afegint un retard de 200-500 ms que se suma directament al LCP.
Google documenta aquest problema de forma explícita a la seva guia d’optimització del LCP a web.dev: “No usis lazy-load en imatges que estan al viewport. Això és particularment important per a l’element Largest Contentful Paint.” La recomanació és clara: l’atribut loading="lazy" mai no s’ha d’aplicar a imatges above the fold, i l’element LCP hauria de tenir loading="eager" (o simplement no tenir l’atribut, ja que eager és el comportament per defecte) juntament amb fetchpriority="high".
Un patró que es repeteix en CMSs i frameworks és l’aplicació automàtica de loading="lazy" a totes les etiquetes <img> generades pel sistema. WordPress, per exemple, va afegir lazy loading natiu a totes les imatges a partir de la versió 5.5, i encara que versions posteriors van excloure la primera imatge del contingut, molts temes i plugins sobreescriuen aquest comportament. Auditar l’HTML renderitzat — no el codi font de la plantilla — és el pas clau per detectar aquest problema.
La combinació òptima per a la imatge LCP és: format WebP o AVIF, preload amb <link rel="preload"> al <head>, atribut fetchpriority="high", sense loading="lazy", i amb width i height explícits. Aquesta configuració garanteix que el navegador prioritza la imatge LCP des del primer moment del parsing.
Checklist d’optimització LCP en 30 minuts
Aquesta checklist està ordenada per impacte descendent. Cada pas inclou l’eina de diagnòstic i l’acció correctiva. Un professional familiaritzat amb les eines pot completar tot el procés en una sessió de 30 minuts.
Pas 1: Identificar l’element LCP (2 minuts). Obriu Chrome DevTools, aneu a Performance, graveu la càrrega i cerqueu el marcador LCP a Timings. Anoteu quin element del DOM és el LCP i quin és el temps actual.
Pas 2: Verificar el format i la mida de la imatge (5 minuts). Si l’element LCP és una imatge, comproveu el seu format (WebP o AVIF preferible), el seu pes (objectiu: menys de 150 KB per a hero en mòbil), i si té srcset amb múltiples resolucions. Useu Squoosh (squoosh.app) per comparar formats i qualitats.
Pas 3: Verificar preload i fetchpriority (3 minuts). Inspeccioneu el <head> de l’HTML renderitzat. L’element LCP ha de tenir un <link rel="preload"> corresponent si és una imatge. L’atribut fetchpriority="high" ha de ser a l’etiqueta de l’element LCP. Verifiqueu que no tingui loading="lazy".
Pas 4: Mesurar el TTFB (3 minuts). A la pestanya Network de DevTools, observeu el primer document HTML. El timing “Waiting for server response” és el vostre TTFB. Si supera els 800 ms, la solució requereix memòria cau de servidor o CDN abans d’optimitzar altres aspectes.
Pas 5: Auditar recursos render-blocking (5 minuts). A PageSpeed Insights, reviseu les seccions “Eliminate render-blocking resources” i “Reduce unused CSS/JS”. A DevTools Coverage, identifiqueu fitxers CSS i JS amb ús inferior al 30%.
Pas 6: Verificar tipografies web (3 minuts). Comproveu que totes les declaracions @font-face incloguin font-display: swap. Verifiqueu si les tipografies tenen preload. Considereu usar tipografies de sistema per al contingut above the fold.
Pas 7: Mesurar el resultat (5 minuts). Repetiu la mesura a DevTools i verifiqueu el LCP. Compareu amb la mesura inicial. Per a dades de camp, l’actualització a CrUX tarda 28 dies, però PageSpeed Insights mostra una estimació immediata basada en dades de laboratori.
Pas 8: Documentar i monitoritzar (4 minuts). Registreu els canvis realitzats, el LCP abans i després, i configureu alertes a Google Search Console per detectar regressions futures en Core Web Vitals.
L’optimització del LCP no és un projecte únic sinó un procés continu. Cada actualització de contingut, cada nou script de tercers, cada canvi en l’allotjament pot afectar el LCP. Incorporar la verificació de Core Web Vitals al flux de desplegament — automatitzada amb Lighthouse CI o Web Vitals Reporter — és la forma més fiable de mantenir el rendiment a llarg termini.