Optimiza el Element Render Delay del LCP

De descargado a mostrado: aprende cómo mejorar la parte de element render delay del Largest Contentful Paint.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-03
  1. Es
  2. Core Web Vitals
  3. Largest contentful paint
  4. Element render delay

Esta guía forma parte de la sección Largest Contentful Paint (LCP) de nuestro centro de recursos de Core Web Vitals. El Element Render Delay es la fase final en la línea temporal del LCP, representando el intervalo entre cuando el recurso LCP termina de descargarse y cuando se pinta visiblemente en la pantalla.

Optimiza el Element Render Delay del LCP

De las cuatro fases del LCP, el Element Render Delay es la más malinterpretada. Los equipos optimizan el TTFB, eliminan el Resource Load Delay y comprimen los recursos para acortar el Resource Load Duration. Ven que la cascada de red termina y asumen que el trabajo está hecho. Se equivocan.

El Element Render Delay es el tiempo desde que el recurso LCP termina de descargarse hasta que el elemento está completamente pintado en la pantalla del usuario. Esto no es un problema de red; es un problema del hilo principal. Un render delay alto significa que el navegador tiene la imagen o la fuente pero está demasiado ocupado con otras tareas para realmente dibujarla. Este retraso es un impuesto directo a tu puntuación LCP, a veces añadiendo 200ms o más después de que todas las solicitudes de red se hayan completado.

Definición precisa: el problema de la última milla

El Element Render Delay comienza en el momento en que el último byte del recurso LCP (por ejemplo, un archivo de imagen o una fuente web) llega al navegador. Termina cuando el elemento LCP está visiblemente pintado en la pantalla. Es, literalmente, el paso final.

Para elementos LCP basados en texto que usan una fuente del sistema, este retraso suele ser cero, ya que no se necesita ningún recurso externo. Sin embargo, para la gran mayoría de sitios donde el elemento LCP es una imagen o usa una fuente web personalizada, esta fase es a menudo el mayor cuello de botella. El navegador dedica este tiempo a tareas vinculadas a la CPU: traducir bits descargados en píxeles visibles.

El 'por qué': una cadena de montaje atascada

Para solucionar el render delay, debes entender cómo un navegador dibuja una página. Es un proceso de múltiples etapas que a menudo se llama la Ruta de Renderizado Crítica. Piensa en ello como una cadena de montaje de una fábrica:

  1. Construir los planos (DOM y CSSOM): El navegador analiza el HTML para construir el Document Object Model (DOM) y el CSS para construir el CSS Object Model (CSSOM). Estos son los planos para el contenido de la página y su estilo.
  2. Combinar planos (Render Tree): El DOM y el CSSOM se combinan en un Render Tree, que contiene solo los nodos necesarios para renderizar la página. Elementos como <head> o aquellos con display: none; se omiten.
  3. Calcular geometría (Layout): El navegador calcula el tamaño y la posición exactos de cada elemento en el render tree. Esta etapa también se conoce como "reflow".
  4. Colorear los píxeles (Paint): El navegador rellena los píxeles de cada elemento, considerando texto, colores, imágenes, bordes y sombras.
  5. Ensamblar capas (Composite): La página se dibuja en diferentes capas, que luego se ensamblan en el orden correcto para crear la imagen final de la pantalla.

El Element Render Delay es el tiempo consumido por estas etapas finales: Layout, Paint y Composite. Toda esta cadena de montaje es ejecutada por un solo trabajador: el hilo principal. Si ese trabajador está ocupado ejecutando una tarea larga de JavaScript o analizando un archivo CSS masivo, la cadena de montaje se detiene. La imagen LCP puede haber llegado, pero está esperando en el muelle de carga a que el hilo principal se libere para procesarla y pintarla.

Cómo identificar el Element Render Delay

Diagnosticar este problema sigue un proceso estricto de dos pasos. No te saltes el primer paso.

Paso 1: Validar con datos de campo (RUM)
Antes de abrir DevTools, debes confirmar que el Element Render Delay es un problema real para tus usuarios reales. Una herramienta profesional de Real User Monitoring (RUM) como la mía, CoreDash, es esencial. Desglosará el LCP de tu sitio en sus cuatro subpartes. Si tus datos RUM muestran un Element Render Delay significativo en el percentil 75, tienes un problema validado y de alto impacto que resolver.

Paso 2: Diagnosticar con DevTools
Una vez que el RUM ha identificado las páginas problemáticas, usa el panel Performance de Chrome DevTools para analizar la causa.

  1. Ve a la pestaña Performance y activa la casilla "Web Vitals".
  2. Haz clic en el botón "Record and reload page".
  3. En la pista "Timings", haz clic en el marcador de LCP. La pestaña "Summary" debajo mostrará la duración precisa de cada una de las cuatro fases del LCP. Anota el valor del Element render delay.
  4. Ahora, examina la pista Main en la línea temporal. Busca tareas largas (bloques amarillos con esquinas rojas) que ocurran entre el final de la solicitud de red del recurso LCP y el marcador de tiempo del LCP. Estas tareas son la causa directa de tu retraso. Pasa el cursor sobre ellas para identificar los scripts responsables.

Causas comunes y soluciones de alto impacto

Un Element Render Delay alto casi siempre es causado por un hilo principal bloqueado.

Causa: CSS que bloquea el renderizado

El problema: Por defecto, el CSS bloquea el renderizado. El navegador no pintará ningún píxel hasta que haya descargado y analizado todos los archivos CSS enlazados en el <head>. Una hoja de estilos grande y compleja puede ocupar el hilo principal durante cientos de milisegundos, retrasando el inicio de las etapas de layout y paint. Esto se agrava cuando los sitios cargan múltiples hojas de estilos, cada una requiriendo una solicitud de red y un ciclo de análisis separados. Para estrategias detalladas sobre cómo reducir la carga de CSS, consulta nuestra guía sobre eliminar CSS no utilizado.

La solución: Haz que tu CSS sea pequeño, limpio y cacheable.

  • Eliminar CSS no utilizado: Esta es la optimización de mayor impacto. En sitios grandes, el CSS no utilizado puede representar el 70% o más del tamaño total de la hoja de estilos. Herramientas como PurgeCSS pueden escanear tu HTML y JavaScript para identificar selectores no utilizados. Eliminar reglas muertas reduce tanto el tiempo de descarga como el tiempo de análisis en el hilo principal.
  • Apunta a hojas de estilos pequeñas y cacheables: El punto óptimo para un archivo CSS es aproximadamente 10-15kB (comprimido). Más pequeño que eso y corres el riesgo de dividir en demasiadas solicitudes paralelas, cada una con su propia sobrecarga de conexión. Más grande que eso y el tiempo de bloqueo crece, especialmente en redes móviles lentas. Una hoja de estilos única y bien estructurada en ese rango se descarga rápido, se analiza rápido y el navegador la cachea para visitas repetidas.
  • Solo inline CSS como último recurso: Insertar CSS crítico en un bloque <style> elimina la solicitud de red para la primera carga de página, pero tiene un coste: el CSS inline no puede ser cacheado por el navegador. Cada visitante recurrente lo vuelve a descargar con cada página. Para la mayoría de los sitios con usuarios que regresan, una pequeña hoja de estilos externa que el navegador cachea es la mejor opción. El inline solo tiene sentido para landing pages con muy pocos visitantes recurrentes.

Cuantificar el impacto del CSS: Para medir cuánto contribuye tu CSS al render delay, abre la pestaña Coverage de Chrome DevTools (Ctrl+Shift+P, luego escribe "Coverage"). Carga la página y observa el porcentaje de bytes no utilizados en tus archivos CSS. Un porcentaje alto de CSS no utilizado es una señal clara de que la limpieza reducirá el Element Render Delay.

Causa: tareas largas de JavaScript

El problema: Esta es la causa más común. La ejecución pesada de JavaScript, ya sea de frameworks, scripts de analytics, herramientas de test A/B o código mal optimizado, puede monopolizar el hilo principal. Una sola tarea de larga ejecución puede bloquear el renderizado durante cientos de milisegundos, añadiéndose directamente al Element Render Delay. Google define una tarea larga como cualquier tarea que dure más de 50ms, y las tareas que superan los 200ms se consideran críticamente largas. Para una colección completa de estrategias de aplazamiento de JavaScript, consulta nuestro artículo sobre 14 métodos para diferir JavaScript.

La solución: Dividir el trabajo.

  • Ceder el hilo principal: Las tareas largas deben dividirse en fragmentos más pequeños. Esto se puede hacer cediendo el control al navegador periódicamente usando setTimeout(..., 0) o la más nueva API scheduler.yield(). Esto permite al navegador realizar actualizaciones de renderizado entre tareas.
  • Optimizar y diferir scripts de terceros: Audita cada script de terceros. Si no son esenciales para el renderizado inicial, cárgalos con el atributo defer o inyéctalos después de que la página se haya cargado. Los scripts de tests A/B son particularmente problemáticos ya que a menudo bloquean el renderizado por diseño.
  • Usa requestAnimationFrame para actualizaciones visuales: Si JavaScript debe realizar manipulación del DOM durante la carga de la página, envuelve el trabajo en requestAnimationFrame. Esto programa el trabajo para ejecutarse justo antes del siguiente paint, asegurando que el navegador tenga la oportunidad de renderizar frames entre operaciones de JavaScript.

Identificar tareas largas en DevTools

En el panel Performance de Chrome DevTools, las tareas largas aparecen como bloques amarillos con un triángulo rojo en la esquina superior derecha en la pista "Main". Para identificar qué scripts son responsables:

  1. Graba una carga de página en el panel Performance.
  2. Localiza el marcador LCP en la pista Timings.
  3. Examina la pista Main buscando tareas largas que ocurran entre la finalización de la solicitud de red del recurso LCP y el marcador LCP.
  4. Haz clic en estas tareas para ver la pila de llamadas en el panel Summary. La pila de llamadas revelará el archivo fuente y la función responsable de la tarea larga.

Scripts de terceros problemáticos comunes

Basándose en experiencia de consultoría real, los scripts de terceros más comunes que causan Element Render Delay incluyen:

  • Herramientas de test A/B (Optimizely, VWO, AB Tasty): Estas a menudo bloquean el renderizado intencionalmente para prevenir el parpadeo de contenido entre variantes. Mover la decisión del experimento al lado del servidor (test del lado del servidor) elimina este problema por completo.
  • Gestores de etiquetas con tags síncronos: Un gestor de etiquetas configurado con tags síncronos (no asíncronos) puede inyectar scripts que bloquean el renderizado. Audita tu contenedor para asegurarte de que todos los tags estén configurados para dispararse después de DOM ready o window load.
  • Plataformas de gestión de consentimiento: Los banners de consentimiento de cookies que bloquean el renderizado hasta que se toma una decisión pueden retrasar el LCP. Usa una implementación asíncrona que no bloquee la ruta de renderizado crítica.
  • Widgets de chat: Los scripts de chat en vivo a menudo ejecutan código de inicialización pesado durante la carga de la página. Difiere la carga hasta después de que la página sea interactiva, o cárgalos con la interacción del usuario (por ejemplo, clic).

Causa: Renderizado del lado del cliente (CSR)

El problema: Con el renderizado puramente del lado del cliente, el elemento LCP a menudo no existe en el HTML inicial. JavaScript debe ejecutarse primero para construir el DOM, insertar el elemento LCP, y entonces el navegador puede finalmente renderizarlo. Todo este proceso es un gran render delay.

La solución: Renderizar en el servidor. No hay otra forma. Usa Server-Side Rendering (SSR) o Static Site Generation (SSG) para asegurar que el elemento LCP esté presente en el documento HTML inicial enviado desde el servidor. Esto elimina toda la fase de renderizado impulsada por JavaScript como fuente de retraso.

Causa: contenido oculto por otro código

El problema: A veces el elemento LCP está en el DOM pero está oculto por CSS (por ejemplo, opacity: 0) o por un script, como una animación de "revelar al hacer scroll" o una herramienta de test A/B que todavía está decidiendo qué variante mostrar. El elemento está descargado y listo, pero no puede ser pintado porque aún no es visible.

La solución: Asegura la visibilidad inmediata. Para el elemento LCP, no uses animaciones de entrada ni ninguna lógica que lo oculte en la carga inicial. El elemento debe estar visible en el DOM y estilizado para ser visible desde el primer paint. Configura las herramientas de test A/B para ejecutarse de forma asíncrona o asegúrate de que tengan un impacto mínimo en la visibilidad del elemento LCP.

Causa: tamaño excesivo del DOM

El problema: Un DOM grande (más de 1.500 nodos) aumenta el coste de cada operación de renderizado. Cada cálculo de layout, recálculo de estilos y operación de paint debe procesar más nodos, lo que toma más tiempo en el hilo principal. Incluso si tu CSS y JavaScript están bien optimizados, un DOM inflado añade render delay por puro volumen. Para estrategias detalladas para reducir el tamaño del DOM, consulta nuestra guía sobre evitar un tamaño excesivo del DOM.

La solución: Reducir el número de nodos del DOM que participan en el renderizado inicial.

  • Simplificar la estructura HTML: Elimina elementos contenedores innecesarios. Aplana estructuras profundamente anidadas. Usa CSS Grid o Flexbox en lugar de elementos <div> extra para el layout.
  • Virtualizar listas largas: Para páginas con cientos de elementos de lista (cuadrículas de productos, tablas de datos), usa bibliotecas de virtualización que solo rendericen los elementos actualmente visibles en el viewport.
  • Renderizado diferido del contenido debajo del pliegue: Usa content-visibility: auto (cubierto a continuación) para omitir por completo el renderizado de secciones fuera de la pantalla.

Tácticas avanzadas: tomar control total del renderizado

Las aplicaciones complejas necesitan más control sobre el hilo principal.

Desbloquear rendimiento con content-visibility

La propiedad CSS content-visibility está diseñada para páginas grandes. Al establecer content-visibility: auto; en secciones de tu página que están debajo del pliegue, estás indicando al navegador que puede omitir el trabajo de layout, paint y composite para ese contenido hasta que esté a punto de entrar en el viewport. Esto reduce la carga de trabajo de renderizado inicial, liberando el hilo principal para pintar el elemento LCP antes.

La clave es combinar content-visibility: auto con contain-intrinsic-size, que proporciona un tamaño de marcador de posición para el contenido oculto. Sin esto, el comportamiento de la barra de desplazamiento se vuelve errático porque el navegador no sabe cuán altas son las secciones ocultas.

/* Apply to below-the-fold sections */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px; /* Estimated height of the section */
}

/* Example: A long article page */
.article-comments {
  content-visibility: auto;
  contain-intrinsic-size: auto 800px;
}

.related-products {
  content-visibility: auto;
  contain-intrinsic-size: auto 600px;
}

.site-footer {
  content-visibility: auto;
  contain-intrinsic-size: auto 300px;
}

Impacto en el rendimiento: Según una publicación del blog de Chrome Developers, aplicar content-visibility: auto a secciones debajo del pliegue de una página de blog redujo el tiempo de renderizado hasta 7x. El navegador omite por completo el trabajo de layout, paint y composite para estas secciones, liberando el hilo principal para concentrarse en el contenido por encima del pliegue, incluido el elemento LCP. La compatibilidad de navegadores cubre todos los navegadores modernos: Chromium, Firefox y Safari 18+.

Descargar trabajo con Web Workers

Los Web Workers te permiten ejecutar JavaScript en un hilo en segundo plano, completamente fuera del hilo principal. Cualquier computación pesada que se ejecute en un Worker no puede bloquear el renderizado. Este sitio, corewebvitals.io, usa un Web Worker para su procesamiento de analytics, y el beneficio de rendimiento es real: el hilo principal se mantiene libre para pintar sin interrupciones.

Dicho esto, los Web Workers no son un patrón común en la mayoría de los sitios web. Requieren un archivo JavaScript separado, comunicación a través de postMessage, y no tienen acceso al DOM. La mayoría de las plataformas CMS y constructores de sitios no ofrecen soporte integrado para ellos, lo que dificulta la implementación sin desarrollo personalizado. Si tienes la capacidad técnica para usarlos, son una de las formas más efectivas de mantener el hilo principal libre. Pero para la mayoría de los equipos, las otras optimizaciones de esta página tendrán un mayor impacto práctico.

// main.js: Create a worker and send data for processing
const worker = new Worker('/js/analytics-worker.js');

// Offload heavy analytics processing to the worker thread
worker.postMessage({
  type: 'process-events',
  events: collectedEvents
});

// Receive results without blocking the main thread
worker.onmessage = (event) => {
  console.log('Analytics processed:', event.data.summary);
};

// analytics-worker.js: Runs in a background thread
self.onmessage = (event) => {
  if (event.data.type === 'process-events') {
    // Heavy computation happens here, off the main thread
    const summary = processEvents(event.data.events);
    self.postMessage({ summary });
  }
};

Impacto en el mundo real

  • Caso 1: El cuello de botella del CSS que bloquea el renderizado: DebugBear analizó un sitio donde un archivo CSS grande creaba un render delay notable. La imagen LCP estaba descargada, pero el navegador estaba atascado analizando CSS. Simplemente insertando CSS crítico inline, el navegador pudo pintar el contenido de la página, incluido el elemento LCP, casi inmediatamente después de que se analizara el HTML, eliminando efectivamente el render delay causado por la hoja de estilos.
  • Caso 2: La penalización del test A/B: Un importante sitio de comercio electrónico descubrió que su LCP estaba siendo frenado por un script síncrono de test A/B. Aunque la imagen LCP se descargó rápidamente, el script bloqueaba el hilo principal mientras determinaba qué imagen de producto mostrar. Mover el test A/B para ejecutarse después de la carga inicial de la página para elementos no críticos mejoró inmediatamente su LCP en más de 400ms, todo recuperado del Element Render Delay.

Checklist: cómo eliminar el Element Render Delay

Un Element Render Delay alto indica un hilo principal congestionado. Las soluciones implican despejar esa congestión para que el navegador pueda pintar.

  1. Validar con RUM: Usa datos de usuarios reales para confirmar que el Element Render Delay es tu principal cuello de botella de LCP antes de empezar a optimizar.
  2. Eliminar CSS no utilizado: Audita y elimina reglas CSS que nunca se aplican. Esta es la optimización de CSS de mayor impacto. Usa herramientas como PurgeCSS o la pestaña Coverage en DevTools.
  3. Mantener hojas de estilos pequeñas y cacheables: Apunta a aproximadamente 10-15kB (comprimido) por archivo CSS. Lo suficientemente pequeño para descargarse rápido, lo suficientemente grande para evitar solicitudes paralelas excesivas. Deja que el navegador las cachee para visitantes recurrentes.
  4. Dividir tareas largas de JavaScript: Ningún script debería ejecutarse durante más de 50ms. Cede el hilo principal para permitir actualizaciones de renderizado.
  5. Auditar y diferir scripts de terceros: Pregúntate: ¿cada script de terceros merece su lugar en la página? Difiere todo lo que no sea esencial para el paint inicial.
  6. Usar SSR o SSG: No dependas del JavaScript del lado del cliente para renderizar tu elemento LCP. Envía HTML completamente formado desde el servidor.
  7. Asegurar visibilidad inmediata del LCP: Elimina cualquier animación, script o estilo que oculte el elemento LCP en la carga de la página.
  8. Usar content-visibility: auto: Para páginas largas, indica al navegador que omita el renderizado del contenido fuera de la pantalla para liberar el hilo principal para el pintado por encima del pliegue.
  9. Reducir el tamaño del DOM: Aplana HTML profundamente anidado, elimina contenedores innecesarios y virtualiza listas largas para reducir el coste de las operaciones de layout y paint.

Próximos pasos: continuar optimizando LCP

El Element Render Delay es la fase final. Para cubrir las cuatro, continúa con:

  • Encontrar y solucionar problemas de LCP: La metodología de diagnóstico completa para encontrar y solucionar todos los problemas de LCP usando datos de campo y herramientas de laboratorio.
  • Optimizar la imagen LCP: Selección de formato de imagen, imágenes responsivas, preloading y errores comunes de optimización de imágenes.
  • Resource Load Delay: Asegura que el navegador descubra el recurso LCP lo antes posible. Este es a menudo el mayor cuello de botella individual del LCP.
  • Resource Load Duration: Reduce el tiempo de descarga mediante compresión, formatos modernos, configuración de CDN y optimización de red.

The RUM tool I built for my own clients.

CoreDash is what I use to audit enterprise platforms. Under 1KB tracking script, EU hosted, no consent banner. AI with MCP support built in. The same tool, available to everyone.

Create Free Account
Optimiza el Element Render Delay del LCPCore Web Vitals Optimiza el Element Render Delay del LCP