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 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 que transcurre desde que el usuario comienza a cargar la página hasta que se renderiza el bloque de imagen o texto más grande en el 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 observar lo que experimentan los usuarios reales, en lugar de lo que muestran las pruebas locales o una herramienta basada en laboratorios, como Lighthouse. 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 pueden obtenerse a partir de herramientas de supervisión de usuarios reales (RUM) instaladas en un sitio o mediante el Chrome User Experience Report (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 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. Los datos más detallados basados en pruebas de laboratorio están disponibles en la sección inferior titulada Cómo diagnosticar problemas de rendimiento. Si los datos de CrUX están disponibles para tu sitio web, concéntrate siempre en los datos del usuario real.
PageSpeed Insights muestra hasta cuatro datos de CrUX diferentes:
- Datos de dispositivos móviles para Esta URL
- Datos de Computadoras para Esta URL
- Datos de dispositivos móviles para todo el origen
- Datos de computadoras para todo Origin
Puedes activarlas o desactivarlas en los controles de la parte 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 carga 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. 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.
Analizar 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 si es un problema más general de todo el sitio. De manera similar, 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.
El TTFB es el tiempo que transcurre desde que el visitante comienza a navegar a una página (por ejemplo, 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 de servidor, visitantes ubicados lejos del servidor del sitio más cercano, visitantes en condiciones de red deficientes o la imposibilidad de utilizar el contenido almacenado en caché debido a los 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. El delta entre el FCP y otras métricas puede ser muy revelador.
Un gran delta entre el TTFB y el FCP podría indicar que el navegador necesita descargar muchos elementos que bloquean la renderización. También puede ser un indicador de que debe realizar mucho trabajo para renderizar 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 de LCP.
Cómo usar datos de Lighthouse de PageSpeed Insights
La sección Lighthouse de PageSpeed Insights ofrece orientación para mejorar el LCP, pero primero debes comprobar si el LCP proporcionado está ampliamente de acuerdo con los datos del usuario 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. 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 las maneras de mejorar el LCP. Usa el filtro LCP para mostrar solo las auditorías relevantes para el LCP 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 Largest Contentful Paint muestra un desglose útil de los distintos tiempos que componen 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, por lo general, es mejor dividirlas en tareas más pequeñas y manejables, y abordar cada una por separado.
En esta sección, se presenta una metodología para desglosar el LCP en sus 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 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 mencionamos antes, las Herramientas para desarrolladores de Chrome o WebPageTest) para determinar el elemento LCP. Desde allí, puedes hacer coincidir la URL (otra vez, si corresponde) cargada por el elemento en una cascada de red de todos los recursos cargados por la página.
Por ejemplo, la siguiente visualización muestra 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, te recomendamos 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 el recurso de LCP termine de cargarse. 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)
- El tiempo que transcurre desde que el usuario comienza a cargar 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 de LCP no requiere una carga de recursos para su renderización (por ejemplo, si el es un nodo de texto renderizado con una fuente de sistema), esta vez es 0.
- Duración de la carga de recursos
- Es la duración que tarda en cargarse el recurso de LCP. Si el elemento LCP no requiere una carga de recursos para renderizarse, este tiempo es 0.
- Retraso en la renderización del elemento
- El tiempo que transcurre entre el momento en que el recurso LCP termina de cargarse y el elemento de LCP por completo.
El LCP de cada página consta de estas cuatro subcategorías. No hay brechas ni superposiciones. entre ellas y suman el tiempo de 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 total de la LCP.
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 cambiará 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 cambiándola a un formato más óptimo (como AVIF o WebP), se reduciría la duración de carga de recursos, pero no mejoraría el LCP porque el tiempo solo cambiaría a la subparte del retraso de renderización de elementos:
Esto sucede porque, en esta página, el elemento LCP se oculta hasta que el código JavaScript termina de cargarse y, luego, todo 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 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 "retraso". 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 solo lineamientos, no reglas estrictas. Si los tiempos de LCP de tus páginas son constantemente de 2.5 segundos, 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 forma de analizar el desglose del tiempo de LCP es:
- 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 cargue 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.
Las próximas cuatro secciones 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 de 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, lo primero que podría comenzar a cargarse un recurso es inmediatamente después del TTFB, en la práctica siempre hay un retraso antes de que los navegadores comiencen a cargar los recursos.
Una buena regla general es que tu recurso de LCP debe comenzar a cargarse al mismo tiempo que el primer recurso que carga 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:
- Cuando se descubre el recurso.
- La prioridad que se le da 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 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 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 generalmente implica esperar a que finalicen las solicitudes de red) antes de descubrir el recurso 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 que solo se haga referencia al recurso desde un archivo externo CSS o JavaScript, el recurso LCP se debe precargar 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 de LCP se puede detectar desde el marcado HTML, es posible que no comience a cargarse tan pronto como el primer recurso. Esto puede ocurrir si las heurísticas de prioridad del escáner de carga previa del navegador no reconocen 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 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, las imágenes no se cargan inicialmente con la prioridad más alta por los navegadores, ya que no son recursos que bloquean 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 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 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 y el tiempo de descubrimiento de tu recurso de LCP, tu cascada de red debería verse de la siguiente manera (con el recurso de LCP comenzando 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á renderizarse inmediatamente después de que termine de cargarse su recurso es que la renderización esté bloqueada por algún otro motivo:
- Se bloqueó la renderización de toda la página debido a que aún se están cargando las hojas de estilo o secuencias de comandos síncronas en
<head>. - 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.
En las siguientes secciones, se explica cómo abordar las causas más comunes de retrasos innecesarios 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 lenguaje de marcado HTML bloquearán la representación de todo el contenido que le sigue, lo cual es bueno, ya que, por lo general, no se recomienda 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 su recurso haya terminado de cargarse, como se muestra en este ejemplo:
Para solucionarlo, tienes las siguientes opciones:
- insertar la hoja de estilo en el código HTML para evitar solicitudes de red adicionales o
- reduce el tamaño de la hoja de estilo.
En general, solo se recomienda intercalar la hoja de estilo si es pequeña, ya que el contenido intercalado en el HTML no puede beneficiarse de la caché en cargas de páginas 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 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 código CSS que no sea crítico: Divide tu hoja de estilo en los estilos necesarios para la carga inicial de la página y, luego, los estilos que se pueden 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 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 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 las hojas de estilo, solo debes insertar 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 el procesamiento 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 el lenguaje de marcado HTML completo.
Desde la perspectiva de la optimización de la LCP, SSR tiene dos ventajas principales:
- 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 de JavaScript adicionales para finalizar antes de que se pueda renderizar.
La principal desventaja del SSR es que requiere tiempo de procesamiento adicional del servidor, lo que puede ralentizar el 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 la red y del dispositivo de tus usuarios no lo están.
Una opción similar a la SSR se denomina generación de sitios estáticos (SSG) o renderización previa. Este es el proceso de generar las páginas HTML en un paso de compilación en lugar de hacerlo a pedido. Si es posible realizar la renderización previa con tu arquitectura, por lo general, es 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.
En la actualidad, todos los navegadores renderizan imágenes en el subproceso principal, lo que significa que cualquier elemento que bloquee este subproceso 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 que se dedica a transferir los bytes del recurso a través de la red al dispositivo del usuario. En general, existen tres formas de hacerlo:
- Reduce el tamaño del recurso.
- Reduce la distancia que debe recorrer el recurso.
- Reduce la contención del ancho de banda de 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 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, por lo general, reducen su tamaño, lo que implementa automáticamente todas las recomendaciones de reducción de tamaño anteriores para ti.
Cómo reducir la contención del 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 cargas 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 una fetchpriority alta, o si solo cargas muchos recursos en general, esto podría afectar la velocidad de carga del 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 publicarán desde la caché, lo que lleva la duración de carga de recursos a casi cero.
Si tu recurso de LCP es una fuente web, además de reducir el tamaño de fuente web, también deberías considerar si necesitas bloquear la renderización en la carga de recursos de fuentes 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, puede ser conveniente 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 viene con advertencias porque los recursos no se pueden almacenar en caché y, en algunos casos, puede provocar demoras en la renderización más largas 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 ú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 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 hasta el 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.
Supervisa 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 Timing en el panel de rendimiento de Herramientas para desarrolladores de Chrome.
Las visualizaciones en el segmento Timing son especialmente útiles cuando se analizan junto con los segmentos Network y Main thread, ya que puedes observar a simple vista lo que 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 anteriormente.
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.
Supervisa los desgloses de LCP con las Herramientas para desarrolladores de Chrome
Chrome DevTools registrará el tiempo de LCP, el elemento de LCP y estas cuatro subpartes en tiempo real para que puedas ver este desglose.
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 el elemento LCP se pueda renderizar en cuanto termine de cargarse su recurso.
- Reduce el tiempo de carga del recurso de 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 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.