Optimice Largest Contentful Paint
Cómo renderizar su contenido principal más rápido.
No puedo ver ningún contenido útil. ¿Por qué tarda tanto en cargar? 😖
Uno de los factores que contribuyen a una mala experiencia de usuario es el tiempo que tarda el usuario en ver cualquier contenido renderizado en la pantalla. First Contentful Paint: Primer despliegue del contenido (FCP) mide el tiempo que tarda en renderizarse el contenido del DOM inicial, pero no captura el tiempo que tarda en renderizarse el contenido más grande (generalmente más significativo) de la página.
Largest Contentful Paint : Despliegue del contenido más extenso (LCP) es una métrica de Core Web Vitals y mide cuándo se hace visible el elemento de contenido más grande en la ventana de visualización. Puede utilizarse para determinar cuándo el contenido principal de la página terminó la renderización en la pantalla.
Las causas más comunes de una LCP deficiente son:
- Tiempos de respuesta lentos del servidor
- JavaScript y CSS bloquean la renderización
- Tiempos de carga de recursos lentos
- Renderización del lado del cliente
Tiempos de respuesta lentos del servidor #
Cuanto más tarda un navegador en recibir el contenido del servidor, más tiempo tarda en renderizar cualquier cosa en la pantalla. Un tiempo de respuesta del servidor más rápido mejora directamente cada métrica de carga de la página, incluido el LCP.
Antes que nada, mejore cómo y dónde su servidor maneja su contenido. Utilice Time to First Byte: Tiempo hasta el primer byte (TTFB) para medir los tiempos de respuesta de su servidor. Puede mejorar su TTFB de varias formas:
- Optimizar su servidor
- Enrutar a los usuarios a una CDN cercana
- Activos del caché
- Publicar las páginas HTML en cache-first
- Establecer conexiones con terceros con anticipación
- Utilizar intercambios firmados
Optimizar su servidor #
¿Ejecuta consultas costosas que le toman a su servidor una cantidad significativa de tiempo en completar? ¿O hay otras operaciones complejas en el lado del servidor que retrasan el proceso para devolver el contenido de la página? Analizar y mejorar la eficiencia de su código del lado del servidor mejorará directamente el tiempo que tarda el navegador en recibir los datos.
En vez de publicar inmediatamente una página estática cuando el navegador la solicita, muchos frameworks web del lado del servidor necesitan crear la página web de forma dinámica. En otras palabras, en vez de enviar un archivo HTML completo que ya está listo cuando el navegador lo solicita, los frameworks necesitan ejecutar la lógica para crear la página. Esto podría deberse a los resultados pendientes de una consulta a la base de datos o incluso porque los componentes se deben generar en el marcado por un framework de interfaz de usuario (como React). Muchos frameworks web que se ejecutan en el servidor tienen una guía de rendimiento que se puede utilizar para acelerar este proceso.
Enrutar a los usuarios a una CDN cercana #
Una Red de distribución de contenidos (CDN) es una red de servidores que se distribuyen en diferentes ubicaciones. Si el contenido de su página web se aloja en un solo servidor, su sitio web se cargará más lentamente para los usuarios que se encuentren geográficamente más lejos, porque las solicitudes de su navegador literalmente tienen que viajar por todo el mundo. Considere la posibilidad de utilizar una CDN para garantizar que sus usuarios nunca tengan que esperar las solicitudes de red a servidores lejanos.
Activos del caché #
Si su HTML es estática y no necesita cambiar en cada solicitud, el almacenamiento en caché puede evitar que se vuelva a crear innecesariamente. Al almacenar una copia del HTML generado en el disco, el almacenamiento en el caché del lado del servidor puede reducir la TTFB y minimizar el uso de los recursos.
Dependiendo de su cadena de herramientas, hay muchas maneras diferentes de aplicar el almacenamiento en el caché del servidor:
- Configure proxies inversos (Varnish, nginx) para publicar contenido en el caché o actuar como un servidor del caché cuando se instala frente a un servidor de aplicaciones
- Configure y administre el comportamiento del caché de su proveedor en la nube (Firebase, AWS, Azure))
- Utilice una CDN que proporcione servidores perimetrales para que su contenido se almacene en el caché y esté más cerca de sus usuarios
Publicar las páginas HTML en cache-first #
Cuando se instala, un service worker se ejecuta en segundo plano del navegador y puede interceptar las solicitudes del servidor. Este nivel de control programático del caché permite almacenar en el caché parte o todo el contenido de la página HTML y solo actualizar el caché cuando el contenido cambió.
En la siguiente gráfica se muestra cómo se han reducido las distribuciones de LCP en un sitio utilizando este patrón:
En la gráfica se muestra la distribución de la LCP de un solo sitio durante los últimos 28 días, segmentado por el estado del service worker. Observe cómo muchas más cargas de páginas tienen un valor de LCP más rápido después de que se introdujo el servicio de páginas HTML cache-first en el service worker (parte azul de la gráfica).
Establecer conexiones con terceros con anticipación #
Las solicitudes del servidor a orígenes de terceros también pueden afectar a LCP, especialmente si son necesarias para mostrar contenido crítico en la página. Utilice rel="preconnect" para informar al navegador que su página tiene la intención de establecer una conexión lo antes posible.
<link rel="preconnect" href="https://example.com" />También puede utilizar dns-prefetch para resolver las búsquedas de DNS de forma más rápida.
<link rel="dns-prefetch" href="https://example.com" />Aunque ambas sugerencias funcionan de manera diferente, considere utilizar dns-prefetch como alternativa para los navegadores que no admiten preconnect.
<head>
…
<link rel="preconnect" href="https://example.com" />
<link rel="dns-prefetch" href="https://example.com" />
</head>Utilizar intercambios firmados (SXG) #
Los intercambios firmados (SXG) son un mecanismo de entrega que permite experiencias de usuario más rápidas al proporcionar contenido en un formato que se puede almacenar en el caché fácilmente. Específicamente, la Google Search almacenará en el caché y, a veces, buscará previamente los SXG. Para los sitios que reciben una gran parte de su tráfico de Google Search, los SXG pueden ser una herramienta importante para mejorar LCP. Para obtener más información, consulte Intercambios firmados.
Renderización que bloquea JavaScript y CSS #
Antes de que un navegador pueda renderizar cualquier contenido, necesita analizar el marcado HTML en un árbol DOM. El analizador HTML se detendrá si encuentra hojas de estilo externas (<link rel="stylesheet">) o etiquetas de JavaScript sincrónicas (<script src="main.js">).
Los scripts y las hojas de estilo son recursos que bloquean la renderización y retrasan la FCP y, como consecuencia, la LCP. Retrasa cualquier JavaScript y CSS no crítico para acelerar la carga del contenido principal de su página web.
Reducir el tiempo de bloqueo de CSS #
Asegúrese de que solo la cantidad mínima de CSS necesaria esté bloqueando la renderización en su sitio con lo siguiente:
- Minificar CSS
- Retrasar CSS no crítico
- CSS crítico con estilos integrados en el código
Minificar CSS #
Para facilitar la legibilidad, los archivos CSS pueden contener caracteres como espaciado, sangría o comentarios. Todos estos caracteres son innecesarios para el navegador, y la minificación de estos archivos garantizará que se eliminen. En última instancia, reducir la cantidad de CSS de bloqueo siempre mejorará el tiempo que se tarda en renderizar completamente el contenido principal de la página (LCP).
Si utiliza un agrupador de módulos o una herramienta de compilación, incluya un complemento adecuado para minificar los archivos CSS en cada compilación:
- Para webpack: optimice-css-assets-webpack-plugin
- Para Gulp: gulp-clean-css
- Para Rollup: rollup-plugin-css-porter
Retrasar CSS no crítico #
Utilice la pestaña Coverage de Chrome DevTools para encontrar cualquier CSS que no utilice en su página web.
Para optimizar:
Elimine por completo cualquier CSS que no utilice o muévalo a otra hoja de estilo si se utiliza en una página separada de su sitio.
Para cualquier CSS que no sea necesaria para la renderización inicial, utilice loadCSS para cargar los archivos de forma asincrónica, lo que aprovecha
rel="preload"yonload.
<link rel="preload" href="stylesheet.css" as="style" onload="this.rel='stylesheet'">
CSS crítico con estilos integrados en el código #
Estilos integrados en el código de cualquier CSS de ruta crítica que se utilice para el contenido de la mitad superior de la página que lo incluya directamente en el <head>.
La inserción de estilos importantes elimina la necesidad de realizar una solicitud de ida y vuelta para obtener CSS crítico. Retrasar el resto minimiza el tiempo de bloqueo de CSS.
Si no puede agregar manualmente estilos integrados en el código a su sitio, utilice una biblioteca para automatizar el proceso. Algunos ejemplos son:
- Critical , CriticalCSS y Penthouse son paquetes que extraen e incorporan estilos integrados en el código de CSS, en la parte superior de la página.
- Critters es un complemento de webpack que integra estilos integrados en el código de CSS crítico y carga diferida de REST
Reducir el tiempo de bloqueo de JavaScript #
Descargue y publique la cantidad mínima de JavaScript necesaria a los usuarios. La reducción de la cantidad que JavaScript bloquea el sitio se traduce en una renderización más rápida y, en consecuencia, en una mejor LCP.
Esto se puede lograr optimizando sus scripts de diferentes formas:
- Minificar y comprimir archivos JavaScript
- Retrasar JavaScript no utilizado
- Minimice los polyfills no utilizados
Tiempos de carga de recursos lentos #
Aunque un aumento en el tiempo de bloqueo de CSS o JavaScript se traduce directamente en un peor rendimiento, el tiempo que se tarda en cargar muchos otros tipos de recursos también puede afectar los tiempos de despliegue. Los tipos de elementos que afectan a LCP son:
<img>elementos<image>elementos dentro de un elemento<svg><video>elementos (la imagen del cartel se utilizan para medir LCP)- Un elemento con una imagen de segundo plano que se carga a través de la función
url()(a diferencia de un gradiente CSS) - Elementos a nivel de bloque que contienen nodos de texto u otros elementos de texto con estilos integrados en el código.
El tiempo que se tarda en cargar estos elementos si se renderizan en la mitad superior de la página tendrá un efecto directo en LCP. Hay algunas formas de garantizar que estos archivos se carguen lo más rápido posible:
- Optimizar y comprimir imágenes
- Precargar recursos importantes
- Comprimir archivos de texto
- Entregar diferentes activos basados en la conexión de la red (servicio adaptable)
- Almacenar activos en el caché con un service worker
Optimizar y comprimir imágenes #
En muchos sitios, las imágenes son el elemento más grande a la vista cuando la página terminó de cargarse. En las imágenes hero los grandes carruseles o los banners son ejemplos comunes de esto.
Mejorar el tiempo que se tarda en cargar y renderizar este tipo de imágenes acelerará directamente la LCP. Para hacer esto:
- En primer lugar, considere la posibilidad de no utilizar una imagen. Si no es relevante para el contenido, elimínela.
- Comprima imágenes (por ejemplo con Imagemin)
- Convierta imágenes a formatos más nuevos (JPEG 2000, JPEG XR o WebP)
- Utilice imágenes responsive
- Considere utilizar una imagen CDN
Precargar recursos importantes #
A veces, los recursos importantes que se declaran o utilizan en un determinado archivo CSS o JavaScript pueden recuperarse más tarde de lo que le gustaría, como una fuente escondida en uno de los muchos archivos CSS de una aplicación.
Si sabe que un recurso en particular debe ser prioritario, utilice <link rel="preload"> para recuperarlo antes. Se pueden precargar muchos tipos de recursos, pero debería centrarse primero en precargar activos críticos, como fuentes, imágenes o videos en la mitad superior de la página, y CSS o JavaScript de ruta crítica.
<link rel="preload" as="script" href="script.js" />
<link rel="preload" as="style" href="style.css" />
<link rel="preload" as="image" href="img.png" />
<link rel="preload" as="video" href="vid.webm" type="video/webm" />
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin />Desde Chrome 73, la precarga se puede utilizar junto con imágenes responsivas para combinar ambos patrones y conseguir una carga de imágenes mucho más rápida.
<link
rel="preload"
as="image"
href="wolf.jpg"
imagesrcset="wolf_400px.jpg 400w, wolf_800px.jpg 800w, wolf_1600px.jpg 1600w"
imagesizes="50vw"
/>Comprimir archivos de texto #
Los algoritmos de compresión, como Gzip y Brotli, pueden reducir significativamente el tamaño de los archivos de texto (HTML, CSS, JavaScript) conforme se transfieren entre el servidor y el navegador. Gzip efectivamente es compatible con todos los navegadores y Brotli, que proporciona resultados de compresión aún mejores, se puede utilizar en casi todos los navegadores más recientes.
La compresión de sus recursos minimizará su tamaño de entrega, mejorando los tiempos de carga y, en consecuencia, la LCP.
- En primer lugar, verifique si su servidor ya comprime archivos automáticamente. La mayoría de las plataformas de alojamiento, CDN y servidores proxy inversos codifican activos con compresión de forma predeterminada o le permiten configurarlos fácilmente.
- Si necesita modificar su servidor para comprimir los archivos, considere la posibilidad de utilizar Brotli en vez de gzip, ya que puede proporcionar mejores índices de compresión.
- Una vez que elija un algoritmo de compresión, comprima los activos con anticipación durante el proceso de creación en vez de hacerlo sobre la marcha, según lo solicite el navegador. Esto minimiza la sobrecarga del servidor y se evitan retrasos en las solicitudes, especialmente cuando se utilizan índices de compresión elevados.
Servicio adaptativo #
Cuando se cargan los recursos que conforman el contenido principal de una página, puede ser efectivo obtener de forma condicional diferentes activos dependiendo del dispositivo del usuario o de las condiciones de la red. Esto se puede hacer utilizando las API Información de la red, Memoria del dispositivo y Concurrencia del hardware.
Si tienes activos grandes que son críticos para la renderización inicial, puedes utilizar diferentes variaciones del mismo recurso dependiendo de la conexión o el dispositivo del usuario. Por ejemplo, puedes mostrar una imagen en vez de un video para cualquier velocidad de conexión inferior a 4G:
if (navigator.connection && navigator.connection.effectiveType) {
if (navigator.connection.effectiveType === '4g') {
// Load video
} else {
// Load image
}
}Una lista de propiedades útiles que puede utilizar son:
navigator.connection.effectiveType: tipo de conexión efectivanavigator.connection.saveData: ahorro de datos habilitado/deshabilitadonavigator.hardwareConcurrency: recuento de núcleos del CPUnavigator.deviceMemory: memoria del dispositivo
Almacenar activos en el caché con un service worker #
Los service workers se pueden utilizar para muchas tareas útiles, incluyendo publicar respuestas en HTML más pequeñas como se mencionó anteriormente en este artículo. También se pueden utilizar para almacenar en el caché cualquier recurso estático que se pueda publicar en el navegador en vez de desde la red en solicitudes repetidas.
El almacenamiento previo en el caché de recursos críticos mediante un service worker puede reducir sus tiempos de carga de manera significativa, especialmente para los usuarios que recargan la página web con una conexión más débil (o incluso acceden a ella sin conexión). Las librerías como Workbox pueden hacer que el proceso de actualización de activos almacenados previamente en el caché sea más fácil que escribir en un service worker personalizado para que lo maneje usted mismo.
Representación del lado del cliente #
Muchos sitios utilizan la lógica de JavaScript del lado del cliente para renderizar las páginas directamente en el navegador. Los frameworks y las librerías, como React, Angular y Vue, han facilitado la creación de aplicaciones de una sola página que manejan diferentes facetas de una página web completamente en el cliente y no en el servidor.
Si está creando un sitio que se renderiza principalmente en el lado del cliente, debe tener cuidado con el efecto que puede tener en LCP si se utiliza un gran paquete de JavaScript. Si no se implementan optimizaciones para evitarlo, es posible que los usuarios no vean ni interactúen con ningún contenido de la página hasta que todo el JavaScript crítico haya terminado de descargarse y ejecutarse.
Al crear un sitio renderizado del lado del cliente, considere las siguientes optimizaciones:
- Minimizar JavaScript crítico
- Utilizar la renderización del lado del servidor
- Utilizar la renderización previa
Minimizar JavaScript crítico #
Si el contenido de su sitio solo se vuelve visible, o se puede interactuar con él, después de que se descargue una cierta cantidad de JavaScript: es aún más importante reducir el tamaño de su paquete tanto como sea posible. Esto se puede hacer al:
- Minificar JavaScript
- Retrasar JavaScript no utilizado
- Minimizar los polyfills no utilizados
Vuelva a la sección Reducir el tiempo de bloqueo de JavaScript para obtener más información sobre estas optimizaciones.
Utilizar la renderización del lado del servidor #
Minimizar la cantidad de JavaScript siempre debe ser lo primero en lo que se debe centrar para los sitios que en su mayoría se renderizan por el cliente. Sin embargo, también debería considerar la posibilidad de combinar una experiencia de renderizado en el servidor para mejorar la LCP tanto como sea posible.
Este concepto funciona utilizando el servidor para renderizar la aplicación en HTML, donde el cliente luego "hidrata" todo el JavaScript y los datos requeridos en el mismo contenido DOM. Esto puede mejorar la LCP al garantizar que el contenido principal de la página se renderice primero en el servidor en vez de solo en el lado del cliente, pero hay algunos inconvenientes:
- Mantener la misma aplicación renderizada en JavaScript en el servidor y el cliente puede aumentar la complejidad.
- Ejecutar JavaScript para renderizar un archivo HTML en el servidor siempre aumentará los tiempos de respuesta del servidor (TTFB) en comparación con solo publicar páginas estáticas desde el servidor.
- Puede parecer que se puede interactuar con una página renderizada por el servidor, pero no puede responder a ninguna entrada del usuario hasta que se haya ejecutado todo el JavaScript del lado del cliente. En resumen, puede hacer que el Time to Interactive: Tiempo de Interacción (TTI) empeore.
Utilizar la renderización previa #
La renderización previa es una técnica independiente que es menos compleja que la renderización del lado del servidor y también proporciona una forma de mejorar LCP en su aplicación. Se utiliza un navegador sin encabezado, el cual es un navegador sin interfaz de usuario, para generar archivos HTML estáticos de cada ruta durante el tiempo de la creación. Estos archivos se pueden enviar junto con los paquetes de JavaScript necesarios para la aplicación.
Con la renderización previa, la TTI sigue teniendo un impacto negativo, pero los tiempos de respuesta del servidor no se ven tan afectados como lo harían con una solución de la renderización del lado del servidor que renderiza dinámicamente cada página solo después de que se solicita.
Herramientas para desarrolladores #
Hay varias herramientas disponibles para medir y depurar LCP:
Lighthouse 6.0 incluye soporte para medir LCP en un entorno de laboratorio.
La sección de sincronizaciones del rendimiento en el panel en Chrome DevTools incluye un marcador de LCP y muestra qué elemento se asocia con LCP cuando se pasa sobre el campo Nodo relacionado.
Chrome User Experience Report proporciona valores de LCP del mundo real agregados a nivel de origen.
Agradecemos a Philip Walton, Katie Hempenius, Kayce Basques e Ilya Grigorik por sus comentarios.