El LCP (Largest Contentful Paint) és la mètrica de Core Web Vitals que més llocs suspenen. Mesura quant tarda a renderitzar-se l’element visual més gran de la part visible de la pàgina — normalment una imatge hero, un bloc de text principal o un vídeo de fons. Si aquell element tarda més de 2,5 segons a aparèixer, Google ho considera un problema.
El que fa frustrант el LCP és que els culpables solen ser decisions de disseny que semblen inofensives: una imatge hero en alta resolució, una font personalitzada que es carrega des d’un CDN extern o un carrusel que depèn de JavaScript per renderitzar. Identificar la causa exacta és el primer pas. Corregir-la sol ser més senzill del que sembla.
Què és el LCP i quin llindar marca Google
El LCP mesura el temps de renderitzat de l’element de contingut més gran visible al viewport. Google estableix tres llindars basats en el percentil 75 de les dades de camp (dades reals d’usuaris, no de laboratori):
- Bo: 2,5 segons o menys.
- Necessita millores: entre 2,5 i 4 segons.
- Deficient: més de 4 segons.
El percentil 75 significa que el 75% de les càrregues de pàgina han de complir el llindar perquè la pàgina es classifiqui com a “bona”. No n’hi ha prou que la mediana sigui ràpida; les càrregues lentes en connexions mòbils o dispositius antics també compten.
L’element LCP varia segons la pàgina. En una pàgina d’inici amb imatge hero, el LCP sol ser aquella imatge. En un article de blog, pot ser el primer paràgraf visible o la imatge destacada. En una pàgina de producte, pot ser la foto principal del producte. Saber quin és el teu element LCP en cada tipus de pàgina és imprescindible abans d’optimitzar.
El LCP forma part del conjunt de Core Web Vitals que Google usa com a senyals d’experiència de pàgina per al rànquing.
Diagnòstic: com identificar l’element LCP de la teva pàgina
Abans d’optimitzar, has de saber quin element determina el teu LCP. Hi ha diverses maneres d’identificar-lo:
PageSpeed Insights. Introdueix la URL i busca la secció “Diagnòstic”. PageSpeed mostra explícitament quin és l’element LCP amb una captura de pantalla ressaltada. A més, separa les dades de laboratori (simulades) i les de camp (usuaris reals del Chrome UX Report).
Chrome DevTools — pestanya Performance. Grava la càrrega de la pàgina i busca el marcador “LCP” a la línia temporal. En fer-hi clic, DevTools ressalta l’element exacte a la pàgina i mostra el temps de renderitzat.
Web Vitals Extension. L’extensió oficial de Google per a Chrome mostra les tres mètriques de Core Web Vitals en temps real, incloent-hi l’element LCP i el seu temps.
Search Console — informe de Core Web Vitals. Mostra les URLs agrupades per rendiment de LCP amb dades de camp agregades. No identifica l’element específic, però assenyala quines pàgines o grups de pàgines tenen problemes.
Un cop identificat l’element, les causes d’un LCP lent es redueixen a quatre categories principals.
Causa 1 — Imatges LCP sense optimitzar (WebP, preload, srcset)
Les imatges són la causa del 70% dels problemes de LCP. El patró habitual: una imatge hero de 2 MB en format PNG o JPEG sense comprimir, servida sense preload i sense format de nova generació.
Solucions
Format WebP o AVIF. Aquests formats ofereixen la mateixa qualitat visual amb un 25-50% menys de pes que JPEG. Un hero de 800 KB en JPEG pot reduir-se a 300-400 KB en WebP sense pèrdua visible. Les imatges en WebP milloren tant el rendiment com el SEO en reduir els temps de transferència.
Preload de la imatge LCP. Afegeix una etiqueta <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> a l’<head> de l’HTML. Això indica al navegador que descarregui la imatge abans de processar el CSS i JavaScript, reduint el LCP entre 200ms i 1 segon.
Atribut fetchpriority=“high”. Afegeix-lo directament a l’<img> de l’element LCP. Li diu al navegador que prioritzi aquesta imatge sobre altres recursos a la cua de descàrrega.
Srcset i sizes. Serveix mides d’imatge diferents segons el viewport. Un mòbil no necessita descarregar una imatge de 1920px d’amplada. Defineix breakpoints amb srcset i el navegador descarregarà la versió adequada.
Dimensions explícites. Defineix sempre width i height a les imatges perquè el navegador reservi espai abans de descarregar-les. Això no afecta directament el LCP, però prevé el CLS que pot retardar el renderitzat final.
Causa 2 — Servidor lent i TTFB alt
El TTFB (Time to First Byte) és el temps que tarda el servidor a enviar el primer byte de la resposta HTTP. Si el teu TTFB és de 800ms, el teu LCP no pot ser inferior a 800ms encara que tot allò altre sigui perfecte.
Llindars de referència
- Excel·lent: menys de 200ms.
- Acceptable: entre 200ms i 600ms.
- Problema: més de 600ms.
Solucions
CDN (Content Delivery Network). Distribueix el contingut estàtic des de servidors geogràficament propers a l’usuari. Un CDN pot reduir el TTFB de 600ms a menys de 100ms per a usuaris llunyans del servidor d’origen.
Memòria cau del servidor. Implementa memòria cau a nivell de servidor (Varnish, Redis, Cloudflare cache) per evitar regenerar la mateixa pàgina en cada sol·licitud. Les pàgines estàtiques s’han de servir directament des de la memòria cau sense processament.
Optimització de base de dades. Si el teu CMS executa consultes lentes en cada càrrega de pàgina, el TTFB serà alt independentment de la infraestructura. Revisa les consultes, afegeix índexs i considera usar generació estàtica per a pàgines que no canvien freqüentment.
HTTP/2 o HTTP/3. Aquests protocols permeten multiplexar connexions, reduint la latència en la descàrrega de múltiples recursos simultanis. La majoria de CDN i servidors moderns ja suporten HTTP/2.
Causa 3 — Recursos render-blocking (CSS, fonts, JS)
Els recursos que bloquegen el renderitzat impedeixen al navegador pintar contingut fins que es descarreguen i processen completament.
CSS render-blocking
Tot arxiu CSS enlaçat amb <link rel="stylesheet"> a l’<head> bloqueja el renderitzat per defecte. Si tens 5 arxius CSS que sumen 300 KB, el navegador no pintarà res fins a descarregar i processar els cinc.
Cal incrustar el CSS crític (els estils necessaris per al contingut above-the-fold) directament a l’<head> i carregar la resta de forma asíncrona amb media="print" onload="this.media='all'".
Fonts web
Les fonts personalitzades causen dos problemes: FOIT (Flash of Invisible Text — el text és invisible fins que carrega la font) i FOUT (Flash of Unstyled Text — el text apareix amb una font genèrica i després canvia). Tots dos afecten el LCP si l’element LCP és un bloc de text.
Usa font-display: swap per mostrar text immediatament amb una font de sistema i canviar a la personalitzada quan carregui. Preconnecta al domini de la font amb <link rel="preconnect" href="https://fonts.googleapis.com">. Considera usar fonts del sistema com a primera opció — la diferència visual és mínima i l’impacte en el rendiment és significatiu.
JavaScript render-blocking
Els scripts a l’<head> sense atributs defer o async bloquegen el parsejament de l’HTML. El navegador atura tot fins a executar l’script.
Usa defer per a scripts que necessiten el DOM complet (s’executen després del parsejament) o async per a scripts independents (s’executen quan es descarreguen). Elimina JavaScript innecessari de l’<head>.
Causa 4 — Lazy loading incorrecte en l’element above the fold
Aplicar loading="lazy" a l’element LCP és un dels errors més freqüents i més fàcils de cometre. Quan marques la imatge hero com a lazy, li dius al navegador que no la descarregui fins que estigui a prop del viewport. Però la imatge hero ja és al viewport des del primer moment — el resultat és un retard de càrrega innecessari.
Aplicar lazy loading a l’element LCP pot empitjorar la mètrica entre 500ms i més d’1 segon. És un error especialment habitual en llocs que apliquen lazy loading global a totes les imatges sense distingir les que estan above-the-fold.
No apliquis mai loading="lazy" a imatges que apareixen al viewport inicial. La imatge LCP ha de tenir loading="eager" (o simplement no tenir l’atribut, ja que eager és el comportament per defecte) i fetchpriority="high".
L’article sobre velocitat web i SEO analitza l’impacte de la velocitat en el posicionament més enllà del LCP, incloent-hi els efectes en conversió.
Preguntes freqüents sobre LCP
Quin és un bon LCP segons Google?
Google defineix tres rangs: bo (2,5 segons o menys), necessita millores (entre 2,5s i 4s) i deficient (més de 4 segons). L’objectiu ha de ser mantenir el LCP per sota de 2,5 segons en el percentil 75 de les dades de camp, tant en mòbil com en escriptori.
Com afecta el LCP al rànquing de Google?
El LCP és una de les tres mètriques de Core Web Vitals que Google usa com a senyals de rànquing. Un LCP lent no et penalitza directament, però et posa en desavantatge davant de competidors amb LCP més ràpid quan la resta de factors són similars.
És possible millorar el LCP sense canviar de servidor?
Sí, en molts casos. Optimitzar imatges (format WebP, compressió, srcset), eliminar CSS i JS render-blocking, usar preload per a recursos crítics i configurar correctament la prioritat de càrrega poden millorar significativament el LCP sense canviar d’infraestructura.
Si el teu LCP supera els 2,5 segons i no aconsegueixes identificar la causa arrel, necessites un diagnòstic tècnic que analitzi la cadena completa de càrrega. Contacta amb el nostre equip per mesurar el teu rendiment real amb dades de camp i aplicar les correccions que major impacte tindran en els teus Core Web Vitals.
Comparteix aquest article
Si t'ha resultat útil aquest contingut, comparteix-lo amb els teus col·legues.
Preguntes Freqüents
¿Con qué frecuencia publican contenido nuevo?
Publicamos artículos nuevos semanalmente, enfocados en las últimas tendencias de SEO técnico, casos de estudio reales y mejores prácticas. Suscríbete a nuestro newsletter para no perderte ninguna actualización.
¿Los consejos son aplicables a cualquier tipo de sitio web?
Nuestros consejos se adaptan a diferentes tipos de sitios: ecommerce, blogs, sitios corporativos y aplicaciones web. Siempre indicamos cuándo una técnica es específica para cierto tipo de sitio o requerimientos técnicos.
¿Puedo implementar estas técnicas yo mismo?
Muchas técnicas básicas puedes implementarlas tú mismo siguiendo nuestras guías paso a paso. Para optimizaciones avanzadas o auditorías completas, recomendamos consultar con especialistas en SEO técnico como nuestro equipo.
¿Ofrecen servicios de consultoría personalizada?
Sí, ofrecemos servicios de consultoría SEO técnica personalizada, auditorías completas y optimización integral. Contáctanos para discutir las necesidades específicas de tu proyecto y cómo podemos ayudarte.
