01
Slow TTFB
Si el HTML llega tarde porque PHP, MySQL, fallos de caché o APIs externas son lentos, todas las fases posteriores del LCP también empiezan tarde.
Home / Optimización LCP en WordPress
Largest Contentful Paint · WordPress
Optimización LCP en WordPress empieza antes de que se descargue la imagen.
Un Largest Contentful Paint deficiente no siempre es un problema de tamaño de imagen. El tiempo de LCP se compone de respuesta del servidor, descubrimiento del recurso, descarga y retraso de renderizado. Identifico qué fase está consumiendo realmente el presupuesto y corrijo la ruta de WordPress/plantilla que lo provoca.
Guía técnica + servicio de implementación · Revisado el 16 de agosto de 2026
01 · Lo que suele fallar
El LCP puede llegar tarde incluso cuando el archivo es pequeño.
En WordPress, el elemento LCP suele ser una imagen hero, imagen destacada, encabezado o slider. El navegador solo puede renderizarlo después de que WordPress envíe HTML, el recurso sea descubierto, se resuelvan sus dependencias y el CSS o las animaciones permitan pintarlo.
02
Descubrimiento tardío de recursos
Las imágenes de fondo CSS, el marcado generado por sliders, las imágenes above-the-fold con lazy loading y los heroes inyectados por JavaScript pueden no ser descubribles en el HTML inicial.
03
Prioridad incorrecta
Una imagen crítica puede competir con fuentes, scripts e imágenes de menor valor si faltan o se usan mal los priority hints o preloads.
04
Tamaños responsive incorrectos
Servir una imagen de 2400 px a un viewport móvil estrecho desperdicia ancho de banda incluso en WebP/AVIF. Importan un srcset, sizes y dimensiones correctos.
05
CSS y fuentes que bloquean el renderizado
El recurso LCP puede terminar de descargarse y aun así esperar a CSS crítico, webfonts, layout o animaciones antes de poder pintarse.
06
Retraso por sliders o animaciones de entrada
Transiciones de opacidad, carruseles y reveals controlados por JavaScript pueden mantener oculto o inestable al candidato LCP final incluso cuando el recurso ya está listo.
02 · Diagnosticar antes de cambiar
Divide el LCP en las cuatro partes que muestra Google.
Mirar solo un resultado final de 3,8 s oculta la solución. Inspecciono el elemento LCP y sus fases de tiempo y sigo esos retrasos hasta decisiones de WordPress, tema o builder.
Elemento LCP por plantilla
El candidato puede cambiar entre home, landing, producto y artículo, así que la optimización sigue la familia de páginas que realmente falla en los datos de campo.
Desglose del TTFB
Comprueba el tiempo de origen/servidor/caché antes de dedicar horas a microoptimizaciones de frontend.
Cadena de descubrimiento
Uso DevTools para ver cuándo descubre el navegador el recurso LCP y qué dependencia de stylesheet o script retrasó ese descubrimiento.
Prioridad y preload
Verifica que preload/fetch priority se utilicen solo para recursos realmente críticos; demasiados recursos de alta prioridad compiten entre sí.
Peso de las imágenes responsive
Compara dimensiones intrínsecas, dimensiones renderizadas, selección srcset/sizes y formato de compresión en anchos móviles habituales.
Retraso de renderizado
Si la imagen termina de descargar pronto pero el LCP ocurre más tarde, reviso fuentes, CSS, animaciones, opacidad, sliders y tareas largas del main thread alrededor del paint.
03 · Implementation
Haz que el elemento LCP sea descubrible, prioritario y renderizable.
La implementación suele ser una cadena corta de cambios concretos. Los temas y constructores de WordPress a veces esconden el recurso crítico detrás de CSS o JavaScript; moverlo a la ruta HTML correcta puede importar más que otra ronda de compresión.
Identificar el candidato real
Capturo trazas de laboratorio y grupos de páginas con datos de campo para optimizar el elemento que realmente ven los usuarios en las plantillas que fallan.
Acortar la respuesta del servidor
Corrijo primero retrasos de caché/origen/backend cuando el TTFB consume una parte grande del presupuesto de LCP.
Exponer el recurso pronto
Usa marcado de imagen responsive cuando corresponda, evita lazy loading en el candidato visible above the fold y elimina dependencias innecesarias para descubrir el recurso.
Definir una prioridad sensata
Uso preload/fetchpriority con cuidado para el asset LCP real y evito que recursos de menor valor compitan durante la primera vista.
Eliminar el retraso de renderizado
Reduzco restricciones de CSS, fuentes y animaciones y me aseguro de que el candidato LCP pueda pintarse en cuanto esté listo.
Validar en producción
Vuelve a ejecutar trazas comparables después del despliegue y observa Search Console/CrUX mientras se acumulan nuevos datos de campo.
04 · Lo que realmente recibes
Una corrección de la métrica ligada a la ruta exacta de renderizado.
Obtienes el desglose temporal y la implementación que lo corrige, no consejos genéricos de «comprime imágenes / activa CDN».
01
Desglose del tiempo de LCP
TTFB, retraso de carga, duración de carga y retraso de renderizado para URLs representativas que fallan.
02
Corrección de la imagen principal
Carga responsive, prioridad y cambios de marcado para el elemento crítico cuando corresponda.
03
Cambios en tema o maquetador
Cambios a nivel de plantilla cuando fondos CSS, sliders o la salida del constructor provocan un descubrimiento tardío.
04
Limpieza de la ruta crítica
Cambios en CSS, fuentes y scripts que permiten renderizar antes el contenido LCP ya disponible.
05
Control de regresión
QA visual en móvil/escritorio y confirmación de que los cambios de lazy loading/prioridad no han perjudicado otras páginas.
06
Seguimiento con datos de campo
Explicación clara del retraso entre desplegar la corrección y ver un cambio en la evaluación móvil de datos de campo.
Si PageSpeed indica que Largest Contentful Paint es el problema, empieza por el elemento, no por una lista de plugins.
Para LCP junto con INP/CLS en varias plantillas, el servicio de Core Web Vitals es la opción global más adecuada.
FAQ
Preguntas que recibo antes de tocar producción.
¿Cuál es un buen LCP para WordPress?
Para Core Web Vitals, un buen Largest Contentful Paint es de 2,5 segundos o menos en el percentil 75. El objetivo son los datos de campo; las herramientas de laboratorio ayudan a reproducir y diagnosticar la causa.
¿Por qué mi LCP sigue alto después de comprimir imágenes?
La imagen puede descubrirse tarde, quedar bloqueada por CSS, esperar a un TTFB lento, recibir baja prioridad o retrasarse por animaciones/fuentes. LCP es todo el recorrido hasta pintar el elemento, no solo el tamaño del archivo.
¿Debo precargar la imagen LCP?
A veces. Preload o fetch priority pueden ayudar cuando el navegador descubriría tarde la imagen crítica, pero preloads innecesarios o duplicados compiten por ancho de banda. El waterfall debe justificar el cambio.
¿Una imagen de fondo CSS puede ser el elemento LCP?
Sí. Una imagen grande de fondo en el hero puede convertirse en candidato LCP, pero el descubrimiento mediante CSS puede llegar más tarde que una imagen presente en el HTML inicial. El marcado responsive de imagen puede mejorar descubrimiento y dimensionado.
¿El TTFB afecta al LCP?
Sí. El navegador no puede descubrir los recursos de la página hasta recibir suficiente HTML/CSS. Una respuesta lenta del servidor retrasa toda la línea temporal del LCP.
¿Cuánto tarda Search Console en mostrar la mejora?
Los datos de campo de Core Web Vitals se agregan durante un periodo móvil, por lo que no cambian inmediatamente después de un deploy. Usa trazas de laboratorio y monitorización de usuarios reales para validar de inmediato mientras los datos de campo se actualizan.