Una guía paso a paso sobre cómo desglosar el LCP y cómo identificar las áreas clave que deben mejorarse.
El Largest Contentful Paint (LCP) es una de las tres métricas de Métricas web esenciales y representa la rapidez con la que se carga el contenido principal de una página web. Específicamente, LCP mide el tiempo que transcurre desde que el usuario comienza a cargar la página hasta que se renderiza la imagen o el bloque de texto más grandes en el viewport.
Para brindar una buena experiencia del usuario, los sitios deben esforzarse por tener un LCP de 2.5 segundos o menos durante, 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 los retrasos en cualquiera de ellos pueden tener un impacto significativo en el LCP.
No es común que corregir rápidamente una sola parte de la página genere una mejora significativa del LCP. Para mejorar el LCP, tienes que observar todo el proceso de carga y asegurarte de que cada paso del proceso esté optimizado.
Información sobre la métrica de LCP
Antes de optimizar el LCP, los desarrolladores deben intentar comprender si tienen un problema de LCP y el alcance de alguno.
El LCP se puede medir en varias herramientas y no todas lo miden de la misma manera. Para comprender el LCP de los usuarios reales, debemos analizar lo que experimentan los usuarios reales, en lugar de lo que muestra una herramienta basada en labs, 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 totalmente representativas de la experiencia de tus usuarios reales.
Los datos de LCP basados en usuarios reales se pueden obtener de las herramientas de supervisión de usuarios reales (RUM) instaladas en un sitio o del Informe sobre la experiencia del usuario en Chrome (CrUX), que recopila datos anónimos de usuarios reales de Chrome de millones de sitios web.
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 Descubre lo que experimentan tus usuarios reales. En la sección inferior denominada Diagnostica problemas de rendimiento, encontrarás más datos detallados basados en labs. Si los datos de CrUX están disponibles para tu sitio web, concéntrate siempre en los datos de usuarios reales.
PageSpeed Insights muestra hasta cuatro datos de CrUX diferentes:
- Datos móviles de esta URL
- Datos de computadoras de escritorio para esta URL
- Datos móviles para todo el valor de Origin
- Datos de computadoras de escritorio para todo el conjunto de datos de origen
Puedes activarlos en los controles que se encuentran en la parte superior derecha de esta sección. Si una URL no tiene suficientes datos para mostrar a nivel de URL, pero sí tiene datos del origen, PageSpeed Insights siempre muestra los datos de origen.
El LCP de todo el origen puede ser muy diferente del de una página individual, según cómo se cargue el LCP en esa página en comparación con el de otras de ese origen. También puede verse afectada por la forma en que los visitantes navegan a estas páginas. Las páginas principales suelen ser visitadas por nuevos usuarios y, por lo tanto, a menudo se cargan "en frío", sin contenido almacenado en caché y, a menudo, son las páginas más lentas de un sitio web.
Observa las cuatro categorías diferentes de datos de CrUX para comprender si un problema de LCP es específico de esta página o si es un problema más general que afecta a todo el sitio. De manera similar, puede mostrar qué tipos de dispositivos tienen problemas de LCP.
Cómo usar métricas complementarias de CrUX de PageSpeed Insights
Quienes deseen optimizar el LCP también deben usar los tiempos First Contentful Paint (FCP) y Tiempo hasta 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 que el visitante comienza a navegar a una página (por ejemplo, al hacer 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 difícil o incluso imposible.
Un TTFB alto puede deberse a varios redireccionamientos del servidor, visitantes que se encuentran lejos del servidor del sitio más cercano, visitantes con condiciones de red deficientes o a la incapacidad de usar contenido almacenado en caché debido a parámetros de consulta.
Una vez que se comienza a renderizar una página, es posible que aparezca un procesamiento de imagen inicial (por ejemplo, el color de fondo), seguido de contenido (por ejemplo, el encabezado del sitio). FCP mide la apariencia del contenido inicial. El delta entre FCP y otras métricas puede ser muy revelador.
Un gran delta entre TTFB y FCP podría indicar que el navegador debe descargar muchos elementos que bloquean el procesamiento. También puede indicar que se requiere mucho trabajo para procesar cualquier contenido significativo; es un indicador clásico de un sitio que se basa en gran medida en la renderización del cliente.
Un delta grande entre FCP y LCP indica que el recurso LCP no está disponible de inmediato para que el navegador priorice (por ejemplo, texto o imágenes administradas por JavaScript, en lugar de estar disponibles en el HTML inicial) o que el navegador está completando otra tarea antes de mostrar el contenido LCP.
Cómo usar los datos de Lighthouse de PageSpeed Insights
La sección Lighthouse de PageSpeed Insights ofrece orientación para mejorar el LCP, pero primero debes verificar si el LCP proporcionado coincide en general con los datos de usuarios reales proporcionados por CrUX. Si Lighthouse y CrUX no están de acuerdo, es probable que CrUX proporcione una imagen más precisa de la experiencia del usuario. Asegúrate de que los datos de CrUX sean para tu página, no el origen completo, antes de tomar medidas al respecto.
Si Lighthouse y CrUX muestran valores de LCP que se deben mejorar, la sección 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 LCP de la siguiente manera:
Además de las Oportunidades para mejorar, puedes encontrar información de Diagnóstico que te ayudará a diagnosticar el problema. El diagnóstico del elemento de pintura con contenido más grande muestra un desglose útil de los distintos tiempos que componen el LCP:
A continuación, profundizaremos en estas subpartes.
Desglose de LCP
La optimización para LCP puede ser una tarea más compleja si PageSpeed Insights no te da la respuesta para mejorar esta métrica. En el caso de las tareas complejas, por lo general, 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 las subpartes más importantes y, luego, presentar recomendaciones específicas y prácticas recomendadas para optimizar cada parte.
La mayoría de las cargas de páginas suelen incluir una serie de solicitudes de red, pero con el fin de identificar oportunidades para mejorar el LCP, deberías comenzar por analizar solo dos:
- El documento HTML inicial
- El recurso LCP (si corresponde)
Si bien otras solicitudes en la página pueden afectar al LCP, estas dos solicitudes (específicamente las horas en que comienza y finaliza el recurso de LCP) revelan si tu página está optimizada para LCP o no.
Si quieres identificar el recurso LCP, puedes usar herramientas para desarrolladores (como PageSpeed Insights que mencionamos antes, las herramientas para desarrolladores de Chrome o WebPageTest) para determinar el elemento LCP. Allí puedes hacer coincidir la URL (nuevamente, si corresponde) que carga el elemento en una cascada de red de todos los recursos cargados por 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 obtener una página bien optimizada, te recomendamos que tu solicitud de recursos LCP comience a cargarse lo antes posible y que el elemento LCP se renderice lo más rápido posible después de que el recurso LCP termine de cargarse. Para ayudarte a visualizar si una página en particular cumple con este principio, puedes dividir el tiempo de LCP total 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 el momento en que 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 lleva 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 de los elementos
- Es el tiempo que transcurre desde que termina de cargarse el recurso LCP hasta que se renderiza por completo el elemento LCP.
El LCP de cada página se compone de estas cuatro subcategorías. No hay espacios ni superposición entre ellos, y se suman para alcanzar el tiempo LCP completo.
Cada página puede tener su valor de LCP desglosado en estas cuatro subpartes. No hay superposición ni brecha entre ellos. En conjunto, suman el tiempo LCP completo.
Para optimizar 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, solo cambiará el tiempo ahorrado en otra parte.
Por ejemplo, en la cascada de red anterior, si redujeras el tamaño del archivo de la imagen comprimiéndola más o cambiando a un formato más óptimo (como AVIF o WebP), se reduciría la duración de la carga del recurso, pero en realidad no mejoraría el LCP porque el tiempo solo cambiaría a la subparte retraso de renderización de elementos:
Esto se debe a que, en esta página, el elemento LCP se oculta hasta que el código JavaScript termina de cargarse y se revela todo 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 para las 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 quieres lograr estos tiempos lo más cerca posible de cero. Las otras dos partes involucran las solicitudes de red, que, por su naturaleza, toman 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 siempre dentro de 2.5 segundos, en realidad no importa cuáles sean las proporciones relativas. Sin embargo, si inviertes mucho tiempo innecesario en cualquiera de las partes del "retraso", será muy difícil alcanzar constantemente el objetivo de 2.5 segundos.
Esta es una buena forma de pensar en el desglose del tiempo de LCP:
- La gran mayoría del tiempo de LCP se debe dedicar a cargar el documento HTML y la fuente de LCP.
- Cualquier momento antes del LCP en el que uno de estos dos recursos no se está cargando es una oportunidad de mejorar.
Cómo optimizar cada parte
Ahora que comprendes cómo se debe desglosar cada uno de los tiempos de las subpartes de LCP en una página bien optimizada, puedes comenzar a optimizar tus propias páginas.
Las siguientes cuatro secciones presentarán recomendaciones y prácticas recomendadas para optimizar cada parte. Se presentan en orden, comenzando con las optimizaciones que probablemente tengan el mayor impacto.
1. Elimina el retraso de carga de recursos.
El objetivo de este paso es garantizar que el recurso LCP comience a cargarse lo antes posible. Si bien, en teoría, lo primero que podría comenzar a cargar un recurso es inmediatamente después del TTFB, en la práctica, siempre hay un retraso antes de que los navegadores comiencen a cargar recursos.
Como regla general, el recurso LCP debería comenzar a cargarse al mismo tiempo que el primer recurso cargado en esa página. O, para decirlo de otra manera, si el recurso LCP comienza a cargarse más tarde que el primer recurso, entonces hay una oportunidad para mejorar.
En términos generales, hay dos factores que afectan la rapidez con la que se puede cargar un recurso LCP:
- Cuando se descubre el recurso.
- La prioridad que se le da al recurso.
Optimizar cuando se descubra el recurso
Para asegurarte de que tu recurso 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 escanear la respuesta del documento HTML para detectar el recurso LCP:
- El elemento LCP es un elemento
<img>, y sus atributossrcosrcsetestán presentes en el lenguaje de marcado HTML inicial. - El elemento LCP requiere una imagen de fondo 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. 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 LCP a partir del escaneo de la respuesta del documento HTML:
- El elemento LCP es una
<img>que se agrega de forma dinámica a la página a través de 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 generalmente implica esperar a que finalicen las solicitudes de red) para poder descubrir el recurso LCP y comenzar a cargarlo. Esto nunca es óptimo.
Para eliminar una demora innecesaria en la carga de recursos, tu 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 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">
Optimizar la prioridad que se le da al recurso
Incluso si el recurso LCP es detectable desde el lenguaje de marcado HTML, es posible que de todos modos no comience a cargarse tan pronto como sea el primer recurso. Esto puede suceder 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 tu imagen LCP con HTML si configuras loading="lazy" en el elemento <img>. El uso de la carga diferida implica que el recurso no se cargará hasta que el diseño confirme que la imagen se encuentra en el viewport, por lo que puede comenzar a cargarse más tarde de lo que lo haría de otra forma.
Incluso sin la carga diferida, los navegadores no cargan al principio las imágenes con la prioridad más alta, ya que no son recursos que bloqueen la representación. Puedes indicarle al navegador qué recursos son más importantes usando 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 establezcas 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 la configuración de prioridad no sea útil para reducir el LCP.
También puedes reducir la prioridad de las imágenes que podrían estar al principio de la respuesta del documento, pero no son visibles debido al estilo, como las imágenes en diapositivas de carrusel que no son visibles al inicio:
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
Quitar la prioridad de ciertos recursos puede permitirse más ancho de banda para aquellos que lo necesitan más, pero ten cuidado. Verifica siempre la prioridad de los recursos en Herramientas para desarrolladores y prueba los cambios con herramientas de lab y de campo.
Después de optimizar la prioridad de los recursos LCP y el tiempo de detección, la cascada de la red debería verse de la siguiente manera (el recurso LCP comienza 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 inmediatamente después de que su recurso termine de cargarse, sin importar cuándo suceda.
El motivo principal por el que el elemento LCP no podría renderizarse inmediatamente después de que termina de cargarse su recurso es si la renderización está bloqueada por alguna otra razón:
- La renderización de toda la página está bloqueada debido a que aún se están cargando las hojas de estilo o las secuencias de comandos síncronas de
<head>. - El recurso LCP terminó de cargarse, pero aún no se agregó el elemento LCP al DOM (espera a que se cargue un código de JavaScript).
- Otro código oculta el elemento, como una biblioteca de pruebas A/B que aún determina en qué experimento debería participar 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 retrasos en la renderización innecesaria de elementos.
Reducir o intercalar las hojas de estilo que bloquean el procesamiento
Las hojas de estilo cargadas desde el lenguaje de marcado HTML bloquearán la renderización de todo el contenido que las sigue, lo que es bueno, ya que generalmente no es conveniente renderizar HTML sin estilo. Sin embargo, si la hoja de estilo es tan grande que tarda mucho más en cargarse que el recurso LCP, evitará que se renderice el elemento LCP, incluso después de que haya terminado de cargarse el recurso, como se muestra en este ejemplo:
Para solucionar este problema, tienes las siguientes opciones:
- Integra 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, esta función solo se recomienda si la hoja de estilo es pequeña, ya que el contenido intercalado en el HTML no puede beneficiarse del almacenamiento en caché en las cargas de página posteriores. 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 representación del elemento LCP es reducir su tamaño de modo que sea más pequeño que el recurso LCP. De este modo, no se genere un cuello de botella para la mayoría de las visitas.
A continuación, se incluyen algunas recomendaciones para reducir el tamaño de la hoja de estilo:
- Quita el código CSS sin usar: Usa las Herramientas para desarrolladores de Chrome para buscar las reglas de CSS que no se usen y que posiblemente se puedan quitar (o aplazar).
- Aplaza la hoja de estilo que no sea fundamental: Divide la hoja de estilo en los estilos que sean necesarios para la carga inicial de la página y, luego, los estilos que se puedan cargar de forma diferida.
- Minifica y comprime el CSS: En el caso de los estilos críticos, asegúrate de reducir el tamaño de transferencia tanto como sea posible.
Difiere o intercala el código JavaScript que bloquea el procesamiento
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 deba ejecutarse lo antes posible en la carga de la página, es mejor integrarlo para que la renderización no se retrase a la espera de otra solicitud de red. Sin embargo, al igual que con las hojas de estilo, 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>
Cómo usar la renderización del servidor
La renderización del servidor (SSR) es el proceso de ejecutar la lógica de la aplicación del cliente en el servidor y responder a las solicitudes de documentos HTML con todo el lenguaje de marcado HTML.
Desde la perspectiva de la optimización del LCP, la SSR tiene dos ventajas principales:
- Tus recursos de imagen serán detectables desde la fuente HTML (como se explicó en el paso 1 anterior).
- El contenido de tu página no requerirá solicitudes de JavaScript adicionales para finalizar antes de que se pueda renderizar.
La principal desventaja de SSR es que requiere más tiempo de procesamiento del servidor, lo que puede ralentizar tu TTFB. Sin embargo, esta compensación suele valer la pena porque tú controlas los tiempos de procesamiento del servidor, mientras que las capacidades de la red y del dispositivo de tus usuarios no lo están.
Una opción similar a la SSR se conoce como 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 a pedido. Si es posible realizar la renderización previa con tu arquitectura, en general, será una mejor opción en lo que respecta al rendimiento.
Divide las tareas largas
Incluso si seguiste los consejos de antes y tu código JavaScript no bloquea el procesamiento ni es responsable de renderizar los elementos, puede retrasar el LCP.
El motivo más común es cuando las páginas cargan archivos JavaScript de gran tamaño, que se deben analizar y ejecutar en el subproceso principal del navegador. Esto significa que, incluso si tu recurso de imagen se descargó por completo, es posible que debas esperar hasta que una secuencia de comandos no relacionada termine de ejecutarse para poder renderizarse.
Actualmente, todos los navegadores procesan imágenes en el subproceso principal, lo que significa que cualquier cosa que bloquee el subproceso principal también puede generar un retraso innecesario en la renderización de los elementos.
3. Reduce la duración de la carga de recursos
El objetivo de este paso es reducir el tiempo dedicado a transferir bytes del recurso al dispositivo del usuario por medio de la red. En general, hay tres maneras de hacerlo:
- Reduce el tamaño del recurso.
- Reduce la distancia que el recurso tiene que recorrer.
- Reduce la contención del ancho de banda de red.
- Elimina el tiempo de la red por completo.
Reduce el tamaño del recurso
El recurso LCP de una página (si tiene) será una imagen o una fuente web. En las siguientes guías, se explica detalladamente cómo reducir el tamaño de ambos:
- Publica el tamaño de imagen óptimo
- Usa formatos de imagen modernos
- Comprime imágenes
- Cómo reducir el tamaño de fuente web
Reduce la distancia que el recurso tiene para recorrer
Además de reducir el tamaño de un recurso, también puedes disminuir los tiempos de carga si acercas tus servidores geográficamente a tus usuarios. La mejor manera de hacerlo es usar una red de distribución de contenidos (CDN).
En particular, las CDN de imágenes son especialmente útiles porque no solo reducen la distancia que debe recorrer el recurso, sino que, en general, también reducen su tamaño, ya que implementan automáticamente todas las recomendaciones de reducción de tamaño que se mencionaron anteriormente.
Cómo reducir la contención del ancho de banda de red
Incluso si reduces el tamaño del recurso y la distancia que tiene para recorrer, un recurso puede tardar mucho tiempo en cargarse si cargas muchos otros recursos al mismo tiempo. Este problema se conoce como contención de red.
Si le otorgaste a tu recurso LCP un 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 una fetchpriority alta o si solo cargas muchos recursos en general, podría afectar la rapidez con la que se carga el recurso LCP.
Elimina el tiempo de la red por completo
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 entregarán desde la caché, lo que hace que la duración de la carga de recursos sea esencialmente cero.
Si tu recurso LCP es una fuente web, además de reducir el tamaño de fuente web, también debes considerar si necesitas bloquear la representación en la carga de recursos de fuente web. Si configuras un valor font-display que no sea auto ni block, el texto siempre estará visible durante la carga y el LCP no se bloqueará en una solicitud de red adicional.
Por último, si tu recurso 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, usar URLs de datos tiene limitaciones porque los recursos no se pueden almacenar en caché y, en algunos casos, pueden generar retrasos en la renderización más prolongadas debido al costo de decodificación adicional.
4. Reduce el tiempo hasta el primer byte
El objetivo de este paso es publicar el código HTML inicial lo más rápido posible. Este paso aparece en el último lugar porque suele ser el que los desarrolladores tienen menos control. Sin embargo, también es uno de los pasos más importantes porque afecta directamente cada paso posterior. No puede ocurrir nada en el frontend hasta que el backend entregue ese primer byte de contenido, por lo que todo lo que puedas hacer para acelerar tu TTFB también mejorará todas las demás métricas de carga.
Una causa común de que el TTFB sea lento en un sitio que suele ser rápido son los visitantes que llegan mediante varios redireccionamientos, por ejemplo, desde anuncios o vínculos acortados. Siempre minimiza la cantidad de redireccionamientos por los que un visitante debe esperar.
Otra causa común es que el contenido almacenado en caché no se puede usar desde un servidor perimetral de CDN y todas las solicitudes deben dirigirse hasta el servidor de origen. Esto puede suceder si los visitantes utilizan parámetros de URL únicos para obtener estadísticas, incluso si no conducen a páginas diferentes.
Para obtener orientación específica sobre cómo optimizar el TTFB, consulta la guía de optimización de TTFB.
Desglose de LCP de supervisión en JavaScript
La información de sincronización para todas las subpartes de LCP que se analizaron antes se encuentra 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 con el objetivo 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 Tiempos en el panel Rendimiento de Herramientas para desarrolladores de Chrome.
Las visualizaciones del segmento Timing son particularmente útiles cuando se observan junto con las pistas Red y Subproceso principal, porque puedes ver a simple vista lo más que sucede en la página durante estos períodos.
Además de visualizar las subpartes del LCP en la pista de sincronización, 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 porcentuales recomendados descritos anteriormente.
En esta captura de pantalla, se muestra un ejemplo que registra el tiempo total de cada subparte de LCP, así como su porcentaje del tiempo total de LCP a 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 una depuración local o modificarlo para enviar estos datos a un proveedor de estadísticas y comprender mejor el desglose del LCP de tus páginas para usuarios reales.
Supervisa desgloses de LCP con la extensión de Métricas web
La extensión de métricas web registrará el tiempo del LCP, el elemento de LCP y estas cuatro subpartes en la consola para que puedas ver este desglose con facilidad.
Resumen
El LCP es complejo y su sincronización puede verse afectada por varios factores. Sin embargo, si consideras que la optimización del LCP se trata principalmente de optimizar la carga del recurso de LCP, esto puede simplificar mucho las cosas.
En términos generales, la optimización de LCP se puede resumir en cuatro pasos:
- Asegúrate de que el recurso LCP comience a cargarse lo antes posible.
- Asegúrate de que el elemento LCP se pueda renderizar en cuanto su recurso termine de cargarse.
- Reduce el tiempo de carga del recurso LCP tanto como puedas sin sacrificar la calidad.
- Envía el documento HTML inicial lo más rápido posible.
Si puedes seguir estos pasos en tus páginas, deberías tener la certeza de que estás brindando una experiencia de carga óptima a tus usuarios, y deberías ver eso reflejado en tus puntuaciones del LCP del mundo real.