El LCP (Largest Contentful Paint) es la métrica de Google que mide cuánto tarda el elemento principal de tu página en aparecer. Si está mal, perdés tráfico orgánico, conversión y la primera impresión del usuario. Si está bien, sumás ranking y reducés rebote. Esta guía es lo que aplicamos cuando un cliente nos llama porque "su sitio anda lento".

Qué es exactamente el LCP

El LCP es el tiempo (en segundos) que tarda en aparecer el elemento más grande visible en la primera pantalla de tu sitio. Suele ser:

  • La imagen del hero
  • El título grande (H1)
  • Un video preview
  • Un bloque de fondo con texto

Google define tres zonas:

  • Bueno: menos de 2.5 segundos
  • A mejorar: entre 2.5 y 4 segundos
  • Pobre: más de 4 segundos

Para empezar, corré tu URL en nuestro test de velocidad y mirá en qué zona estás. La métrica se mide en mobile (más estricto) y desktop. Mobile es la que más cuenta para SEO.

Identificar el elemento LCP de tu sitio

Antes de optimizar, tenés que saber qué elemento está siendo medido. Hay tres formas:

1. PageSpeed Insights

En el reporte de PSI, scrolleá hasta "Diagnóstico" → "Largest Contentful Paint element". Te muestra el HTML exacto del elemento.

2. Chrome DevTools

Abrí DevTools → Performance → grabá un reload. Después en el timeline buscá "LCP". Chrome te marca el elemento en pantalla.

3. Web Vitals extension

Instalá la extensión Web Vitals de Google en Chrome. Te muestra LCP, INP y CLS en vivo mientras navegás cualquier sitio.

Las 7 causas más comunes de LCP alto

1. Imagen del hero pesada y sin optimizar

El caso más común. Tu hero tiene una imagen de 1.5 MB en JPG. Solución:

  • Convertí a WebP (o AVIF si te animás): reduce 25-35% sin pérdida visual
  • Servila al tamaño correcto con srcset + sizes
  • Agregá fetchpriority="high" al <img> del hero
  • No uses loading="lazy" en imágenes above-the-fold (rompe el LCP)

2. Fuentes web que bloquean el render

Si tu H1 es el LCP y la fuente tarda en cargar, el LCP espera hasta que llegue la fuente. Solución:

  • Preload de la fuente crítica: 
    <link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
  • Usá font-display: swap en tu @font-face para mostrar fallback mientras carga
  • Auto-host las fuentes (no las traigas de Google Fonts en producción)

3. Hosting lento (TTFB alto)

Si tu Time to First Byte es mayor a 800ms, el LCP nunca va a estar bien porque arranca tarde. Causas:

  • Hosting compartido barato (5 USD/mes con 500 sitios en el mismo server)
  • Queries DB pesadas sin cache
  • Plugins de WordPress que ejecutan cosas en cada request

Si tu TTFB está mal, leé nuestra guía de hosting con la comparativa real. A veces cambiar de hosting baja el LCP 1.5 segundos sin tocar nada del código.

4. CSS y JavaScript render-blocking

Cada <script src="..."> y <link rel="stylesheet"> en el head que no tenga async o defer frena el render del HTML. Solución:

  • Inline el CSS crítico (above-the-fold) en el head
  • El resto del CSS cargalo asíncrono
  • defer en todos los JS no críticos
  • Movié analytics y pixels al final del body con async

5. Sin compresión Brotli/Gzip

Si tu servidor no comprime los archivos, mandás HTML/CSS/JS 4 veces más pesados de lo necesario. En el .htaccess de Apache:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css application/javascript
</IfModule>

Brotli (más moderno, mejor compresión) está disponible en hostings serios y se activa similar.

6. CDN ausente o mal configurado

Si tu sitio sirve TODO desde un solo server en San Pablo o Madrid, el visitante de Bahía Blanca espera 200ms por cada asset. CDN delante (Cloudflare gratis, o BunnyCDN, o el de tu hosting) sirve los assets desde el nodo más cercano.

7. Cache de página ausente

Cada visita ejecuta PHP + queries DB de cero. Activá cache de página (WP Rocket, LiteSpeed Cache, o lo que ofrezca tu hosting). El HTML servido desde cache puede dropear LCP 1+ segundo.

Checklist de optimización LCP (en orden de impacto)

  1. Imagen LCP en WebP/AVIF con fetchpriority="high" y srcset
  2. Sin loading="lazy" en above-the-fold
  3. Preload de fuentes críticas + font-display: swap
  4. Critical CSS inline en el head
  5. Defer/async en JS no crítico
  6. Cache de página activo
  7. CDN delante del origen
  8. Gzip/Brotli activo
  9. Hosting con TTFB < 400ms
El error más caro es optimizar el código y mantener un hosting que tarda 1.2s solo en empezar a responder. Sin un buen punto de partida, todo lo demás es maquillaje.

Casos especiales

WordPress

El stack que usamos en WordPress para LCP en verde:

  • Hosting con LiteSpeed (Webempresa, A2)
  • LiteSpeed Cache (gratis, brutal)
  • Tema liviano (Astra, GeneratePress, Blocksy)
  • WebP automático (ShortPixel, Imagify)
  • Cloudflare delante

Ecommerce

Tu fila de productos puede tener 8 imágenes en el viewport. LCP probablemente sea una de ellas. Aplicá fetchpriority="high" solo a la primera, el resto pueden ir loading="lazy" sin problema.

SPA (React, Vue, Next.js)

Si tu sitio es SPA, el HTML inicial es vacío y todo se hidrata después. Resultado: LCP horrible. Solución: SSR o SSG. Next.js/Nuxt/Astro lo resuelven nativamente.

Cómo medir mejoras reales

No confíes en una sola medición. Las herramientas:

  • PageSpeed Insights: nuestro test usa la misma API. Mostrá mobile, no solo desktop.
  • Search Console → Core Web Vitals: datos reales de usuarios (CrUX), no simulados.
  • WebPageTest: gratis, muy granular, opciones de geolocalización.
  • Web Vitals extension: en tu propio browsing.

Search Console es la fuente de verdad para SEO porque Google usa los datos reales de Chrome (CrUX). Si PSI te dice 1.8s pero CrUX dice 3.2s, Google te ranquea con 3.2s.

Próximos pasos

Si querés ir más profundo:

Si querés que lo hagamos por vos, en Jumpweb ofrecemos auditorías SEO técnicas completas con plan de acción priorizado y ejecución.