Cuando abres una página web, el navegador solicita el documento HTML a un servidor, analiza su contenido y envía solicitudes separadas para los recursos a los que se hace referencia. Como desarrollador, ya conoces todos los recursos que necesita tu página y cuáles son los más importantes. Puedes usar ese conocimiento para solicitar los recursos críticos con anticipación y acelerar el proceso de carga. En esta publicación, se explica cómo lograrlo con <link rel="preload">.
Cómo funciona la precarga
La precarga es más adecuada para los recursos que el navegador suele descubrir tarde.
@font-face. El navegador carga el archivo de fuente solo después de que termina de descargar y analizar la hoja de estilo.Al precargar un recurso determinado, le indicas al navegador que te gustaría recuperarlo antes de lo que lo descubriría de otro modo porque tienes la certeza de que es importante para la página actual.
La cadena de solicitudes críticas representa el orden de los recursos que el navegador prioriza y recupera. Lighthouse identifica los recursos que se encuentran en el tercer nivel de esta cadena como de descubrimiento tardío. Puedes usar la auditoría Precargar solicitudes de claves para identificar qué recursos precargar.
Para precargar recursos, agrega una etiqueta <link> con rel="preload" al encabezado de tu documento HTML:
<link rel="preload" as="script" href="critical.js">
El navegador almacena en caché los recursos precargados para que estén disponibles de inmediato cuando se necesiten. (No ejecuta las secuencias de comandos ni aplica las hojas de estilo).
Las sugerencias de recursos, como preconnect y prefetch, se ejecutan según lo que el navegador lo crea conveniente. Por otro lado, preload es obligatorio para el navegador. Los navegadores modernos ya son bastante buenos para priorizar recursos. Por ello, es importante usar preload con moderación y solo precargar los recursos más importantes.
Las precargas sin usar activan una advertencia de la consola en Chrome, aproximadamente 3 segundos después del evento load.
Casos de uso
Precarga de recursos definidos en CSS
Las fuentes definidas con reglas @font-face o imágenes de fondo definidas en archivos CSS no se detectan hasta que el navegador descarga y analiza esos archivos CSS. La precarga de estos recursos garantiza que se recuperen antes de que se descarguen los archivos CSS.
Precarga de archivos CSS
Si usas el enfoque esencial de CSS, lo divides en dos partes. El CSS fundamental que se requiere para renderizar el contenido de la mitad superior de la página está integrado en el <head> del documento, y las CSS que no son críticas se suelen cargar de forma diferida con JavaScript. Esperar a que se ejecute JavaScript antes de cargar CSS que no sea crítico puede causar demoras en la renderización cuando los usuarios se desplazan, por lo que se recomienda usar <link rel="preload"> para iniciar la descarga antes.
Precarga de archivos JavaScript
Debido a que los navegadores no ejecutan archivos precargados, la precarga es útil para separar la recuperación de la ejecución, lo que puede mejorar métricas como el tiempo de carga. La precarga funciona mejor si divides tus paquetes de JavaScript y solo precargas fragmentos críticos.
Cómo implementar rel=preload
La forma más simple de implementar preload es agregar una etiqueta <link> al <head> del documento:
<head>
<link rel="preload" as="script" href="critical.js">
</head>
El atributo as ayuda al navegador a establecer la prioridad del recurso cargado previamente según su tipo, a establecer los encabezados correctos y a determinar si el recurso ya existe en la caché. Los valores aceptados para este atributo incluyen script, style, font, image y otros.
Algunos tipos de recursos, como las fuentes, se cargan en modo anónimo. Para ellos, debes configurar el atributo crossorigin con preload:
<link rel="preload" href="ComicSans.woff2" as="font" type="font/woff2" crossorigin>
Los elementos <link> también aceptan un atributo type, que contiene el tipo MIME del recurso vinculado. Los navegadores usan el valor del atributo type para garantizar que los recursos se precargan solo si se admite el tipo de archivo. Si un navegador no admite el tipo de recurso especificado, ignorará <link rel="preload">.
También puedes precargar cualquier tipo de recurso a través del encabezado HTTP Link:
Link: </css/style.css>; rel="preload"; as="style"
Una ventaja de especificar preload en el encabezado HTTP es que el navegador no necesita analizar el documento para descubrirlo, lo que puede ofrecer pequeñas mejoras en algunos casos.
Precarga módulos de JavaScript con webpack
Si usas un agrupador de módulos que crea archivos de compilación de tu aplicación, debes comprobar si admite la inserción de etiquetas de precarga. Con webpack versión 4.6.0 o posterior, se admite la precarga mediante el uso de comentarios mágicos en import():
import(_/* webpackPreload: true */_ "CriticalChunk")
Si usas una versión anterior de webpack, utiliza un complemento de terceros, como preload-webpack-plugin.
Efectos de la precarga en las Métricas web esenciales
La precarga es una potente optimización del rendimiento que tiene un efecto en la velocidad de carga. Estas optimizaciones pueden generar cambios en las Métricas web esenciales de tu sitio, y es importante tenerlas en cuenta.
Procesamiento de imagen con contenido más grande (LCP)
La precarga tiene un gran efecto en el Largest Contentful Paint (LCP) cuando se trata de imágenes y fuentes, ya que las imágenes y los nodos de texto pueden ser candidatos de LCP. Las hero image y las grandes ejecuciones de texto que se renderizan con fuentes web pueden beneficiarse significativamente de una sugerencia de precarga bien ubicada y deben usarse cuando haya oportunidades de entregar estos fragmentos importantes de contenido al usuario más rápido.
Sin embargo, debes tener cuidado con la precarga y con otras optimizaciones. En particular, evita precargar demasiados recursos. Si se priorizan demasiados recursos, no se prioriza ninguno de ellos. Los efectos de las sugerencias de precarga excesivas serán especialmente perjudiciales para las de redes más lentas en las que la contención del ancho de banda será más evidente.
En cambio, enfócate en algunos recursos de alto valor que sabes que se beneficiarán con una precarga bien ubicada. Al precargar fuentes, asegúrate de entregar las fuentes en formato WOFF 2.0 para reducir tanto el tiempo de carga de los recursos como sea posible. Debido a que WOFF 2.0 tiene una excelente compatibilidad con el navegador, el uso de formatos más antiguos, como WOFF 1.0 o TrueType (TTF), retrasará tu LCP si el candidato de LCP es un nodo de texto.
Cuando se trata de LCP y JavaScript, asegúrate de enviar el lenguaje de marcado completo desde el servidor para que el escáner de precarga del navegador funcione correctamente. Si publicas una experiencia que depende completamente de JavaScript para renderizar el lenguaje de marcado y no puede enviar código HTML procesado por el servidor, sería beneficioso pasar por un lugar donde el escáner de precarga del navegador no puede y precargar recursos que, de otro modo, solo serían detectables cuando JavaScript termina de cargarse y ejecutarse.
Cambio de diseño acumulado (CLS)
El Cambio de diseño acumulado (CLS) es una métrica especialmente importante en lo que respecta a las fuentes web, y CLS tiene una interacción significativa con las fuentes web que usan la propiedad font-display de CSS para administrar la forma en que se cargan las fuentes. Para minimizar los cambios de diseño relacionados con las fuentes web, considera las siguientes estrategias:
- Precarga las fuentes mientras usas el valor
blockpredeterminado parafont-display. Este es un delicado equilibrio. El bloqueo de la visualización de fuentes sin un resguardo puede considerarse un problema de la experiencia del usuario. Por un lado, cargar fuentes confont-display: block;elimina los cambios de diseño relacionados con las fuentes web. Por otro lado, te recomendamos que cargues esas fuentes web lo antes posible si son cruciales para la experiencia del usuario. La combinación de una precarga confont-display: block;puede ser un compromiso aceptable. - Precarga las fuentes mientras usas el valor
fallbackparafont-display.fallbackes un compromiso entreswapyblock, en el sentido de que tiene un período de bloqueo extremadamente corto. - Usa el valor
optionalparafont-displaysin una carga previa. Si una fuente web no es fundamental para la experiencia del usuario, pero de todos modos se usa para renderizar una cantidad significativa de texto de la página, considera usar el valoroptional. En condiciones adversas,optionalmostrará el texto de la página en una fuente de resguardo mientras carga la fuente en segundo plano para la siguiente navegación. El resultado neto en estas condiciones es CLS mejorado, ya que las fuentes del sistema se representarán de inmediato, mientras que las cargas de páginas posteriores cargarán la fuente de inmediato sin cambios de diseño.
CLS es una métrica difícil de optimizar cuando se trata de fuentes web. Como siempre, experimenta en el lab, pero confía en tus datos de campo para determinar si tus estrategias de carga de fuentes están mejorando CLS o lo empeoran.
Interacción con el siguiente procesamiento de imagen (INP)
Interaction to Next Paint es una métrica que mide la capacidad de respuesta a las entradas del usuario. Dado que JavaScript es el principal factor de interactividad en la Web, la precarga de JavaScript que impulsa interacciones importantes puede ayudar a mantener un INP de una página más bajo. Sin embargo, ten en cuenta que precargar demasiado JavaScript durante el inicio puede tener consecuencias negativas no deseadas si demasiados recursos compiten por el ancho de banda.
También debes tener cuidado con la división del código. La división de código es una excelente optimización para reducir la cantidad de JavaScript que se carga durante el inicio, pero las interacciones pueden retrasarse si dependen de que JavaScript se cargue al inicio de la interacción. Para compensar esto, deberás examinar la intención del usuario e inyectar una precarga de los fragmentos de JavaScript necesarios antes de que se lleve a cabo la interacción. Un ejemplo podría ser la precarga de JavaScript, el cual se requiere para validar el contenido de un formulario cuando alguno de los campos del formulario está enfocado.
Conclusión
Para mejorar la velocidad de la página, precarga los recursos importantes que el navegador descubre más tarde. Precargar todo sería contraproductivo, así que usa preload con moderación y mide el impacto en el mundo real.