Largest Content Painful que en español significa “La pintura de contenido más grande” o LCP por sus siglas en inglés, es el tiempo de representación del contenido principal y más grande que ve el usuario en la página web.
LCP es una de las métricas fundamentales de Web Vitals que lanzan los desarrolladores de Google Chrome para medir la «experiencia del usuario» según las métricas de velocidad de página.
El Largest Content Painful o LCP es muy importante para ver en cuánto tiempo se renderiza en el navegador el componente más importante o más grande de la página web para que los usuarios puedan interactuar con la web. La buena carga de LCP puede aumentar la tasa de conversión y la satisfacción del usuario.
El LCP está directamente relacionado con algunas de las métricas de velocidad de página más conocidas:
- First Contentful Paint
- First Paint
- First Meaningful Paint
- First Significant Paint
- Time to First Byte
- Speed Index
A excepción de First Meaningful Paint y First Significant Paint, los desarrolladores de Lighthouse, Pagespeed Insights y Google Chrome siguen utilizando el resto de ellas.
La métrica Largest Contentful Paint o LCP, ha tomado el puesto de First Meaningful Paint y First Significant Paint. First Significant Paint se calculaba cuándo se descargaba el primer componente significativo de la página mientras que First meaningful Paint se calculaba cuánto tiempo tarda el renderizado del primer componente importante de la página web.
Largest Contentful Paint ha incluido ambas métricas para una mejor forma de mejorar la velocidad de la página centrada en la experiencia usuario.
Dado que, calcular First meaningful Paint y First Significant Paint como métricas separadas era muy difícil de usar para una mejor experiencia del usuario, Largest Contentful Paint comenzó a usarse después del lanzamiento de Core Web Vitals.
Tabla de Contenidos
¿Qué es un buen tiempo de LCP?
Según el propio Google en su documentación especifica lo siguiente:
- Un buen tiempo de LCP está por debajo de los 2,5 segundos (verde).
- Entre 2,5 segundos y 4,0 segundos (amarillo) significa que LCP debe mejorarse.
- Si dura más de 4.0 segundos (rojo), significa que la pintura con contenido más grande es deficiente.
La medición de LCP desde un dispositivo diferente y tipos de conexión puede ayudarnos a los SEO y desarrolladores a comprender qué perfil de usuario debe tener qué tipo de experiencia LCP en el sitio web.
El uso de Dynamic Serving y Network Information API puede ayudar a optimizar el dispositivo y el tipo de conexión en este contexto. Si el 75% o más del 75% de los usuarios tienen una sincronización LCP por debajo de los 2,5 segundos, significa que la puntuación LCP es buena en general.
Decir esto suena fácil pero llevarlo a la realidad es una tarea fuerte y de mucha investigación, ya que no todos las páginas son iguales y como SEO, WPO o desarrolladores debemos trabajar con códigos de terceros mal optimizados.
¿Qué elementos de la página web se consideran en el LCP?
Los elementos de la página web que se consideran en la pintura de contenido más grande son los siguientes.
- Elementos de imagen.
- Elementos de imagen en una etiqueta <svg>.
- Elementos de texto, ya sea «bloque» o «en línea».
- Elementos de imagen con propiedad de fondo CSS.
Los elementos que se miden en el LCP están limitados para simplificar el cálculo. En el futuro, los desarrolladores de Google Chrome piensan en agregar elementos «svg» y «video» también.
¿Cómo se puede saber qué es un elemento LCP de acuerdo con Web Core Vitals?
La etiqueta <div> o el elemento de la página web que contiene el elemento más grande se mide de acuerdo con su área «visible» para los usuarios. Si un componente de la página web tiene un área más amplia que la ventana gráfica o algunas de las partes del componente de la página web están «ocultas» o «no visibles», esta parte oculta no se cuenta en el LCP.
¿Cómo se mide el LCP para los elementos de imagen en la página web?
Como se mencionó anteriormente, el tamaño del elemento LCP se percibe y mide de acuerdo con su tamaño visible para los usuarios.
Para las imágenes redimensionadas, el tamaño más pequeño de la imagen entre el tamaño intrínseco o el tamaño redimensionado se contará para el LCP.
Si se estira una imagen, se contará el tamaño intrínseco. Si una imagen se reduce de acuerdo con su tamaño intrínseco, se contará el tamaño reducido.
¿Cómo se percibe Largest Content Painful para los elementos de texto en la página web?
Para el LCP de los nodos HTML que contienen «elementos de texto», se mide el tamaño del elemento de texto.
Significa que el rectángulo más pequeño posible que envuelve el área de los elementos de texto se medirá y comparará para el LCP.
Para comprender qué elemento de texto pertenece a qué elemento, los desarrolladores de Chrome utilizan el «elemento de nivel de bloque más cercano».
Significa que si hay un texto, ya sea un texto sin formato, un párrafo o un texto en línea, se contará como el texto del elemento ancestro de nivel de bloque más cercano.
Para todos los componentes de la página web, los bordes CSS, los márgenes y los rellenos no se cuentan para la medición LCP.
Tiempo de generación mayor del LCP en el navegador
El navegador puede percibir el LCP como diferente, ya que la página web se descarga y representa en fases.
Para resolver este problema, el navegador utiliza «Performance Entry» con el tipo de «Largest Content Painful».
Siempre que el navegador muestra un nuevo elemento de página, se actualiza la Performance Entry con el tipo de «pintura de contenido más grande».
Por lo tanto, en el primer segundo del proceso de representación de la página, una imagen pequeña puede ser el elemento de contenido más grande, pero más tarde, si hay un elemento más grande en la pantalla, el contenido más grande cambiará inmediatamente.
Por ejemplo, al comienzo de la carga de la página web, un elemento de texto puede ser el LCP. Después de descargar un botón con el CTA y el Heading 1 (H1), se puede cambiar el LCP. Una vez finalizada la descarga de la imagen de fondo, el LCP volverá a cambiar. La pintura de contenido más grande se percibirá de acuerdo con el contenido del «nodo HTML contenedor». Si todo este contenido está en el mismo «nodo HTML» (si todos tienen el mismo nodo HTML principal), entonces todos estarán en la pintura de contenido más grande.
Si los elementos de la página web están en diferentes nodos HTML, entonces el LCP se elegirá de acuerdo con el tamaño visible total de estos diferentes elementos del nodo HTML.
El uso de HTML semántico y la estructura de código HTML más limpia pueden ayudar a los algoritmos de Google y a los sistemas de medición de velocidad de página de Chrome a identificar el LCP más fácilmente.
Imagínese, LCP es la «ventana emergente» en la página web o un fragmento de texto pequeño y no importante.
En realidad, esto puede crear un informe de experiencia de usuario de Chrome no eficiente, confundir los algoritmos de Google y disminuir la eficiencia de las herramientas de velocidad de página.
En la página web el LCP debe incluir el contenido principal y el propósito de la página web.
Claramente, debe indicar el contexto y la función de la página web mientras satisface la intención principal de la visita de los usuarios.
Los algoritmos del motor de búsqueda de Google también pueden usar LCP para comprender el propósito de la página web, por eso es importante tener un LCP claro en la experiencia de carga de la página web.
¿Cómo determina el navegador el LCP durante el proceso de carga de la página web?
A continuación, explicaré con el mayor detalle posible la medición y optimización del LCP.
- Si un componente web permanece el tiempo suficiente visible en la página durante la carga, puede percibirse como el LCP a pesar de que hay otro componente de la página web que es más grande y se descarga más tarde.
- A pesar de que un nodo HTML tiene el contenido más grande en la página web, es posible que aún no sea el LCP. Si hay dos nodos HTML que tienen tamaños visibles similares, el nodo HTML con los elementos más grandes y más pequeños se elegirá como LCP. Imagine que hay dos nodos HTML, uno tiene una imagen grande y el otro tiene dos imágenes pequeñas diferentes, en este contexto, el nodo HTML con la imagen más grande se percibirá como LCP.
- Después de Chrome 86, los nodos HTML con opacidad 0 no se contarán en la medición LCP.
- Después de que el usuario haya realizado la primera interacción con la página web, la medición LCP se detendrá. En este contexto, podemos decir que LCP refleja el propósito principal de la página web.
- Los navegadores siempre cambian el LCP cada vez que los nuevos elementos de la página web se vuelven visibles, porque si una página web tiene una “pantalla de presentación” o una “fase de carga visualmente”, la página web no se puede percibir e interpretar cómo debería ser.
- Si hay un marcador de posición para la imagen (slider o carrusel), el navegador notará el tiempo borrado del marcador de posición y cambiará el LCP con la imagen que sigue.
- Si hay imágenes de «cross-origin» sin el encabezado «Timing-Allow-Origin», no se puede medir el LCP para estos elementos de la página web.
- Para mantener un mejor rendimiento del cálculo y la medición de LCP, solo se cuenta el «tamaño visible inicial». Significa que cualquier cambio en el tamaño o la posición del elemento después de que sea visible no afectará al LCP.
- Si se elimina un elemento de la página web durante la fase de carga, también se eliminará del LCP. Esta sección es especialmente importante para los «Carruseles de imágenes».
¿Cómo medir el Largest Content Painful?
Para medir el LCP, se pueden utilizar los métodos y herramientas siguientes.
- Pagespeed Insights: en el informe podemos encontrar el item donde nos señala que parte de nuestro HTML es considerado el LCP.
- Lighthouse: desde la extensión de Google Chrome que se activa con F12+Run Report, podemos ver el ítem desde el navegador.
- GTMetrix: esta excelente herramienta hace poco se actualizó y añadió las web vitals a su informe de rendimiento.
- Webpagetest
- Chrome Experience Report
¿Cuáles son las principales razones de un mal tiempo LCP?
Estas son algunas de las razones por la cual podemos tener una mala puntuación de LCP:
- Slow Response Time: Tiempo de respuesta lento, producido por un servidor de bajo rendimiento o por la razones mencionadas a continuación.
- Render Blocking CSS: el mal uso de librerías y “Dirty CSS” pueden bloquear el renderizado del LCP de la página.
- Render Blocking Javascript: el abuso de librerías externas y funciones propias al inicio de la carga de la página pueden bloquear el LCP de la página.
- Client-side Rendering: el mal renderizado del lado del cliente también es otro factor que debemos tomar en cuenta.
- Unoptimized and Uncleaned CSS and JS Files: la falta de minificación de códigos CSS y JS hace que el tiempo de carga se vea comprometido.
- Non-visible Fonts During Page Loading: el uso de fuentes llamadas desde el archivo principal CSS desde recursos externos sin una especificación de carga (<link rel=preload>) pueden afectar negativamente.
- Unoptimized Images: el mal uso de imágenes sobredimensionadas y muy pesadas es un error muy frecuente y que afecta directamente al PageSpeed de toda página.
- Unoptimized Resource Load Order: cuando no indicamos el orden de carga de los recursos más importantes de la página con los atributos como async, defer y preload puede impactar negativamente en la velocidad de carga.
Estos puntos son importantes para todas las métricas de rendimiento de una página web. En el contexto de LCP.
¿Cómo optimizar el LCP?
Un tiempo lento hasta el primer byte disminuirá el rendimiento general del sitio web. Un servidor lento creará una ralentización general, pero es más crítico para Largest Content painful.
Debido al tiempo de respuesta lento, es posible que el navegador no interprete el LCP correctamente, ya que algunos de los componentes de la página web permanecen más tiempo del que deberían en la pantalla.
Para aumentar el TTFB (Time To First Byte) y ayudar a la mejora del LCP, es posible implementar algunos de los siguientes métodos.
- Optimice la infraestructura del servidor con las tecnologías back-end, se puede considerar el uso de servidores LiteSpeed que gracias a su tecnología pueden ser de gran ayuda para mejorar la carga del LCP.
- Compresión Brotli o Gzip en el servidor, es muy importante que tomen en cuenta estas tecnologías cuando estén investigando servicios de hosting, los cuales deben ofrecer como mínimo cualquiera de estas 2 opciones.
- Habilitar HTTP 2 Server Push para los activos críticos y disminuir el TTFB para estos recursos.
- Almacene en caché los activos necesarios para la página web. En el caso de WordPress existen muchas opciones de plugins de cache como WP Rocket y LiteSpeed Cache para servidores LiteSpeed.
- Uso de una Red de Entrega de Contenido o CDN como CloudFlare puede ser de gran ayuda.
- Cambiar de HTTP 1 a HTTP 2.
La configuración del servidor y el uso de una estructura de consulta más simple en segundo plano, afectarán directamente el tiempo de respuesta y el LCP.
Vamos a profundizar un poco más en los siguientes puntos.
1.Optimización de los servidores web para un mejor LCP
Cada infraestructura de servidor web tiene sus propios términos, métodos y pautas para mejorar el rendimiento de la página web.
Si el servidor web no es compatible o no tiene la tecnología de compresión “Brotli” o “Gzip”, o no sirve los encabezados de respuesta que son necesarios para el almacenamiento en caché, también disminuirá la velocidad de carga de la página web.
Para optimizar la infraestructura del servidor, es importante utilizar consultas más simples en segundo plano.
Además, el uso de una tecnología de renderización del lado del servidor (Server-Side-Rendering o SSR) junto con una caché del lado del servidor puede reducir el tiempo de respuesta.
Cada activo de la página web se llama desde el servidor durante la «creación de la conexión».
Debido a estos procesos de búsqueda, descarga y creación de la página web desde el proceso de inicio, el tiempo de respuesta y el rendimiento general de la página web pueden verse afectados.
La representación del lado del servidor puede crear una página web HTML en el lado del servidor y el servidor puede almacenar en caché esa página web HTML estática para servirla al usuario MÁS RÁPIDO.
En este método, el navegador obtendrá una página web lista para usar de la memoria caché y el servidor no se agotará para dar una respuesta para cada activo de la página web individual.
Gracias a la representación del lado del servidor y a un tiempo de respuesta más rápido, compresión Gzip y Brotli, se puede optimizar el LCP.
2. Red de distribución de contenido (CDN) para mejorar el LCP
Si un sitio web tiene un solo servidor, se puede sobrecargar fácilmente. Además, si no hay suficiente «espacio de disco», «CPU», «Red» o «Memoria» en el servidor, el sitio web puede sufrir de un bajo tiempo de respuesta del servidor o, peor aún, errores 500x.
Esta situación afecta a la pintura con contenido más grande (LCP) al igual que otras métricas de velocidad de página. Para evitar la sobrecarga en el servidor, el uso de Content Delivery Network (CDN) es opcional.
Los servicios de Content Delivery Network tienen muchas bases de datos y centros en todo el mundo para ofrecer los contenidos del sitio web a los usuarios desde la ubicación más cercana posible para que el servidor del sitio web no tenga que estar sobrecargado y el usuario pueda experimentar tiempos de respuesta más rápidos.
El uso de CDN puede afectar positivamente al Largest Content Painful, ya que asegura que los dispositivos y navegadores de los usuarios descarguen el contenido necesario más rápido sin agotar el servidor real del sitio web.
El uso de CDN puede aumentar el tiempo de LCP. Una representación del uso de CDN y sus efectos en Pagespeed.
3. Uso de Server Side Rendering para almacenar y entregar más rapido las páginas web
El almacenamiento en caché de las páginas web HTML de forma estática en los sistemas de almacenamiento en caché del lado del servidor puede reducir el tiempo de respuesta.
Dado que está almacenado en la caché, el servidor no tiene que volver a crearlo. Para utilizar el almacenamiento en caché de páginas HTML estáticas, el documento HTML no debe cambiarse en cada solicitud.
Algunos de los métodos y opciones populares de almacenamiento en caché del lado del servidor se enumeran a continuación.
- Utilice servidores proxy inversos como Nginx o Varnish que se comportan como servidores de caché frente a un servidor de aplicaciones.
- Los sistemas en la nube como AWS, Azure y Firebase tienen sus propios sistemas y pautas de caché.
- Utilice CDN Systems para que su contenido se pueda almacenar en caché en los servidores de borde que se encuentran cerca de la ubicación de los usuarios.
4. Utilice Service Worker para almacenar en caché los activos necesarios para mejorar la pintura con contenido más grande
Los Service Workers son los sistemas de caché locales que almacenan todos los activos o algunos de ellos en el almacenamiento local (navegador) de ciertos sitios web.
Si hay un Service Worker en un sitio web, almacenará parte del contenido web en el almacenamiento local (partes tipo <head>, <footer>, barras de navegación, <aside>, entre otros), de modo que el navegador utilizará estos activos en la próxima sesión. Esto aumentará el rendimiento general de la página web y reducirá la posibilidad de sobrecarga del servidor.
Para mejorar el LCP, el uso de Service Worker es uno de los métodos eficientes.
Un experimento: Service Worker y correlación de tiempo LCP
5. Utilice las sugerencias del navegador para mejorar el rendimiento de LCP
Para mejorar el tiempo de LCP podemos usar atributos como: «preconnect», «preload», «DNS-prefetch», «prefetch», «prerender», «async», «defer», en los archivos correspondientes.
Puede resultar útil cargar previamente los componentes necesarios de la página web para mejorar el LCP mientras se usa «defer» en los archivos Javascript que no están relacionados con el contenido de LCP.
Además, el uso de «preconnect» en la dirección CDN puede ser útil si hay contenido relacionado con el LCP en el servidor CDN.
Ejemplo de precarga:
<link rel=»preconnect» href=»https://example.com»>
Ejemplo de preconnect:
<link rel=»preconnect» href=»https://example.com»>
Además, puede utilizar “DNS-Prefetch” pero no realiza el protocolo de enlace TLS ni la negociación de TCP.
6. Elimine los recursos de bloqueo de renderizado para mejorar el LCP
Los navegadores renderizan las páginas web a través de documentos HTML mientras analizan el Modelo de objetos de documento (DOM), cualquier “hoja de estilo” y archivo de “script” bloquean la renderización.
Para eliminar los recursos de bloqueo de procesamiento, los activos no críticos deben aplazarse y también minimizarse.
La eliminación de los recursos de bloqueo de renderizado mejorará el «First paint», el «First Contentful paint» y, naturalmente, el «Largest Content Painful o LCP».
Para reducir los efectos del archivo CSS que bloquea el procesamiento se debe realizar las siguientes acciones:
Se puede ver que los archivos CSS pueden crear bloqueos durante más de 2 segundos.
Cómo comprimir y minimizar los archivos CSS para mejorar el Largest Content Painful
Comprimir y minimizar los archivos CSS disminuirá el efecto de «bloqueo de procesamiento» de los archivos CSS para que los usuarios puedan ver la pintura con contenido más grande antes.
Para realizar la minificación y compresión de CSS, puede utilizar los métodos siguientes.
- Elimine los comentarios en los archivos CSS.
- Refactorizar todos los Códigos CSS innecesarios e inflados.
- Elimina y corrige todos los declarantes importantes.
- Corrija el uso total de ID múltiples.
- Use, Webpack, Gulp, Rollup para la limpieza de CSS.
- Comprima los archivos CSS eliminando los espacios.
- Elimine todos los códigos muertos y no utilizados de los archivos CSS.
- Descargue los archivos CSS de forma asincrónica (“async”)
- Inline the Critical CSS y colóquelo en la sección <head>. Para incorporar los códigos CSS, también puede utilizar los paquetes «CriticalCSS«, «Penthouse«, «Critical» y «Critters» para crear CSS crítico para la sección superior de la página.
Cómo reducir el tiempo de bloqueo de JavaScript para mejorar el Largest Content Painful
La descarga y el uso de una cantidad mínima de Javascript siempre es mejor para la optimización. Los archivos Javascript bloquean y detienen el analizador cuando el navegador ejecuta los procesos Javascript, DOM y CSSOM. Por lo tanto, solo usar los archivos Javascript necesarios para la sección de Above the Fold o pliegue anterior es útil para el tiempo del LCP.
Para reducir el efecto de bloqueo del analizador de los archivos Javascript en el contexto de LCP, puede utilizar los métodos siguientes.
- Minificar archivos Javascript.
- Comprimir archivos Javascript.
- Eliminar comentarios y código innecesario de archivos Javascript.
- Limpiar todo el código muerto y no utilizado de los archivos Javascript.
- Minimice el uso innecesario de Polyfills
Puede utilizar el Informe de cobertura de Chrome para encontrar códigos muertos y no utilizados para diferentes páginas web como «Por función» o «Por bloque». Además, el uso de Puppeteer puede brindar más detalles sobre el Informe de cobertura.
7. Optimización de imágenes para mejorar el LCP
Las imágenes son uno de los recursos más pesados en las páginas web.
Optimizar y comprimir imágenes conservando la calidad visual de las mismas es importante en términos de UX, velocidad de página y eficiencia de rastreo.
En el contexto del LCP, la optimización de imágenes puede aumentar el rendimiento directamente. Dado que el tamaño visual de las imágenes en la pantalla también afecta al LCP, optimizarlas puede significar un impacto directamente.
Para mejorar el rendimiento del LCP mediante la optimización de las imágenes, tenemos lo siguiente.
- Si las imágenes no son necesarias con la sección de Above the Fold o pliegue anterior y el LCP, lo mejor es intentar aplazarlas.
- Comprima imágenes con diferentes métodos como Imagemin, Webpack, Gulp, Grunt o Python.
- Cambie los formatos de imagen para disminuir el tamaño.
- Utilice siempre imágenes responsive para un mejor rendimiento.
- Sirva imágenes a través de un CDN de imágenes.
- Comprima las imágenes antes de subirlas.
8. Utilice Adaptive Serving para la optimización de LCP
El servicio adaptable o Adaptive Serving funciona proporcionando diferentes activos de la página web al usuario de acuerdo con su conexión y tipo de dispositivo.
En este contexto, Adaptive Serving puede mejorar la experiencia del usuario al tiempo que aumenta la satisfacción del mismo.
Ofrecer imágenes y recursos no pesados a los tipos de conexión 3G puede ser útil, o no entregar javascripts pesados a un usuario de teléfono móvil lento puede aumentar la interacción del usuario junto con el LCP.
Para utilizar Adaptive Serving, se puede utilizar la API de información de red, la API de memoria del dispositivo y la API de hardware y concurrencia.
Se pueden crear diferentes variaciones del mismo recurso para diferentes user-agent. Este es un ejemplo de servicio adaptable:
if (navigator.connection && navigator.connection.effectiveType) {
if (navigator.connection.effectiveType === ‘4g’) {
// Load Third Party Trackers
} else {
// Don’t Load Third Party Trackers
}
}
9. No confíe en el renderizado del lado del cliente para un mejor tiempo de LCP
Si un sitio web usa React, Vue o Angular con renderizado del lado del cliente, el tiempo de pintura con contenido más grande puede ser incluso superior a 4 segundos.
Porque, hasta que finalice el tiempo de descarga y procesamiento de los activos JS importantes y pesados, el navegador no puede mostrar ningún contenido.
Esta situación crea una experiencia de usuario no confiable y no eficiente junto con una experiencia de carga de página web no interactiva.
Para crear una página web de carga rápida a través de frameworks como Angular, React o Vue, considere las siguientes opciones:
- Minify Javascript Bundles.
- Utilice el renderizado del lado del servidor (SSR) en lugar del renderizado del lado del cliente (CSR).
- Usar renderizado previo o pre render (<link rel=”prerender”).
- Disminuir la cantidad de Javascript no crítico.
- Aplazar Javascript no utilizado para la sección de la mitad superior de la página.
Además, podemos utilizar los complementos necesarios para que el navegador pueda examinar los componentes React, Vue o Angular en la página web junto con sus «accesorios», «estados», «jerarquía de componentes» para que pueda encontrar y comprender la estructura del código para encontrar mejores oportunidades de optimización.
10. Utilice el renderizado del lado del servidor y el renderizado previo
El renderizado del lado del servidor consiste en crear las páginas web en el servidor antes de que el agente de usuario (user-agent) solicite la misma página web.
El Server-Side-Render también se puede utilizar para los sitios web basados en React, Angular y Vue.
El uso de la representación del lado del servidor para las páginas web puede aumentar el LCP.
Para evitar algunas posibles situaciones negativas importantes durante la renderización del lado del servidor, asegúrese de que no existan los mismos archivos Javascript tanto en el lado del servidor como en el lado del cliente.
La representación del lado del servidor siempre mejora el tiempo hasta el primer byte (TTFB), pero también puede disminuir el tiempo de interacción (TTI) ya que la página web no será interactiva hasta que Javascript active las funciones necesarias del lado del cliente.
Por otro lado, la renderización previa (prerender) es diferente a la renderización del lado del servidor.
En la representación del lado del servidor, el navegador utiliza el HTML estático que se creó en el servidor, mientras que el navegador también «hidrata» los archivos Javascript necesarios en el lado del cliente para la interacción sobre el mismo contenido DOM.
El método de representación previa también crea páginas HTML estáticas con un «navegador sin cabeza o headless browser» y envía estas páginas HTML estáticas junto con los archivos Javascript necesarios para la interacción del usuario en el navegador al mismo tiempo.
El renderizado previo también mejora el Content Largest Painful, pero aún así, también puede aumentar el tiempo de interacción (TTI).
Además, la “capacidad de respuesta de carga” y la “interacción del usuario durante el tiempo de carga de la página” están relacionadas con el FID o First Input Delay.
Conclusiones
El LCP es una de las métricas de velocidad de página centradas en el usuario más importantes.
Refleja la función y el propósito básicos de la página web, y también podría ayudar a los algoritmos del motor de búsqueda a comprender el propósito de la página y su potencial para satisfacer la intención de búsqueda de los usuarios.
La medición del LCP y la optimización también son importantes para el SEO. Es una métrica compleja de rendimiento y UX.
Comprender la metodología de medición LCP puede mejorar la visión del SEO o el desarrollador para mejorar el potencial de la página.
Saber cómo funcionan los navegadores y cómo se están mejorando, son necesidades críticas para los SEO, la terminología y la medición del Largest Content Painful brindan esta oportunidad.
Como SEO debemos tener en cuenta y profundizar un poco más en este y otros factores de Web Vitals para evitar ser perjudicados en la próxima actualización de los algoritmos principales de Google.