Mejorar el LCP: los cuatro tramos y cuál es el tuyo

La mayoría de los intentos de arreglar el LCP fallan por lo mismo: se aplican recomendaciones generales sin saber en qué parte del recorrido se pierde el tiempo. El LCP no es un número, son cuatro tramos consecutivos, y las acciones que arreglan el primero no tocan el tercero. Google publica cuánto debería pesar cada uno, y comparar tu reparto contra ese reparto convierte una lista de veinte consejos en uno o dos que sí van a mover el número.

Respuesta rápida

• El umbral es 2,5 segundos en el percentil 75 de las visitas reales.
• Se descompone en cuatro tramos, y solo uno de ellos es tu cuello de botella.
• El reparto ideal es 40 / 10 / 40 / 10. El que se desvía es el que hay que atacar.
• Nunca cargues en diferido la imagen del LCP. Es el error más común y el más caro.

¿Cómo se mejora el LCP?

Midiendo primero cuál de sus cuatro tramos se lleva el tiempo: el TTFB, el retraso hasta empezar a cargar el recurso, la descarga del recurso o el retraso hasta pintarlo. Google publica un reparto de referencia de 40 %, 10 %, 40 % y 10 %, y el tramo que se desvía de él es el que hay que atacar.

Qué tipo de problema es este

El encuadre que hace perder semanas es tratar el LCP como una propiedad general del sitio, del tipo "la web va lenta". Con esa idea se aplica todo a la vez: comprimir imágenes, minificar, poner una CDN, cambiar de hosting.

El LCP es más estrecho que eso. Mide cuándo aparece el elemento más grande visible al cargar, que suele ser una imagen, un vídeo o un bloque de texto, y solo eso. Optimizar cosas que ocurren después de que ese elemento se pinte no lo mueve ni un milisegundo.

Y es una secuencia. El navegador pide el HTML, lo recibe, descubre cuál es el recurso principal, lo pide, lo recibe y lo pinta. Cada una de esas etapas puede ser el problema, y las cuatro tienen soluciones que no se parecen en nada.

Los cuatro tramos, y qué hacer en cada uno

1. TTFB: hasta el primer byte

Es lo que tarda el servidor en empezar a responder. Debería llevarse alrededor del 40 % del total.

Cuando se lleva mucho más, el problema no está en la página sino detrás: una consulta a base de datos lenta, ausencia de caché, un servidor lejos del usuario, o redirecciones encadenadas que multiplican viajes. Las redirecciones son la causa más fácil de pasar por alto porque no se ven, y cómo evitarlas está en redirecciones 301.

2. Retraso de carga del recurso: el tramo delator

Es el tiempo entre que llega el HTML y el navegador empieza a descargar el recurso principal. Debería ser menos del 10 %, y es el tramo que más veces está disparado.

Si lo está, casi siempre es una de estas tres. La imagen se declaró con carga diferida, y la imagen del LCP nunca debe cargarse en diferido: la documentación de Google lo dice sin matices porque garantiza retraso. O el recurso lo inyecta JavaScript, así que no se descubre hasta que el script corre. O compite en prioridad con otras diez descargas.

El arreglo suele ser de una línea: quitar el loading="lazy" de esa imagen y marcarla con fetchpriority="high". Con el aviso que la propia documentación incluye: poner prioridad alta a más de una o dos imágenes deja de servir para nada.

3. Duración de carga: bajar el recurso

Debería estar alrededor del 40 %. Si se pasa, el recurso pesa demasiado o viaja mal.

Aquí sí funcionan los consejos habituales: formato moderno, dimensiones adecuadas al hueco real, compresión, y servir desde un sitio cercano al usuario. Es el tramo donde más gente empieza y donde a menudo no estaba el problema.

4. Retraso de renderizado: llegó y no se ve

Menos del 10 %. Cuando se dispara, el recurso ya está en el navegador y algo impide pintarlo: una fuente que bloquea, CSS crítico que llega tarde, o contenido que solo aparece cuando termina de ejecutarse JavaScript, que es un caso aparte y está en JavaScript y SEO.

Dónde se mide esto de verdad

Con la distinción que decide todo lo demás: los datos de campo son los que cuentan y los de laboratorio son los que explican.

Google evalúa el LCP sobre visitas reales, en el percentil 75, así que tres de cada cuatro visitas deben estar por debajo del umbral. Ese es el número que aparece en Search Console y el que tarda semanas en moverse.

El desglose en cuatro tramos, en cambio, sale de una medición de laboratorio o de la consola del navegador, y responde al instante. La secuencia sensata es diagnosticar en laboratorio, arreglar y esperar a que el campo lo confirme. Cómo leer el informe sin confundir los dos está en Core Web Vitals.

Cuándo no tocar el LCP

Cuando ya estás por debajo de 2,5 segundos en campo. El umbral es un umbral, no una escala continua de premios.

Cuando la página no recibe visitas. Optimizar la carga de algo que nadie abre es trabajo perfectamente medible y perfectamente inútil.

Cuando el problema real es de indexación. Una página que no está en el índice no tiene LCP que valga.

Cuando el desglose dice que el tramo malo es el TTFB y no controlas el servidor. Ahí la conversación es con quien lo aloja, no con el HTML.

El 90 % que no tiene estudio, y los otros tres tramos

Comprobado el 13 de agosto de 2026, una de las guías mejor posicionadas para esta consulta abre con una cifra redonda: el 90 % de los problemas de LCP son imágenes gigantes y sin optimizar en la cabecera. No la acompaña de ninguna medición, y no aparece en ninguna fuente localizable.

Lo que sí está publicado es el reparto que Google da como objetivo para los cuatro tramos de arriba: en torno a un 40 % para la respuesta del servidor y otro 40 % para la descarga del recurso, con menos de un 10 % para cada una de las dos esperas. Es decir que, incluso en el caso ideal, el peso de la imagen explica alrededor de la mitad del tiempo, no el noventa por ciento. Y cuando una de las dos esperas se pasa de ese 10 %, el problema ya no es de peso: es que el navegador tarda en enterarse de que esa imagen existe, o que la pinta tarde aunque ya la tenga.

La consecuencia práctica es la de siempre con las cifras redondas. Un 90 % autoriza a saltarse la medición, porque si nueve de cada diez casos son lo mismo, mirar cuál es el tuyo parece tiempo perdido. Se comprime la imagen, el número no se mueve, y la conclusión que se saca es que las Core Web Vitals no sirven para nada.

Errores que se repiten

• Cargar en diferido la imagen del LCP. Garantiza retraso, siempre.
• Optimizar imágenes antes de mirar el desglose. Puede que el tramo malo sea otro.
• Poner prioridad alta a diez imágenes. Priorizar todo es no priorizar nada.
• Juzgar por el número de laboratorio. El que Google usa es el de campo.
• Cambiar de hosting sin medir el TTFB. Es caro y a veces no era eso.
• Repetir la medición cada día. El dato de campo es una ventana de 28 días.

Ninguna de las cuatro palancas de arriba mueve las otras dos métricas, y conviene saberlo antes de repartir el presupuesto. Comprimir la imagen no cambia nada si el hueco no estaba reservado: eso es estabilidad visual. Y la respuesta a la interacción vive en el JavaScript, no en las imágenes: qué es INP. El orden entre las tres está en cómo mejorar la velocidad de una web.

Datos y transparencia

Que el reparto objetivo del LCP es de alrededor del 40 % para la respuesta del servidor y otro 40 % para la descarga del recurso, con menos del 10 % para cada una de las dos esperas, procede de la guía de optimización de la métrica de Google, abierta el 13 de agosto de 2026. Que una de las guías mejor posicionadas en español atribuye el 90 % de los problemas a la imagen de cabecera sin citar medición alguna es una observación propia del mismo día y se recoge como cifra sin respaldo, no como fuente.

El umbral de 2,5 segundos para un LCP bueno, el rango de 2,5 a 4 segundos para mejorable y más de 4 para deficiente, la evaluación en el percentil 75 con móvil y escritorio por separado, los cuatro tramos con sus definiciones y el reparto de referencia de 40 %, menos del 10 %, 40 % y menos del 10 % proceden de la documentación pública de Google sobre LCP y su optimización, comprobada el 12 de agosto de 2026. La advertencia de no cargar nunca en diferido la imagen del LCP y la de que marcar más de una o dos imágenes con prioridad alta deja de ser útil son citas de esa misma documentación. No aparece aquí ninguna cifra sobre cuánto mejora la conversión o la posición por cada décima de segundo: las que circulan proceden de estudios sobre sitios concretos cuyas condiciones no son extrapolables. El orden de diagnóstico es juicio operativo de trabajo sobre una cartera que registra más de 300 millones de impresiones anuales en Search Console. Verificado en agosto de 2026.

Fuentes primarias, abiertas el 13 de agosto de 2026: la guía de optimización del LCP.

Lo que esto cambia

Hay un patrón aquí que se repite en todo el SEO técnico y que este caso muestra mejor que ninguno.

Cuando una métrica se puede descomponer, la descomposición es el trabajo y el resto es ruido. Sin ella, mejorar el LCP es aplicar una lista de veinte consejos con la esperanza de acertar; con ella, es mirar cuatro números, ver cuál se sale del reparto y hacer una cosa. La diferencia entre las dos formas de trabajar no es de conocimiento técnico, es de haberse parado a medir antes de empezar.

Preguntas frecuentes