Qué está pasando probablemente
El recurso LCP se descubre demasiado tarde
Si la imagen hero aparece por CSS, lazy loading, JS, slider, componente cliente o background, el navegador no la encuentra pronto y el LCP se dispara.
TTFB alto antes de que empiece la página
Si el HTML tarda en llegar, ningún preload salva el primer viewport. Hay que mirar SSR, cache, CDN, middleware, revalidación y origen.
La imagen está bien comprimida pero mal priorizada
Puede ser AVIF/WebP y aun así cargar tarde si no tiene tamaños correctos, preload/fetchPriority cuando toca, cache estable o srcset/sizes adecuados.
Render delay por CSS, fuentes o hidratación
El recurso puede descargarse pronto pero no pintarse por CSS bloqueante, fuentes externas, JavaScript inicial, componentes cliente o animaciones del hero.
Terceros antes del contenido
CMP, chat, analytics, A/B testing, pixels y widgets pueden competir por CPU o red en móvil si cargan antes del contenido principal.
Cómo comprobarlo sin romper nada
Compara Search Console/Core Web Vitals, PageSpeed Insights y Lighthouse local. Si no coinciden, separa datos de campo, datos de laboratorio y condiciones de throttling.
Identifica el elemento LCP exacto en móvil y desktop. No optimices imágenes secundarias si el LCP real es un H1 o contenedor hero.
Desglosa LCP en TTFB, resource load delay, resource load duration y element render delay.
Revisa si el recurso LCP está en el HTML inicial, si usa lazy loading por error, si tiene fetchPriority/preload adecuado y si el srcset/sizes descarga un tamaño razonable.
Comprueba fuentes: font-display, preload de fuente crítica, peso de familias y si el texto LCP espera a una webfont.
Revisa CSS crítico, bundles iniciales, componentes client-side, sliders, animaciones y si la hidratación retrasa el primer viewport.
Prueba con y sin CMP, chat, analytics, pixels, A/B testing y scripts publicitarios para aislar terceros.
Agrupa por plantilla: home, servicios, artículos o problemas. Si falla una plantilla, arreglarla puede recuperar muchas URLs a la vez.
Cómo lo resolvería paso a paso
Arregla primero el tramo que más pesa
Si el problema es TTFB, trabaja cache/CDN/SSR. Si es resource load delay, haz visible y prioritario el recurso. Si es render delay, reduce CSS, fuentes, JS y trabajo de main thread.
Haz que el LCP sea descubrible desde el HTML
Para una imagen hero, evita lazy loading, background tardío o carga por JS. Usa dimensiones reales, srcset/sizes, cache fuerte y prioridad solo para el candidato LCP correcto.
Convierte móvil en la referencia principal
No declares victoria con desktop. Valida móvil, 4G simulado, dispositivo real y datos de campo cuando existan.
Carga marketing después del primer viewport
Consent, tracking, chat y herramientas comerciales deben seguir funcionando, pero no necesitan bloquear el contenido principal.
Mide impacto por plantilla
Después del cambio, revisa PageSpeed para URL de prueba y Search Console por grupos de URLs. No basta con optimizar una URL aislada si el problema vive en el layout.
Si se vuelve técnico
Puedes seguir esta ruta por tu cuenta. Si al comprobarlo aparece una discrepancia rara, una configuración de tracking delicada, una decisión de puja con riesgo o un bloqueo que requiere acceso a la cuenta, Lia guarda este contexto y te lleva a CreatikLab para continuar sin empezar desde cero.
Llevar este contexto a LiaQué no haría
Optimizar la imagen equivocada porque no se miró el elemento LCP real.
Confundir score de Lighthouse local con datos de campo de usuarios reales.
Preload de demasiados recursos y competir contra el propio contenido.
Usar lazy loading en una imagen hero que es LCP.
Ignorar fuentes, CMP, chat y tags porque no parecen parte del diseño.
Arreglar solo una URL cuando el problema está en una plantilla compartida.
Preguntas frecuentes
¿LCP afecta al SEO?
Core Web Vitals forman parte de la experiencia de página. No sustituyen relevancia ni contenido, pero Google recomienda tener buenas métricas y, para negocio, un móvil lento suele reducir conversión.
¿Por qué PageSpeed móvil sale mal si desktop está perfecto?
Móvil usa condiciones más duras de red y CPU. Además puede cargar otro hero, otro CSS, otro menú, otra CMP o más JavaScript visible en el primer viewport.
¿Una CDN arregla siempre LCP?
Ayuda si el problema es entrega de HTML o recursos. No arregla por sí sola CSS bloqueante, fuente crítica, hidratación pesada, imagen mal priorizada o terceros que cargan antes del contenido.
