El Largest Contentful Paint (LCP) es una de las tres métricas de Métricas web esenciales. Representa la rapidez con la que se carga el contenido principal de una página web, en concreto, 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 dentro del viewport.
Para brindar una buena experiencia del usuario, los sitios deben 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 una corrección rápida en una sola parte de una 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 comprender si su sitio tiene un problema de LCP y, de ser así, en qué medida.
Varias herramientas pueden medir el LCP, pero no todas lo hacen de la misma manera. Para comprender la experiencia de LCP de los usuarios reales, debes comprender lo que los usuarios reales experimentan, en lugar de solo lo que puede mostrar una herramienta basada en labs, como Lighthouse o las pruebas locales. Estas herramientas basadas en labs pueden proporcionar una gran cantidad de información para explicar el LCP y ayudarte a mejorar tus métricas. Sin embargo, las pruebas de lab por sí solas no son totalmente representativas de lo que experimentan los usuarios.
Puedes mostrar datos de LCP basados en usuarios reales de 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 datos de CrUX en PageSpeed Insights
PageSpeed Insights proporciona acceso a datos de CrUX en la sección Descubre lo que experimentan tus usuarios reales. En la sección Diagnostica problemas de rendimiento, encontrarás datos más detallados basados en labs. Enfócate siempre en los datos de CrUX si están disponibles.
Cuando CrUX no proporciona datos (por ejemplo, en el caso de una página con tráfico insuficiente para obtener datos a nivel de la página), puedes complementar CrUX con datos de RUM recopilados mediante las APIs de JavaScript que se ejecutan en la página. Esto también puede proporcionar muchos más datos de los que CrUX puede exponer como un conjunto de datos públicos. Más adelante en esta guía, explicaremos cómo recopilar estos datos con JavaScript.
Datos de LCP
PageSpeed Insights muestra hasta cuatro conjuntos de 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 activar o desactivar estos controles con los controles de la parte superior y derecha de esta sección. Si una URL no tiene suficientes datos para mostrarlos 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 otras páginas de ese origen. También puede verse afectada por la forma en que los visitantes navegan a estas páginas. Los usuarios nuevos suelen visitar las páginas principales y, por lo tanto, a menudo se cargan sin contenido almacenado en caché, lo que las convierte en 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.
Métricas complementarias
Los desarrolladores que trabajan en la optimización del LCP también pueden usar los tiempos del primer procesamiento de imagen con contenido (FCP) y del 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 transcurre desde 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 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 en condiciones de red deficientes o la incapacidad de usar contenido almacenado en caché debido a los parámetros de consulta.
Una vez que se comienza a renderizar una página, es posible que se muestre 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, y la diferencia entre FCP y otras métricas puede ser muy reveladora.
Una gran diferencia entre TTFB y FCP puede indicar que el navegador debe descargar muchos recursos de bloqueo de renderización. También puede indicar que el navegador debe completar mucho trabajo para renderizar contenido significativo, lo que sugiere que el sitio depende en gran medida de la renderización del cliente.
Una gran diferencia 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 debe completar otra tarea antes de mostrar el contenido del LCP.
Cómo usar los datos de Lighthouse de PageSpeed Insights
En la sección Lighthouse de PageSpeed Insights, se ofrece orientación para mejorar el LCP, pero primero debes verificar si el LCP proporcionado generalmente coincide con los datos de usuarios reales que proporciona CrUX. Si Lighthouse y CrUX no están de acuerdo, es probable que CrUX proporcione un panorama más preciso 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, hay información de Diagnóstico que puede proporcionar más información que ayude a diagnosticar el problema. El diagnóstico del elemento de pintura con contenido más grande muestra un desglose útil de los diversos tiempos que componen el LCP:
En la siguiente sección, se exploran las subcategorías de LCP con más detalle.
Desglose de LCP
En esta sección, se presenta una metodología en la que se desglosa el LCP en las subcategorías más importantes, junto con recomendaciones específicas y prácticas recomendadas para optimizar cada subcategoría.
La mayoría de las cargas de páginas suelen incluir varias solicitudes de red, pero con el objetivo de identificar oportunidades para mejorar el LCP, te recomendamos que comiences solo con el documento HTML inicial y, si corresponde, con el recurso LCP.
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.
Para identificar el recurso LCP, puedes usar herramientas para desarrolladores, como PageSpeed Insights, las herramientas para desarrolladores de Chrome o WebPageTest, para determinar el elemento LCP. Desde allí, puedes hacer coincidir la URL (si corresponde) que carga el elemento en una cascada de red de todos los recursos que carga 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 la 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 sigue este principio, puedes desglosar el tiempo total de LCP en las siguientes subcategorías:
- 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.
- Tiempo de carga del recurso
- Es el tiempo que tarda en cargarse el recurso LCP. Si el elemento 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.
Cuando se optimiza el LCP, es útil intentar optimizar estas subcategorías. Sin embargo, debes asegurarte de que todas estén optimizadas, ya que algunas optimizaciones cambian el tiempo ahorrado de una parte a otra en lugar de reducir realmente el LCP.
Por ejemplo, en el ejemplo de la cascada de red, reducir el tamaño del archivo de la imagen comprimiendo más la imagen o cambiando a un formato más óptimo (como AVIF o WebP) reduciría el tiempo de carga de recursos, pero no mejoraría el LCP porque ese tiempo se vuelve parte del retraso de renderización del elemento. Esto se debe a que el elemento LCP está oculto hasta que su JavaScript asociado termina de cargarse, después de lo cual se revela.
Tiempos óptimos de subcategoría
Para optimizar cada subcategoría de LCP, es importante comprender cuál es el desglose ideal de estas subcategorías en una página bien optimizada.
Las dos subcategorías que involucran retrasos deben reducirse lo más posible. Las otras dos involucran solicitudes de red, que requieren tiempo y no se pueden optimizar por completo.
La siguiente es una distribución LCP idealizada.
Estos tiempos son lineamientos, no reglas estrictas. Si los tiempos de LCP de tus páginas son constantemente de 2.5 segundos o menos, no importa en realidad cómo se ve el desglose. Sin embargo, si tus categorías de demora son innecesariamente largas, tendrás problemas para alcanzar el objetivo de 2.5 segundos.
Te recomendamos que consideres el desglose del tiempo de LCP de la siguiente manera:
- La gran mayoría del tiempo 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 para mejorar.
Cómo optimizar cada categoría
Ahora que comprendes cómo se ven los tiempos de la subcategoría LCP en una página bien optimizada, puedes comenzar a optimizar tus propias páginas.
En las siguientes secciones, se presentan sugerencias y prácticas recomendadas para optimizar cada categoría. Comienza con las optimizaciones que pueden tener el mayor impacto.
Elimina el retraso en la 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, el primer recurso puede 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 asegurarte de que tu recurso LCP se inicie al mismo tiempo que el primer recurso que carga la página.
En términos generales, hay dos factores que afectan la velocidad 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 garantizar que tu recurso LCP comience a cargarse lo antes posible, el análisis de precarga del navegador debe poder detectar ese recurso en la respuesta inicial del documento HTML. Algunos ejemplos de recursos LCP detectables incluyen los siguientes:
- Un elemento
<img>cuyos atributossrcosrcsetestán en el lenguaje de marcado HTML inicial - Cualquier elemento que requiera una imagen de fondo de CSS, siempre que esa imagen esté precargada con
<link rel="preload">en el lenguaje de marcado HTML (o con un encabezadoLink). - Un nodo de texto que requiere una fuente web para renderizarse, siempre que la fuente esté precargada con
<link rel="preload">en el lenguaje de marcado HTML (o con un encabezadoLink).
Estos son algunos recursos de LCP que no se pueden descubrir mediante el análisis de la respuesta del documento HTML. En cada caso, el navegador debe ejecutar una secuencia de comandos o aplicar una hoja de estilo antes de poder detectar y comenzar a cargar el recurso LCP, por lo que debe esperar a que finalicen las solicitudes de red.
- Un elemento
<img>que se agrega de forma dinámica a la página a través de JavaScript - Cualquier elemento que se cargue de forma diferida con una biblioteca de JavaScript que oculte sus atributos
srcosrcset(a menudo, comodata-srcodata-srcset) - Cualquier elemento que requiera una imagen de fondo CSS.
Para evitar una demora innecesaria en la carga de recursos, tu recurso LCP debe ser detectable desde la fuente HTML. En los casos en que solo se haga 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 análisis 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 estableces loading="lazy" en el 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, lo que a menudo hace que se cargue más tarde.
Incluso sin la carga diferida, los navegadores no cargan al principio imágenes con prioridad alta porque no son recursos que bloqueen la renderización. Puedes aumentar la prioridad de carga de un recurso con el atributo fetchpriority de la siguiente manera:
<img fetchpriority="high" src="/path/to/hero-image.webp">
Se recomienda establecer 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 diseño, 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 proporcionar más ancho de banda a los que lo necesitan más, pero ten cuidado de no excederte. Verifica siempre la prioridad de los recursos en DevTools y prueba tus cambios con las 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 verse de la siguiente manera, en la que el recurso de LCP comienza al mismo tiempo que el primer recurso:
Punto clave: Otro motivo por el que es posible que tu recurso LCP no comience a cargarse lo antes posible, incluso cuando sea detectable desde la fuente HTML, es que esté alojado en un origen diferente al que se debe conectar el navegador para poder comenzar a cargar el recurso. Cuando sea posible, te recomendamos que alojes recursos críticos en el mismo origen que tu recurso de documento HTML, de modo que el navegador pueda reutilizar la conexión existente y ahorrar tiempo (más información sobre este punto más adelante).
Elimina el retraso de 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.
La razón principal por la que el elemento LCP no podría renderizarse inmediatamente después de que su recurso termine de cargarse 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 en
<head>. - El recurso LCP terminó de cargarse, pero el elemento LCP aún no se agregó al DOM porque está esperando que se cargue el código JavaScript.
- El elemento está oculto por otro código, como una biblioteca de pruebas A/B que aún no decidió en qué grupo experimental poner al 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 innecesarios en la renderización de elementos.
Incorpora o reduce las hojas de estilo que bloquean el procesamiento del contenido
Hojas de estilo cargadas desde la renderización del bloque de lenguaje de marcado HTML de todo el contenido que las sigue. Por lo general, esto es bueno, ya que permite que la hoja de estilo tenga efecto antes de que se carguen otros elementos. 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 termine de cargarse su recurso, como se muestra en este ejemplo:
Para solucionar este problema, puedes hacer lo siguiente:
- 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.
La intercalación de la hoja de estilo solo es eficaz para reducir el LCP si la hoja es pequeña. Sin embargo, si la hoja de estilo tarda más en cargarse que tu recurso de LCP, es probable que sea demasiado grande para intercalarla de manera efectiva, por lo que te recomendamos que reduzcas la complejidad de tu hoja de estilo de la siguiente manera:
- Quita el código CSS sin usar: Usa las Herramientas para desarrolladores de Chrome para encontrar las reglas de CSS que no se usen y que se puedan quitar (o aplazar).
- Aplaza el CSS que no sea fundamental: Divide la hoja de estilo en diseños que servirán para cargar la página inicial y, luego, en los que se puedan cargar de forma diferida.
- Minifica y comprime CSS: En el caso de los diseños críticos, asegúrate de reducir su tamaño de transferencia tanto como sea posible.
Difiere o intercala el código JavaScript que bloquea el procesamiento
Te recomendamos que todas las secuencias de comandos de tus páginas sean asíncronas mediante los atributos async o defer. El uso de secuencias de comandos síncronas casi siempre es malo para el rendimiento.
Sin embargo, si tienes JavaScript que debe ejecutarse lo antes posible en la carga de la página, puedes mejorar el LCP si insertas secuencias de comandos pequeñas para reducir el tiempo que el navegador pasa esperando solicitudes de red.
<head>
<script>
// Inline script contents directly in the HTML.
// IMPORTANT: only do this for very small scripts.
</script>
</head>
<head> <script src="/path/to/main.js"></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.
La SSR ayuda a optimizar el LCP de las siguientes maneras:
- Hace que tus recursos sean detectables desde la fuente HTML, como se describe en Cómo eliminar la demora en la carga de recursos.
- Evita que tu página necesite 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.
También te recomendamos generar tus páginas HTML en un paso de compilación en lugar de a pedido para obtener un mejor rendimiento. Esta práctica se denomina generación de sitios estáticos (SSG) o renderización previa.
Divide las tareas largas
Incluso si seguiste todos estos consejos 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 que cuando una página carga un archivo JavaScript grande, el navegador tarda en analizar y ejecutar el código en su subproceso principal. Esto significa que, incluso si el recurso LCP se descargó por completo, es posible que debas esperar para renderizarse hasta que termine de ejecutarse una secuencia de comandos no relacionada.
Todos los navegadores renderizan 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 elementos. Por lo tanto, te recomendamos dividir un archivo JavaScript grande en varios archivos de secuencia de comandos que se puedan analizar según sea necesario.
Reduce el tiempo de carga de los recursos
El objetivo de este paso es reducir el tiempo que el navegador pasa transfiriendo el recurso por la red al dispositivo del usuario. En general, hay varias 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
Los recursos LCP suelen ser imágenes o fuentes web. En las siguientes guías, se proporcionan detalles para 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
También puedes reducir los tiempos de carga si ubicas tus servidores lo más cerca posible a nivel geográfico de tus usuarios. La mejor manera de hacerlo es usar una red de distribución de contenidos (CDN).
De hecho, las CDN de imágenes son especialmente útiles porque reducen la distancia que el recurso tiene que recorrer y, a menudo, reducen el tamaño del recurso mediante las estrategias mencionadas anteriormente.
Punto clave: Las CDN de imágenes son una excelente forma de reducir los tiempos de carga de los recursos. Sin embargo, usar un dominio de terceros para alojar tus imágenes tiene un costo de conexión adicional. Si bien la preconexión al origen puede mitigar parte de este costo, la mejor opción es entregar imágenes desde el mismo origen que tu documento HTML. Para ello, muchas CDN te permiten usar servidores proxy en las solicitudes de tu origen a las de ellos.
Cómo reducir la contención del ancho de banda de red
Si tu página carga muchos recursos al mismo tiempo, es posible que cualquier recurso demore mucho tiempo en cargarse. Este problema se conoce como contención de red.
Si le diste a tu recurso LCP un fetchpriority alto y comenzaste a cargarlo lo antes posible, el navegador hace todo lo posible para evitar que los recursos de menor prioridad compitan con él. Sin embargo, cargar demasiados recursos a la vez puede afectar al LCP, en especial si muchos de esos recursos tienen un fetchpriority alto. Para reducir la contención de red, asegúrate de que los únicos recursos con fetchpriority alto sean los que necesitan cargarse más rápido.
Elimina el tiempo de la red por completo
La mejor manera de reducir los tiempos de carga de los recursos es eliminar por completo la red del proceso. Si entregas 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 reduce el tiempo de carga de los recursos a cero.
Si tu recurso de LCP es una fuente web, además de reducir el tamaño de fuente web, te recomendamos que consideres si necesitas bloquear la representación en la carga de recursos de fuente web.
Si configuras un valor font-display que no sea auto o block, el texto siempre es visible durante la carga, y el LCP no tiene que esperar una solicitud de red adicional.
Por último, si tu recurso de LCP es pequeño, podría tener sentido intercalar los recursos como un URI de datos para eliminar la solicitud de red adicional. Sin embargo, usar URI de datos tiene sus desventajas: evita que los recursos se almacenen en caché y, en algunos casos, puede causar retrasos de procesamiento más largos 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 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 a 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, como anuncios o vínculos acortados. Siempre minimiza la cantidad de redireccionamientos por los que un visitante debe esperar.
Otra causa común es cuando el contenido almacenado en caché no se puede usar desde un servidor perimetral de CDN, lo que requiere que todas las solicitudes se dirijan hasta el servidor de origen. Esto puede ocurrir si los visitantes utilizan parámetros de URL únicos para las estadísticas, incluso si no dirigen a los usuarios a páginas diferentes.
Si deseas obtener orientación específica para reducir el TTFB, consulta Cómo optimizar el TTFB.
Desglose de LCP de supervisión en JavaScript
La información de sincronización para todas las subcategorías de LCP está disponible en JavaScript mediante una combinación de las siguientes APIs de rendimiento:
Procesar estos valores de sincronización en JavaScript te permite enviarlos a un proveedor de estadísticas 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 de rendimiento de Herramientas para desarrolladores de Chrome:
Las visualizaciones del segmento de tiempos son particularmente útiles junto con las pistas de subprocesos principales y de red, que te permiten ver qué más sucede en la página durante estos períodos.
También puedes usar JavaScript para calcular el porcentaje del tiempo total de LCP que ocupa cada subcategoría y determinar si tus páginas cumplen con los desgloses porcentuales recomendados.
En esta captura de pantalla, se muestra un ejemplo que registra el tiempo total de cada subcategoría de LCP en la consola, así como su porcentaje del tiempo total de LCP.
Ambas visualizaciones se crearon con el siguiente código:
const LCP_SUB_PARTS = [
'Time to first byte',
'Resource load delay',
'Resource load time',
'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 de qué se trata el desglose de LCP de tus páginas para usuarios reales.
Supervisa el desglose de LCP con la extensión de Métricas web
La extensión de Métricas web registra el tiempo de LCP, el elemento de LCP y las cuatro subcategorías en el registro de la consola para mostrar este desglose.
