Una guía paso a paso para desglosar el LCP y identificar las áreas clave que se deben mejorar.
Fecha de publicación: 30 de abril de 2020
El procesamiento de imagen con contenido más grande (LCP) es una de las tres métricas de las Métricas web esenciales y representa la rapidez con la que se carga el contenido principal de una página web. Específicamente, el LCP mide el tiempo desde que el usuario inicia la carga de la página hasta que se renderiza la imagen o el bloque de texto más grande dentro del viewport.
Para proporcionar una buena experiencia del usuario, los sitios deben esforzarse por tener un LCP de 2.5 segundos o menos para, al menos, el 75% de las visitas a la página.
Varios factores pueden afectar la rapidez con la que el navegador puede cargar y renderizar una página web, y las demoras en cualquiera de ellos pueden tener un impacto significativo en el LCP.
Es raro que una corrección rápida de una sola parte de una página genere una mejora significativa del LCP. Para mejorar el LCP, debes observar todo el proceso de carga y asegurarte de que cada paso esté optimizado.
Información sobre tu métrica de LCP
Antes de optimizar el LCP, los desarrolladores deben intentar comprender si incluso tienen un problema de LCP y cuál es su alcance.
El LCP se puede medir en varias herramientas, y no todas miden el LCP de la misma manera. Para comprender el LCP de los usuarios reales, debemos tener en cuenta lo que experimentan los usuarios reales, en lugar de lo que muestra una herramienta de laboratorio como Lighthouse o las pruebas locales. Estas herramientas basadas en laboratorios pueden proporcionar una gran cantidad de información para explicar y ayudarte a mejorar el LCP, pero ten en cuenta que las pruebas de laboratorio por sí solas pueden no ser del todo representativas de lo que experimentan tus usuarios reales.
Los datos de LCP basados en usuarios reales se pueden mostrar a partir de las herramientas de supervisión de usuarios reales (RUM) instaladas en un sitio o mediante el Informe sobre la experiencia del usuario en Chrome (CrUX), que recopila datos anónimos de usuarios reales de Chrome para millones de sitios web.
Cómo usar los datos de LCP de CrUX de las Herramientas para desarrolladores de Chrome
El panel Rendimiento de Chrome DevTools muestra tu experiencia de LCP local junto a la LCP de CrUX de la página o el origen en la vista de métricas en vivo.
Si aplicas capas de datos de campo al panel Rendimiento, puedes evaluar si una página tiene algún problema de LCP de usuarios reales y adaptar la configuración de tu entorno local para reproducir y depurar mejor esos problemas.
Cómo usar los datos de LCP de CrUX de PageSpeed Insights
PageSpeed Insights proporciona acceso a los datos de CrUX en la sección superior etiquetada como Descubre lo que experimentan tus usuarios reales. Puedes encontrar datos más detallados sobre los labs en la sección Diagnose performance issues (Diagnostica problemas de rendimiento). Si los datos de CrUX están disponibles para tu sitio web, siempre concéntrate primero en los datos reales de los usuarios.
PageSpeed Insights muestra hasta cuatro datos de CrUX diferentes:
- Datos de dispositivos móviles para Esta URL
- Datos de computadoras de escritorio para esta URL
- Datos móviles de todo el origen
- Datos de computadoras para todo Origin
Puedes activarlos o desactivarlos en los controles que se encuentran en la parte superior y superior derecha de esta sección. Si una URL no tiene suficientes datos para mostrarse a nivel de la URL, pero sí tiene datos para el origen, PageSpeed Insights siempre muestra los datos del origen.
El LCP de todo el origen puede ser muy diferente al LCP de una página individual según cómo se cargue el LCP en esa página en comparación con otras páginas de ese origen. También puede verse afectado por la forma en que los visitantes navegan a estas páginas. Las páginas principales suelen ser visitadas por usuarios nuevos y, por lo tanto, a menudo se cargan "en frío", sin contenido almacenado en caché, por lo que suelen ser las páginas más lentas de un sitio web.
Observar las cuatro categorías diferentes de datos de CrUX puede ayudarte a comprender si un problema de LCP es específico de esta página o es un problema más general en todo el sitio. Del mismo modo, puede mostrar qué tipos de dispositivos tienen problemas de LCP.
Cómo usar las métricas complementarias de CrUX de PageSpeed Insights
Quienes deseen optimizar el LCP también deben usar los tiempos de primer procesamiento de imagen con contenido (FCP) y tiempo para el primer byte (TTFB), que son buenas métricas de diagnóstico que pueden proporcionar estadísticas valiosas sobre el LCP.
TTFB es el tiempo en el que el visitante comienza a navegar a una página (por ejemplo, cuando hace clic en un vínculo) hasta que se reciben los primeros bytes del documento HTML. Un TTFB alto puede hacer que lograr un LCP de 2.5 segundos sea un desafío o incluso imposible.
Un TTFB alto puede deberse a varios redireccionamientos del servidor, a visitantes ubicados lejos del servidor del sitio más cercano, a visitantes con condiciones de red deficientes o a la imposibilidad de usar contenido almacenado en caché debido a parámetros de consulta.
Una vez que una página comienza a renderizarse, puede haber una pintura inicial (por ejemplo, el color de fondo), seguida de la aparición de cierto contenido (por ejemplo, el encabezado del sitio). El FCP mide la apariencia del contenido inicial. La diferencia entre el FCP y otras métricas puede ser muy reveladora.
Una gran diferencia entre el TTFB y el FCP podría indicar que el navegador necesita descargar muchos recursos que bloquean la renderización. También puede ser una señal de que debe completar una gran cantidad de trabajo para renderizar cualquier contenido significativo; un signo clásico de un sitio que depende en gran medida de la renderización del cliente.
Una gran diferencia entre el FCP y el LCP indica que el recurso de LCP no está disponible de inmediato para que el navegador lo priorice (por ejemplo, texto o imágenes que administra JavaScript en lugar de estar disponibles en el HTML inicial) o que el navegador está completando otra tarea antes de poder mostrar el contenido del LCP.
Cómo usar los datos de Lighthouse de PageSpeed Insights
La sección de Lighthouse de PageSpeed Insights ofrece orientación para mejorar el LCP, pero primero debes verificar si el LCP proporcionado está en general de acuerdo con los datos reales del usuario que proporciona CrUX. Si Lighthouse y CrUX no coinciden, es probable que CrUX proporcione una imagen más precisa de la experiencia del usuario. Antes de realizar cualquier acción, asegúrate de que tus datos de CrUX sean de tu página, no del origen completo.
Si tanto Lighthouse como CrUX muestran valores de LCP que necesitan mejoras, la sección de Lighthouse puede proporcionar orientación valiosa sobre cómo mejorar el LCP. Usa el filtro de LCP para mostrar solo las auditorías relevantes para la métrica, de la siguiente manera:
Además de las oportunidades de mejora, hay información de diagnóstico que puede proporcionar más información para ayudar a diagnosticar el problema. El diagnóstico del elemento de procesamiento de imagen con contenido más grande muestra un desglose útil de los diversos tiempos que conforman el LCP:
A continuación, analizaremos estas subpartes.
Desglose de LCP
La optimización para el LCP puede ser una tarea más compleja cuando PageSpeed Insights no te ofrece la respuesta para mejorar esta métrica. Con las tareas complejas, generalmente es mejor dividirlas en tareas más pequeñas y fáciles de administrar, y abordar cada una por separado.
En esta sección, se presenta una metodología para desglosar el LCP en sus partes más críticas y, luego, presentar recomendaciones y prácticas recomendadas específicas para optimizar cada parte.
La mayoría de las cargas de página suelen incluir varias solicitudes de red, pero, para identificar oportunidades de mejorar el LCP, debes comenzar por observar solo dos:
- El documento HTML inicial
- El recurso de LCP (si corresponde)
Si bien otras solicitudes en la página pueden afectar el LCP, estas dos solicitudes (específicamente, los momentos en que comienza y termina el recurso de LCP) revelan si tu página está optimizada para el LCP o no.
Para identificar el recurso de LCP, puedes usar herramientas para desarrolladores (como PageSpeed Insights, que se mencionó antes, Herramientas para desarrolladores de Chrome o WebPageTest) para determinar el elemento de LCP. Desde allí, puedes hacer coincidir la URL (otra vez, si corresponde) que cargó el elemento en una cascada de red de todos los recursos que cargó la página.
Por ejemplo, en la siguiente visualización, se muestran estos recursos destacados en un diagrama de cascada de red de una carga de página típica, en la que el elemento LCP requiere una solicitud de imagen para renderizarse.
Para que una página esté bien optimizada, debes hacer que tu solicitud de recursos de LCP comience a cargarse lo antes posible y que el elemento de LCP se renderice lo más rápido posible después de que se termine de cargar el recurso de LCP. Para visualizar si una página en particular sigue o no este principio, puedes desglosar el tiempo total de la LCP en las siguientes subpartes:
- Tiempo hasta el primer byte (TTFB)
- Es el tiempo que transcurre desde que el usuario inicia la carga de la página hasta que el navegador recibe el primer byte de la respuesta del documento HTML.
- Retraso en la carga de recursos
- Es el tiempo que transcurre entre el TTFB y cuando el navegador comienza a cargar el recurso LCP. Si el elemento LCP no requiere una carga de recursos para su renderización (por ejemplo, si el elemento es un nodo de texto renderizado con una fuente del sistema), este tiempo es 0.
- Duración de la carga de recursos
- Es el tiempo que se tarda en cargar el recurso LCP. Si el elemento de LCP no requiere una carga de recursos para su renderización, este tiempo es 0.
- Retraso en la renderización del elemento
- Es el tiempo que transcurre entre el momento en que termina de cargarse el recurso de LCP y el momento en que se renderiza por completo el elemento de LCP.
El LCP de cada página consta de estas cuatro subcategorías. No hay brechas ni superposiciones entre ellos, y suman el tiempo completo de la LCP.
Cada página puede tener su valor de LCP dividido en estas cuatro subpartes. No hay superposición ni brecha entre ellos. En conjunto, suman el tiempo de LCP completo.
Cuando se optimiza el LCP, es útil intentar optimizar estas subpartes de forma individual. Sin embargo, también es importante tener en cuenta que debes optimizarlos todos. En algunos casos, una optimización aplicada a una parte no mejorará el LCP, sino que solo trasladará el tiempo ahorrado a otra parte.
Por ejemplo, en la cascada de red anterior, si redujeras el tamaño del archivo de nuestra imagen comprimiéndola más o cambiando a un formato más óptimo (como AVIF o WebP), eso reduciría la duración de carga de recursos, pero en realidad no mejoraría la LCP porque el tiempo simplemente se trasladaría a la subparte de demora en la renderización de elementos:
Esto sucede porque, en esta página, el elemento LCP está oculto hasta que se termina de cargar el código JavaScript y, luego, todo se revela a la vez.
Este ejemplo ayuda a ilustrar el punto que debes optimizar todas estas subpartes para lograr los mejores resultados de LCP.
Tiempos óptimos de subpartes
Para optimizar cada subparte del LCP, es importante comprender cuál es el desglose ideal de estas subpartes en una página bien optimizada.
De las cuatro subpartes, dos tienen la palabra "delay" en sus nombres. Esa es una pista de que debes acercar estos tiempos lo más cerca posible de cero. Las otras dos partes incluyen solicitudes de red, que por su propia naturaleza llevan tiempo.
Ten en cuenta que estos desgloses de tiempo son lineamientos, no reglas estrictas. Si los tiempos de LCP de tus páginas se mantienen dentro de 2.5 segundos de forma coherente, no importa cuáles sean las proporciones relativas. Sin embargo, si pasas mucho tiempo innecesario en cualquiera de las partes de "demora", será muy difícil alcanzar constantemente el objetivo de 2.5 segundos.
Una buena manera de pensar en el desglose del tiempo de LCP es la siguiente:
- La gran mayoría del tiempo de LCP se debe dedicar a cargar el documento HTML y la fuente de LCP.
- Cualquier momento previo al LCP en el que uno de estos dos recursos no se está cargando es una oportunidad para mejorar.
Cómo optimizar cada parte
Ahora que comprendes cómo se deben desglosar cada uno de los tiempos de las subpartes del LCP en una página bien optimizada, puedes comenzar a optimizar tus propias páginas.
En las siguientes cuatro secciones, se presentarán recomendaciones y prácticas recomendadas para optimizar cada parte. Estos se presentan en orden, comenzando por las optimizaciones que probablemente tendrán el mayor impacto.
1. Elimina el retraso en la carga de recursos
El objetivo de este paso es garantizar que el recurso de LCP comience a cargarse lo antes posible. Si bien, en teoría, el recurso podría comenzar a cargarse inmediatamente después del TTFB, en la práctica, siempre hay un retraso antes de que los navegadores comiencen a cargar recursos.
Una buena regla general es que tu recurso de LCP debe comenzar a cargarse al mismo tiempo que el primer recurso cargado por esa página. En otras palabras, si el recurso de LCP comienza a cargarse más tarde que el primer recurso, hay una oportunidad de mejora.
En términos generales, existen dos factores que afectan la rapidez con la que se puede cargar un recurso de LCP:
- Cuándo se descubre el recurso
- Es la prioridad que se le asigna al recurso.
Optimiza cuando se descubre el recurso
Para garantizar que tu recurso de LCP comience a cargarse lo antes posible, es fundamental que el escáner de precarga del navegador pueda detectarlo en la respuesta inicial del documento HTML. Por ejemplo, en los siguientes casos, el navegador puede descubrir el recurso de LCP escaneando la respuesta del documento HTML:
- El elemento LCP es un elemento
<img>, y sus atributossrcosrcsetestán presentes en el lenguaje de marcado HTML inicial. - El elemento de LCP requiere una imagen de fondo de CSS, pero esa imagen se precarga con
<link rel="preload">en el lenguaje de marcado HTML (o con un encabezadoLink). - El elemento LCP es un nodo de texto que requiere una fuente web para renderizarse, y la fuente se carga con
<link rel="preload">en el lenguaje de marcado HTML (o con un encabezadoLink).
Estos son algunos ejemplos en los que no se puede descubrir el recurso de LCP a partir del análisis de la respuesta del documento HTML:
- El elemento LCP es un
<img>que se agrega de forma dinámica a la página con JavaScript. - El elemento LCP se carga de forma diferida con una biblioteca de JavaScript que oculta sus atributos
srcosrcset(a menudo, comodata-srcodata-srcset). - El elemento LCP requiere una imagen de fondo CSS.
En cada uno de estos casos, el navegador debe ejecutar la secuencia de comandos o aplicar la hoja de estilo, lo que suele implicar esperar a que finalicen las solicitudes de red, antes de poder descubrir el recurso de LCP y comenzar a cargarlo. Esto nunca es óptimo.
Para eliminar las demoras innecesarias en la carga de recursos, el recurso LCP debe ser detectable desde la fuente HTML. En los casos en los que solo se hace referencia al recurso desde un archivo CSS o JavaScript externo, el recurso de LCP debe cargarse previamente con una prioridad de recuperación alta, por ejemplo:
<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">
<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">
Optimiza la prioridad que se le asigna al recurso
Incluso si el recurso LCP es detectable en el lenguaje de marcado HTML, es posible que de todos modos no comience a cargarse a partir del primer recurso. Esto puede ocurrir si la heurística de prioridad del escáner de precarga del navegador no reconoce que el recurso es importante o si determina que otros recursos son más importantes.
Por ejemplo, puedes retrasar la imagen de la LCP con HTML si configuras loading="lazy" en tu elemento <img>. El uso de la carga diferida significa que el recurso no se cargará hasta que el diseño confirme que la imagen está en el viewport, por lo que es posible que comience a cargarse más tarde de lo que lo haría de otra manera.
Incluso sin la carga diferida, los navegadores no cargan las imágenes inicialmente con la prioridad más alta, ya que no son recursos que bloqueen la renderización. Puedes indicarle al navegador qué recursos son más importantes mediante el atributo fetchpriority para los recursos que podrían beneficiarse de una prioridad más alta:
<img fetchpriority="high" src="/path/to/hero-image.webp">
Te recomendamos que configures fetchpriority="high" en un elemento <img> si crees que es probable que sea el elemento LCP de tu página. Sin embargo, establecer una prioridad alta en más de una o dos imágenes hace que el parámetro de configuración de prioridad no sea útil para reducir el LCP.
También puedes disminuir la prioridad de las imágenes que podrían estar al principio de la respuesta del documento, pero que no son visibles debido al diseño, como las imágenes en las diapositivas del carrusel que no son visibles al inicio:
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
Dejar de priorizar ciertos recursos puede permitir un mayor ancho de banda para los recursos que más lo necesitan, pero ten cuidado. Siempre verifica la prioridad de los recursos en DevTools y prueba los cambios con herramientas de lab y de campo.
Después de optimizar la prioridad de los recursos de LCP y el tiempo de descubrimiento, la cascada de red debería tener el siguiente aspecto (el recurso de LCP empezará al mismo tiempo que el primer recurso):
2. Elimina el retraso en la renderización de elementos
El objetivo de este paso es garantizar que el elemento LCP se pueda renderizar de inmediato después de que se haya terminado de cargar su recurso, sin importar cuándo suceda.
El motivo principal por el que el elemento LCP no podría renderizarse inmediatamente después de que se termina de cargar su recurso es si la renderización está bloqueada por algún otro motivo:
- La renderización de toda la página está bloqueada debido a que los
<head>aún están cargando hojas de estilo o secuencias de comandos síncronas. - El recurso de LCP terminó de cargarse, pero el elemento de LCP aún no se agregó al DOM (está esperando que se cargue algún código JavaScript).
- Otro código oculta el elemento, como una biblioteca de pruebas A/B que aún está determinando en qué experimento debe estar el usuario.
- El subproceso principal está bloqueado debido a tareas largas, y el trabajo de renderización debe esperar hasta que se completen esas tareas largas.
En las siguientes secciones, se explica cómo abordar las causas más comunes de la demora innecesaria en la renderización de elementos.
Reduce o intercala los hojas de estilo que bloquean la renderización
Las hojas de estilo cargadas desde el marcado HTML bloquearán la renderización de todo el contenido que las siga, lo cual es bueno, ya que, por lo general, no quieres renderizar HTML sin diseño. Sin embargo, si la hoja de estilo es tan grande que tarda mucho más en cargarse que el recurso de LCP, impedirá que se renderice el elemento LCP, incluso después de que se haya terminado de cargar el recurso, como se muestra en este ejemplo:
Para solucionar este problema, puedes hacer lo siguiente:
- intercalar la hoja de estilo en el código HTML para evitar la solicitud de red adicional
- reducir el tamaño de la hoja de estilo.
En general, la incorporación de la hoja de estilo solo se recomienda si esta es pequeña, ya que el contenido insertado en el código HTML no se puede beneficiar del almacenamiento en caché en cargas posteriores de página. Si una hoja de estilo es tan grande que tarda más en cargarse que el recurso LCP, es poco probable que sea una buena candidata para la incorporación.
En la mayoría de los casos, la mejor manera de garantizar que la hoja de estilo no bloquee la renderización del elemento LCP es reducir su tamaño para que sea más pequeño que el recurso LCP. Esto debería garantizar que no sea un cuello de botella para la mayoría de las visitas.
Estas son algunas recomendaciones para reducir el tamaño de la hoja de estilo:
- Quita el CSS que no se usa: Usa las Herramientas para desarrolladores de Chrome para encontrar las reglas de CSS que no se usan y que se podrían quitar (o aplazar).
- Aplaza el CSS no esencial: Divide tu hoja de estilo en estilos que sean necesarios para la carga inicial de la página y, luego, en estilos que se puedan cargar de forma diferida.
- Reduce el uso de CSS y comprime: En el caso de los estilos que son fundamentales, asegúrate de reducir su tamaño de transferencia tanto como sea posible.
Aplaza o inserta el código JavaScript que bloquea la visualización
Casi nunca es necesario agregar secuencias de comandos síncronas (secuencias de comandos sin los atributos async o defer) a la <head> de tus páginas, y hacerlo casi siempre tendrá un impacto negativo en el rendimiento.
En los casos en que el código JavaScript debe ejecutarse lo antes posible en la carga de la página, es mejor incorporarlo para que la renderización no se retrase esperando otra solicitud de red. Sin embargo, al igual que con los diseños de página, solo debes intercalar las secuencias de comandos si son muy pequeñas.
<head> <script src="/path/to/main.js"></script> </head>
<head>
<script>
// Inline script contents directly in the HTML.
// IMPORTANT: only do this for very small scripts.
</script>
</head>Usa el procesamiento del servidor
La renderización del servidor (SSR) es el proceso de ejecutar la lógica de tu aplicación del cliente en el servidor y responder a las solicitudes de documentos HTML con el marcado HTML completo.
Desde la perspectiva de la optimización de la LCP, existen dos ventajas principales del SSR:
- Los recursos de imagen serán detectables desde el código fuente HTML (como se explicó en el paso 1 anterior).
- El contenido de tu página no requerirá solicitudes adicionales de JavaScript para terminar antes de que se pueda renderizar.
La principal desventaja de la SSR es que requiere tiempo adicional de procesamiento del servidor, lo que puede ralentizar tu TTFB. Sin embargo, esta compensación suele valer la pena, ya que los tiempos de procesamiento del servidor están bajo tu control, mientras que las capacidades de red y dispositivo de tus usuarios no lo están.
Una opción similar al SSR se denomina generación de sitios estáticos (SSG) o renderización previa. Este es el proceso de generar tus páginas HTML en un paso de compilación en lugar de hacerlo a pedido. Si la renderización previa es posible con tu arquitectura, suele ser una mejor opción para el rendimiento.
Divide las tareas largas
Incluso si seguiste las sugerencias que se mencionaron anteriormente y tu código JavaScript no bloquea la renderización ni es responsable de la renderización de tus elementos, puede retrasar el LCP.
El motivo más común por el que esto sucede es cuando las páginas cargan archivos JavaScript grandes, que deben analizarse y ejecutarse en el subproceso principal del navegador. Esto significa que, incluso si tu recurso de imagen se descargó por completo, es posible que deba esperar hasta que una secuencia de comandos no relacionada termine de ejecutarse para poder renderizarse.
Actualmente, todos los navegadores renderizan imágenes en el subproceso principal, lo que significa que cualquier elemento que lo bloquee también puede generar una demora innecesaria en la renderización de elementos.
3. Reduce la duración de la carga de recursos
El objetivo de este paso es reducir el tiempo dedicado a transferir los bytes del recurso a través de la red al dispositivo del usuario. En general, existen cuatro maneras de hacerlo:
- Reduce el tamaño del recurso.
- Reduce la distancia que debe recorrer el recurso.
- Reduce la contención por el ancho de banda de la red.
- Eliminar por completo el tiempo de red
Reduce el tamaño del recurso
El recurso de LCP de una página (si tiene uno) será una imagen o una fuente web. En las siguientes guías, se explica con gran detalle cómo reducir el tamaño de ambos:
- Publica el tamaño de imagen óptimo
- Usa formatos de imagen modernos
- Cómo comprimir imágenes
- Reduce el tamaño de la fuente web
Reduce la distancia que debe recorrer el recurso
Además de reducir el tamaño de un recurso, también puedes reducir los tiempos de carga si colocas tus servidores lo más cerca posible de tus usuarios geográficamente. Y la mejor manera de hacerlo es usar una red de distribución de contenidos (CDN).
Las CDN de imágenes, en particular, son especialmente útiles porque no solo reducen la distancia que debe recorrer el recurso, sino que también suelen reducir su tamaño, lo que implementa automáticamente todas las recomendaciones de reducción de tamaño anteriores por ti.
Reduce la contención por el ancho de banda de red
Incluso si reduces el tamaño del recurso y la distancia que debe recorrer, un recurso puede tardar mucho tiempo en cargarse si estás cargando muchos otros recursos al mismo tiempo. Este problema se conoce como contención de red.
Si le otorgaste a tu recurso de LCP un valor de fetchpriority alto y comenzaste a cargarlo lo antes posible, el navegador hará todo lo posible para evitar que los recursos de menor prioridad compitan con él. Sin embargo, si cargas muchos recursos con un fetchpriority alto o si solo cargas muchos recursos en general, es posible que se vea afectada la rapidez con la que se carga el recurso de LCP.
Eliminar por completo el tiempo de red
La mejor manera de reducir la duración de la carga de recursos es eliminar la red por completo del proceso. Si publicas tus recursos con una política de control de caché eficiente, los visitantes que soliciten esos recursos por segunda vez los recibirán desde la caché, lo que reducirá la duración de carga de recursos a prácticamente cero.
Si tu recurso de LCP es una fuente web, además de reducir el tamaño de la fuente web, también debes considerar si necesitas bloquear la renderización en la carga de recursos de la fuente web. Si estableces un valor font-display distinto de auto o block, el texto siempre será visible durante la carga y el LCP no se bloqueará en una solicitud de red adicional.
Por último, si tu recurso de LCP es pequeño, tiene sentido intercalar los recursos como una URL de datos, lo que también eliminará la solicitud de red adicional. Sin embargo, el uso de URLs de datos incluye advertencias porque los recursos no se pueden almacenar en caché y, en algunos casos, puede generar retrasos en la renderización más largos debido al costo de decodificación adicional.
4. Reduce el tiempo hasta el primer byte.
El objetivo de este paso es entregar el HTML inicial lo más rápido posible. Este paso se incluye en último lugar porque, a menudo, es el que los desarrolladores tienen menos control. Sin embargo, también es uno de los pasos más importantes porque afecta directamente a todos los pasos que le siguen. No puede ocurrir nada en el frontend hasta que el backend entrega ese primer byte de contenido, por lo que todo lo que puedas hacer para acelerar el TTFB también mejorará todas las demás métricas de carga.
Una causa común de un TTFB lento para un sitio que, de lo contrario, sería rápido son los visitantes que llegan a través de varios redireccionamientos, como anuncios o vínculos acortados. Siempre minimiza la cantidad de redireccionamientos que los visitantes deben esperar.
Otra causa común es cuando no se puede usar el contenido almacenado en caché desde un servidor perimetral de CDN y todas las solicitudes deben dirigirse al servidor de origen. Esto puede suceder si los visitantes usan parámetros de URL únicos para las estadísticas, incluso si no generan páginas diferentes.
Para obtener orientación específica sobre cómo optimizar el TTFB, consulta la guía para optimizar el TTFB.
Cómo supervisar el desglose de LCP en JavaScript
La información de tiempo de todas las subpartes del LCP que se analizaron anteriormente está disponible en JavaScript a través de una combinación de las siguientes APIs de rendimiento:
El beneficio de calcular estos valores de tiempo en JavaScript es que te permite enviarlos a un proveedor de análisis o registrarlos en tus herramientas para desarrolladores a fin de facilitar la depuración y la optimización.
Por ejemplo, en la siguiente captura de pantalla, se usa el método performance.measure() de la API de User Timing para agregar barras al segmento de tiempos en el panel Rendimiento de las Herramientas para desarrolladores de Chrome.
Las visualizaciones en la pista Timings son particularmente útiles cuando se observan junto con las pistas Network y Main thread, ya que puedes ver de un vistazo qué más sucede en la página durante estos períodos.
Además de visualizar las subpartes de LCP en la pista de tiempo, también puedes usar JavaScript para calcular qué porcentaje es cada subparte del tiempo total de LCP. Con esa información, puedes determinar si tus páginas cumplen con los desgloses porcentual recomendados que se describieron antes.
En esta captura de pantalla, se muestra un ejemplo que registra el tiempo total de cada subparte de la LCP, así como su porcentaje del tiempo total de la LCP en la consola.
Ambas visualizaciones se crearon con el siguiente código:
const LCP_SUB_PARTS = [
'Time to first byte',
'Resource load delay',
'Resource load duration',
'Element render delay',
];
new PerformanceObserver((list) => {
const lcpEntry = list.getEntries().at(-1);
const navEntry = performance.getEntriesByType('navigation')[0];
const lcpResEntry = performance
.getEntriesByType('resource')
.filter((e) => e.name === lcpEntry.url)[0];
// Ignore LCP entries that aren't images to reduce DevTools noise.
// Comment this line out if you want to include text entries.
if (!lcpEntry.url) return;
// Compute the start and end times of each LCP sub-part.
// WARNING! If your LCP resource is loaded cross-origin, make sure to add
// the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
const ttfb = navEntry.responseStart;
const lcpRequestStart = Math.max(
ttfb,
// Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
);
const lcpResponseEnd = Math.max(
lcpRequestStart,
lcpResEntry ? lcpResEntry.responseEnd : 0
);
const lcpRenderTime = Math.max(
lcpResponseEnd,
// Use LCP startTime (the final LCP time) because there are sometimes
// slight differences between loadTime/renderTime and startTime
// due to rounding precision.
lcpEntry ? lcpEntry.startTime : 0
);
// Clear previous measures before making new ones.
// Note: due to a bug, this doesn't work in Chrome DevTools.
LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));
// Create measures for each LCP sub-part for easier
// visualization in the Chrome DevTools Performance panel.
const lcpSubPartMeasures = [
performance.measure(LCP_SUB_PARTS[0], {
start: 0,
end: ttfb,
}),
performance.measure(LCP_SUB_PARTS[1], {
start: ttfb,
end: lcpRequestStart,
}),
performance.measure(LCP_SUB_PARTS[2], {
start: lcpRequestStart,
end: lcpResponseEnd,
}),
performance.measure(LCP_SUB_PARTS[3], {
start: lcpResponseEnd,
end: lcpRenderTime,
}),
];
// Log helpful debug information to the console.
console.log('LCP value: ', lcpRenderTime);
console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
console.table(
lcpSubPartMeasures.map((measure) => ({
'LCP sub-part': measure.name,
'Time (ms)': measure.duration,
'% of LCP': `${
Math.round((1000 * measure.duration) / lcpRenderTime) / 10
}%`,
}))
);
}).observe({type: 'largest-contentful-paint', buffered: true});
Puedes usar este código tal como está para depuraciones locales o modificarlo para enviar estos datos a un proveedor de servicios de estadísticas a fin de comprender mejor cómo es el desglose del LCP de tus páginas para los usuarios reales.
Resumen
El LCP es complejo y su duración puede verse afectada por varios factores. Sin embargo, si consideras que optimizar el LCP se trata principalmente de optimizar la carga del recurso de LCP, esto puede simplificar las cosas de manera significativa.
En un nivel alto, la optimización de la LCP se puede resumir en cuatro pasos:
- Asegúrate de que el recurso de LCP comience a cargarse lo antes posible.
- Asegúrate de que se pueda renderizar el elemento de LCP apenas su recurso termine de cargarse.
- Reduce el tiempo de carga del recurso de LCP tanto como puedas sin sacrificar la calidad.
- Entrega el documento HTML inicial lo más rápido posible.
Si puedes seguir estos pasos en tus páginas, deberías tener la seguridad de que les brindas a tus usuarios una experiencia de carga óptima y deberías ver eso reflejado en tus puntuaciones de LCP en el mundo real.