Dimensión de Core/Dash: Tipo de elemento (LCP)
Corrige el Largest Contentful Paint filtrando el tráfico según el tipo de elemento arquitectónico.
Trusted by market leaders · Client results
Dimensión: Recurso: Tipo de elemento LCP (lcpet)
La dimensión de Tipo de elemento (LCP) (lcpet) clasifica el nodo del Largest Contentful Paint en una de cuatro clases arquitectónicas: text, image, background-image o video.
Mientras que la dimensión Attribution Element identifica el nodo exacto del DOM, la dimensión de Tipo de elemento dicta tu estrategia de ingeniería de alto nivel. El LCP es la suma de cuatro intervalos de tiempo: TTFB, Load Delay, Load Time y Render Delay. El Tipo de elemento te indica cuál de estos intervalos está perjudicando tu puntuación, permitiéndote seleccionar el protocolo de optimización correcto sin tener que adivinar.
Optimizando las Core Web Vitals por tipo de elemento LCP
Después de mejorar el TTFB, que es independiente del tipo de elemento LCP, debes adoptar un enfoque diferente para optimizar el LCP observando tu tipo de elemento LCP.
1. Texto
Cuando CoreDash informa que el texto es el Tipo de elemento, el ancho de banda de los recursos estáticos de la red rara vez es el cuello de botella. El texto reside directamente en el documento HTML, lo que significa que el contenido está disponible inmediatamente después de la respuesta inicial del servidor (TTFB). Si tu LCP es lento aquí, el problema es casi exclusivamente el Render Delay.
Para solucionar esto, concéntrate por completo en el Critical Rendering Path. Es probable que cálculos pesados de CSS o JavaScript síncrono en el <head> estén bloqueando al navegador e impidiendo que pinte el texto. Además, revisa tu estrategia de carga de fuentes; si no estás utilizando font-display: swap u optional, el navegador oculta artificialmente el texto (FOIT) mientras espera a que se descargue el archivo de la fuente.
2. Imagen (<img>)
Este tipo desencadena todo el canal de procesamiento de recursos: descubrimiento, descarga y decodificación. A diferencia del texto, un LCP de imagen depende en gran medida del Load Delay y del Load Time. Aquí estás luchando contra la física y la latencia de la red, por lo que tu objetivo es hacer que el activo sea más ligero y se pueda descubrir antes.
La optimización aquí requiere una gestión estricta de los activos. Asegúrate de que la etiqueta <img> exista en el código fuente HTML inicial (Server-Side Rendering) para minimizar el Load Delay. Añade fetchpriority="high" y elimina estrictamente cualquier atributo loading="lazy", ya que estos retrasan la solicitud del navegador. Por último, aborda el Load Time sirviendo formatos de próxima generación (AVIF/WebP) y utilizando srcset para evitar que los dispositivos móviles descarguen archivos del tamaño de un escritorio.
3. Imagen de fondo
Esta clasificación señala una ineficiencia arquitectónica. Debido a que la imagen se define en el CSS (por ejemplo, background-image: url(...)), el navegador no puede descubrir la URL hasta que haya descargado y analizado completamente tus hojas de estilo. Esto crea un Load Delay masivo porque el Preload Scanner es efectivamente ciego ante el activo.
La única solución de ingeniería sólida es la refactorización. Mueve el activo visual del CSS a una etiqueta <img> estándar en el HTML para exponer la URL al navegador de inmediato. Si no puedes refactorizar el marcado, debes usar <link rel="preload"> en el head del documento para forzar un descubrimiento temprano, aunque esto a menudo supone una carga de mantenimiento en comparación con el uso de un elemento de imagen nativo.
4. Video
Cuando el elemento LCP es un video, el navegador mide el tiempo de renderizado de la imagen del póster o del primer fotograma (si se reproduce automáticamente). Esto se comporta de manera similar al tipo de imagen, pero a menudo es más pesado debido al tamaño del archivo de los activos de video.
Trata esto estrictamente como una tarea de optimización de imágenes. Asegúrate de que haya un atributo de póster ligero presente en el HTML para que el navegador no tenga que descargar segmentos de video para renderizar el primer píxel. Comprime la imagen del póster de manera tan agresiva como lo harías con una imagen LCP estándar.
Flujo de trabajo: encontrar problemas de LCP basados en el tipo de elemento LCP
El Tipo de elemento LCP no es estático ni es el mismo para cada visitante. Con frecuencia cambia según el dispositivo del usuario, revelando fallas fundamentales en el diseño responsivo.
Utiliza el filtro Device Form Factor de CoreDash para comparar los Tipos de elementos entre Mobile y Desktop. A menudo descubrirás que los usuarios de escritorio obtienen un LCP de imagen (por ejemplo, un Hero Banner), mientras que los usuarios móviles obtienen un LCP de texto. Esto confirma que tu diseño CSS para móviles empuja el Hero Banner por debajo del pliegue o lo reduce tan significativamente que un párrafo de texto se convierte en el elemento más grande.
Si estás optimizando la imagen hero para mejorar el LCP móvil en este escenario, estás desperdiciando esfuerzo. El navegador ni siquiera está contando la imagen. Debes ajustar el diseño para que la imagen vuelva a la vista principal, o bien cambiar tu enfoque a optimizar el renderizado del texto (fuentes/CSS) para los usuarios móviles.
