Cuando abres una página web, el navegador solicita el documento HTML a un servidor, analiza su contenido y envía solicitudes separadas para cualquier recurso al que se haga referencia. Como desarrollador, ya conoces todos los recursos que necesita tu página y cuáles de ellos 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 detectar de forma tardía.
@font-face. El navegador carga el archivo de fuente solo después de terminar de descargar y analizar la hoja de estilo.Al precargar un recurso determinado, le indicas al navegador que deseas recuperarlo antes de que el navegador lo descubriría porque estás seguro 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 detección tardía. Puedes usar la auditoría Precargar solicitudes clave 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 inmediatamente cuando sea necesario. (No ejecuta las secuencias de comandos ni aplica las hojas de estilo).
Las sugerencias de recursos, por ejemplo, preconnect y prefetch, se ejecutan según lo considere el navegador. El preload, por otro lado, es obligatorio para el navegador. Los navegadores modernos ya son bastante buenos para priorizar recursos. Por eso, es importante usar preload con moderación y solo precargar los recursos más importantes.
Las precargas sin usar activan una advertencia de Console 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 descubren hasta que el navegador descarga y analiza esos archivos. 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 crítico de CSS, debes dividir tu CSS en dos partes. El CSS crítico necesario para renderizar el contenido de la mitad superior de la página está intercalado en el <head> del documento, y el CSS no crítico suele cargarse de forma diferida con JavaScript. Esperar a que se ejecute JavaScript antes de cargar elementos CSS no críticos puede causar demoras en la renderización cuando los usuarios se desplazan, por lo que te recomendamos usar <link rel="preload"> para iniciar la descarga lo antes posible.
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 las métricas como el tiempo de carga. La precarga funciona mejor si divides tus paquetes de JavaScript y solo precargas los fragmentos críticos.
Cómo implementar rel=preload
La forma más sencilla de implementar preload es agregar una etiqueta <link> al <head> del documento:
<head>
<link rel="preload" as="script" href="critical.js">
</head>
Proporcionar el atributo as ayuda al navegador a establecer la prioridad del recurso solicitado previamente según su tipo, establecer los encabezados correctos y determinar si el recurso ya existe en la caché. Los valores aceptados para este atributo incluyen los siguientes: script, style, font, image y otros.
Algunos tipos de recursos, como las fuentes, se cargan en modo anónimo. Para esos casos, 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 de MIME del recurso vinculado. Los navegadores usan el valor del atributo type para garantizar que los recursos se precarguen solo si su tipo de archivo es compatible. Si un navegador no admite el tipo de recurso especificado, ignorará el <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"
Uno de los beneficios 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 de módulos de JavaScript con webpack
Si usas un agrupador de módulos que crea archivos de compilación de tu aplicación, debes verificar si es compatible con la inserción de etiquetas de precarga. A partir de la versión 4.6.0 de webpack, la precarga es compatible con el uso de comentarios mágicos dentro de import():
import(_/* webpackPreload: true */_ "CriticalChunk")
Si usas una versión anterior de webpack, usa un complemento de terceros, como preload-webpack-plugin.
Efectos de la precarga en Core Web Vitals
La precarga es una potente optimización del rendimiento que influye en la velocidad de carga. Estas optimizaciones pueden generar cambios en las Métricas web esenciales de tu sitio, por lo que es importante tenerlas en cuenta.
Procesamiento de imagen con contenido más grande (LCP)
La precarga tiene un efecto potente en el procesamiento de imagen con contenido más grande (LCP) cuando se trata de imágenes y fuentes, ya que tanto las imágenes como los nodos de texto pueden ser candidatos de LCP. Las imágenes hero y las grandes ejecuciones de texto que se renderizan con fuentes web pueden beneficiarse notablemente de una sugerencia de precarga bien ubicada, y deben usarse cuando existen oportunidades de entregar estos fragmentos de contenido importantes 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, en efecto, ninguno de ellos se prioriza. Los efectos de las sugerencias de precarga excesivas serán especialmente perjudiciales para las redes más lentas en las que la contención del ancho de banda será más evidente.
En cambio, concéntrate en algunos recursos de alto valor que sabes que se beneficiarán de una precarga bien ubicada. Cuando precargues las fuentes, asegúrate de usarlas en formato WOFF 2.0 para reducir al máximo el tiempo de carga de los recursos. Debido a que WOFF 2.0 tiene excelente compatibilidad con los navegadores, el uso de formatos más antiguos, como WOFF 1.0 o TrueType (TTF), retrasará tu LCP si el candidato es un nodo de texto.
En el caso 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 se basa completamente en JavaScript para procesar el lenguaje de marcado y no puedes enviar HTML renderizado por el servidor, sería beneficioso intervenir en los casos en los que el escáner de precarga del navegador no puede y precargar recursos que, de lo contrario, solo estarían visibles cuando JavaScript termine 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 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 la fuente web, considera las siguientes estrategias:
- Precarga las fuentes mientras usas el valor predeterminado
blockparafont-display. Este es un equilibrio delicado. Bloquear la visualización de las 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 la fuente 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 una opción aceptable. - Precarga las fuentes mientras usas el valor
fallbackparafont-display.fallbackes un compromiso entreswapyblock, ya que tiene un período de bloqueo extremadamente corto. - Usa el valor
optionalparafont-displaysin precarga. Si una fuente web no es fundamental para la experiencia del usuario, pero 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 alternativa mientras se carga la fuente en segundo plano para la siguiente navegación. El resultado neto en estas condiciones es un CLS mejorado, ya que las fuentes del sistema se representarán inmediatamente, mientras que, en las cargas de página posteriores, la fuente se cargará 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 los datos de tu campo para determinar si tus estrategias de carga de fuentes mejoran el 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 la entrada del usuario. Dado que JavaScript impulsa la mayor parte de la interactividad en la Web, la precarga de JavaScript que impulsa interacciones importantes puede ayudar a mantener el INP de una página más bajo. Sin embargo, ten en cuenta que la precarga de 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 de código. La división de código es una optimización excelente para reducir la cantidad de JavaScript que se carga durante el inicio, pero las interacciones pueden retrasarse si dependen de que el código se cargue justo al inicio de la interacción. Para compensar esto, tendrás que examinar la intención del usuario e insertar una precarga para los fragmentos necesarios de JavaScript antes de que se lleve a cabo la interacción. Un ejemplo podría ser la precarga de JavaScript necesario 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 descubra tarde. Precargar todo sería contraproductivo, así que usa preload con moderación y mide el impacto en el mundo real.