Descubre qué es el escáner de precarga del navegador, cómo ayuda al rendimiento y cómo puedes evitar estorbas.
Un aspecto ignorado en cuanto a la optimización de la velocidad de las páginas implica saber un poco sobre los aspectos internos del navegador. Los navegadores realizan ciertas optimizaciones para mejorar el rendimiento de maneras que nosotros, como los desarrolladores, no podemos, pero solo en la medida en que esas optimizaciones no se frustren involuntariamente.
Una optimización interna del navegador que hay que comprender es el escáner de precarga del navegador. En esta publicación, se explicará cómo funciona el escáner de precarga y, lo que es más importante, cómo puedes evitar interrupciones.
¿Qué es un escáner de precarga?
Cada navegador tiene un analizador de HTML principal que asigna tokens al lenguaje de marcado sin procesar y lo procesa en un modelo de objetos. Todo esto continúa hasta que el analizador se detiene cuando encuentra un recurso de bloqueo, como una hoja de estilo cargada con un elemento <link> o una secuencia de comandos cargada con un elemento <script> sin un atributo async o defer.
<link> para un archivo CSS externo, lo que impide que el navegador analice el resto del documento (o incluso procese) hasta que se descargue y analice el CSS.
En el caso de los archivos CSS, tanto el análisis como la renderización se bloquean para evitar un destello de contenido sin estilo (FOUC), que ocurre cuando una versión sin estilo de una página se puede ver brevemente antes de que se le apliquen estilos.
El navegador también bloquea el análisis y la renderización de la página cuando encuentra elementos <script> sin los atributos defer o async.
Esto se debe a que el navegador no puede saber con seguridad si una secuencia de comandos determinada modificará el DOM mientras el analizador de HTML principal aún realiza su trabajo. Por eso, es una práctica común cargar tu código JavaScript al final del documento para que los efectos de la renderización y el análisis bloqueados sean marginales.
Estas son buenas razones por las que el navegador debe bloquear tanto el análisis como la renderización. Sin embargo, no es recomendable bloquear cualquiera de estos pasos importantes, ya que pueden detener el programa si retrasan el descubrimiento de otros recursos importantes. Afortunadamente, los navegadores hacen todo lo posible para mitigar estos problemas mediante un analizador de HTML secundario llamado escáner de precarga.
<body>, pero el escáner de precarga puede mirar hacia adelante en el lenguaje de marcado sin procesar para encontrar ese recurso de imagen y comenzar a cargarlo antes de que se desbloquee el analizador de HTML principal.
La función de un escáner de precarga es especulativa, lo que significa que examina el lenguaje de marcado sin procesar para encontrar recursos que se pueden recuperar de manera oportuna antes de que el analizador de HTML principal los encuentre.
Cómo saber cuándo funciona el escáner de precarga
El escáner de precarga existe debido al bloqueo de la renderización y el análisis. Si estos dos problemas de rendimiento nunca hubieran existido, el escáner de precarga no sería muy útil. La clave para averiguar si una página web se beneficia del escáner de precarga depende de estos fenómenos de bloqueo. Para ello, puedes introducir un retraso artificial en las solicitudes destinadas a averiguar dónde está funcionando el escáner de precarga.
Tomemos como ejemplo esta página de imágenes y texto básicos con una hoja de estilo. Debido a que los archivos CSS bloquean la renderización y el análisis, introduces un retraso artificial de dos segundos para la hoja de estilo a través de un servicio de proxy. Esta demora facilita la observación de la cascada de red donde está funcionando el escáner de precarga.
Como puedes ver en la cascada, el escáner de precarga detecta el elemento <img> incluso mientras se bloquean la renderización y el análisis de documentos. Sin esta optimización, el navegador no puede recuperar elementos de manera oportuna durante el período de bloqueo, y una mayor cantidad de solicitudes de recursos serían consecutivas en lugar de simultáneas.
Con ese ejemplo de juguete fuera del camino, veamos algunos patrones del mundo real en los que se puede vencer el escáner de precarga y qué se puede hacer para solucionarlos.
Se insertaron async secuencias de comandos
Supongamos que tienes HTML en tu <head> que incluye código JavaScript intercalado, como el siguiente:
<script>
const scriptEl = document.createElement('script');
scriptEl.src = '/yall.min.js';
document.head.appendChild(scriptEl);
</script>
Las secuencias de comandos inyectadas son async de forma predeterminada, por lo que, cuando se inserte, se comportará como si se le hubiera aplicado el atributo async. Eso significa que se ejecutará lo antes posible y no bloqueará la renderización. Suena óptimo, ¿verdad? Sin embargo, si supones que este <script> intercalado viene después de un elemento <link> que carga un archivo CSS externo, obtendrás un resultado deficiente:
async insertada. El escáner de precarga no puede descubrir la secuencia de comandos durante la fase de bloqueo de la renderización porque se inserta en el cliente.
Analicemos lo que sucedió aquí:
- A los 0 segundos, se solicita el documento principal.
- A los 1,4 segundos, llega el primer byte de la solicitud de navegación.
- En 2.0 segundos, se solicitan el CSS y la imagen.
- Debido a que el analizador no puede cargar la hoja de estilo y el código JavaScript intercalado que inserta la secuencia de comandos
asyncaparece después de esa hoja de estilo en 2.6 segundos, la funcionalidad que proporciona la secuencia de comandos no estará disponible inmediatamente.
Esto no es óptimo, ya que la solicitud de la secuencia de comandos solo se produce después de que se termina de descargar la hoja de estilo. Esto retrasa la ejecución de la secuencia de comandos lo antes posible. Por el contrario, debido a que el elemento <img> es detectable en el lenguaje de marcado proporcionado por el servidor, el escáner de precarga lo descubre.
Entonces, ¿qué sucede si usas una etiqueta <script> normal con el atributo async en lugar de insertar la secuencia de comandos en el DOM?
<script src="/yall.min.js" async></script>
Este es el resultado:
<script> async. El escáner de carga previa detecta la secuencia de comandos durante la fase de bloqueo de la renderización y la carga de forma simultánea con la CSS.
Es posible que se sienta tentado a sugerir que estos problemas se pueden solucionar usando rel=preload. Sin duda, esto funciona, pero puede tener algunos efectos secundarios. Después de todo, ¿por qué usar rel=preload para solucionar un problema que se puede evitar no inyectando un elemento <script> en el DOM?
async insertada, pero la secuencia de comandos async está precargada para garantizar que se detecte antes.
La precarga "corrige" el problema aquí, pero presenta un nuevo problema: la secuencia de comandos async de las dos primeras demostraciones (a pesar de estar cargada en <head>) se carga con prioridad "Baja", mientras que la hoja de estilo se carga con la prioridad "Más alta". En la última demostración, en la que se precarga la secuencia de comandos async, la hoja de estilo aún se carga con la prioridad "Más alta", pero la prioridad de la secuencia de comandos se ascendió a "Alta".
Cuando se eleva la prioridad de un recurso, el navegador le asigna más ancho de banda. Esto significa que, aunque la hoja de estilo tenga la prioridad más alta, la prioridad elevada de la secuencia de comandos puede causar contención del ancho de banda. Ese podría ser un factor en las conexiones lentas o en los casos en que los recursos sean bastante grandes.
La respuesta aquí es clara: si se necesita una secuencia de comandos durante el inicio, no anules el escáner de precarga inyectándolo en el DOM. Realiza experimentos según sea necesario con la posición del elemento <script> y con atributos como defer y async.
Carga diferida con JavaScript
La carga diferida es un excelente método para conservar datos, que se suele aplicar a las imágenes. Sin embargo, a veces la carga diferida se aplica de forma incorrecta a imágenes que se encuentran en la "mitad superior de la página", por decirlo de algún modo.
Esto genera posibles problemas con la visibilidad de recursos relacionados con el escáner de precarga y puede retrasar innecesariamente el tiempo que lleva descubrir una referencia a una imagen, descargarla, decodificarla y presentarla. Tomemos el lenguaje de marcado de esta imagen, por ejemplo:
<img data-src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">
El uso de un prefijo data- es un patrón común en los cargadores diferidos con tecnología de JavaScript. Cuando la imagen se desplaza al viewport, el cargador diferido quita el prefijo data-, lo que significa que, en el ejemplo anterior, data-src se convierte en src. Esta actualización le solicita al navegador que recupere el recurso.
Este patrón no resulta problemático hasta que se aplica a las imágenes que están en el viewport durante el inicio. Debido a que el escáner de precarga no lee el atributo data-src de la misma manera que lo haría un atributo src (o srcset), la referencia de imagen no se descubre antes. Y lo que es peor, la carga de la imagen se retrasa hasta después de que el cargador diferido JavaScript descarga, compila y ejecuta.
Según el tamaño de la imagen, que puede depender del tamaño del viewport, puede ser un elemento candidato para el Largest Contentful Paint (LCP). Cuando el escáner de precarga no puede recuperar de manera especulativa el recurso de imagen con anticipación(posiblemente durante el punto en el que se procesa el bloque de las hojas de estilo de la página), el LCP se ve afectado.
La solución es cambiar el lenguaje de marcado de la imagen:
<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">
Este es el patrón óptimo para las imágenes que están en el viewport durante el inicio, ya que el escáner de precarga descubrirá y recuperará el recurso de imagen más rápido.
El resultado en este ejemplo simplificado es una mejora de 100 milisegundos en el LCP en una conexión lenta. Esto puede no parecer una gran mejora, pero es cuando consideras que la solución es una corrección rápida de lenguaje de marcado y que la mayoría de las páginas web son más complejas que este conjunto de ejemplos. Eso significa que los candidatos de LCP pueden tener que competir por el ancho de banda con muchos otros recursos, por lo que optimizaciones como esta se vuelven cada vez más importantes.
Imágenes de fondo de CSS
Recuerda que el escáner de precarga del navegador analiza el lenguaje de marcado. No analiza otros tipos de recursos, como CSS, que pueden implicar recuperaciones de imágenes a las que hace referencia la propiedad background-image.
Al igual que HTML, los navegadores procesan CSS en su propio modelo de objetos, que se conoce como CSSOM. Si se descubren recursos externos a medida que se construye el CSSOM, estos se solicitan en el momento del descubrimiento y no a través del escáner de precarga.
Supongamos que el candidato para LCP de tu página es un elemento con una propiedad background-image de CSS. Esto es lo que sucede cuando se cargan los recursos:
background-image de CSS (fila 3). La imagen que solicita no comienza a recuperarse hasta que el analizador de CSS la encuentra.
En este caso, el escáner de precarga no se ve tan frustrado como no está involucrado. Aun así, si un candidato de LCP de la página es de una propiedad CSS background-image, deberás precargar esa imagen:
<!-- Make sure this is in the <head> below any
stylesheets, so as not to block them from loading -->
<link rel="preload" as="image" href="lcp-image.jpg">
Esa sugerencia rel=preload es pequeña, pero ayuda al navegador a descubrir la imagen antes de lo que lo haría de otro modo:
background-image de CSS (fila 3). La sugerencia rel=preload ayuda al navegador a descubrir la imagen alrededor de 250 milisegundos antes que sin ella.
Con la sugerencia rel=preload, el candidato a LCP se descubre más rápido, lo que reduce el tiempo de LCP. Si bien esa sugerencia ayuda a solucionar el problema, la mejor opción puede ser evaluar si tu candidato para LCP de imágenes tiene que cargarse desde CSS. Con una etiqueta <img>, tendrás más control sobre la carga de una imagen adecuada para el viewport y, al mismo tiempo, permitirás que el escáner de precarga la descubra.
Demasiados recursos intercalados
El intercalado es una práctica que coloca un recurso dentro del HTML. Puedes intercalar hojas de estilo en elementos <style>, secuencias de comandos en elementos <script> y prácticamente cualquier otro recurso con la codificación en base64.
La intercalación de recursos puede ser más rápida que descargarlos, ya que no se emite una solicitud independiente para el recurso. Se incluye en el documento y se carga al instante. Sin embargo, existen desventajas importantes:
- Si no almacenas tu HTML en caché (y simplemente no puedes hacerlo si la respuesta HTML es dinámica), los recursos insertados nunca se almacenan en caché. Esto afecta el rendimiento porque los recursos intercalados no se pueden volver a usar.
- Incluso si puedes almacenar HTML en caché, los recursos intercalados no se comparten entre los documentos. Esto reduce la eficiencia del almacenamiento en caché en comparación con los archivos externos que se pueden almacenar en caché y volver a usar en todo un origen.
- Si insertas demasiado contenido, se retrasa el escáner de precarga para que no descubra recursos más adelante en el documento, ya que descargar ese contenido adicional intercalado lleva más tiempo.
Tomemos esta página como ejemplo. En ciertas condiciones, el candidato para LCP es la imagen de la parte superior de la página y el CSS se encuentra en un archivo separado cargado por un elemento <link>. La página también usa cuatro fuentes web que se solicitan como archivos independientes del recurso CSS.
<img>, pero el escáner de precarga la detecta porque el CSS y las fuentes necesarias para cargar la página en recursos separados, lo que no demora el trabajo del escáner de precarga.
Ahora, ¿qué sucede si el CSS y todas las fuentes se intercalan como recursos en base64?
<img>, pero la incorporación de la CSS y sus cuatro recursos de fuente en el `` retrasa el escáner de precarga en el descubrimiento de la imagen hasta que esos recursos se descarguen por completo.
En este ejemplo, el impacto de la integración genera consecuencias negativas para el LCP y el rendimiento en general. La versión de la página que no está intercalada nada pinta la imagen LCP en aproximadamente 3.5 segundos. En la página que intercala todo, no se pinta la imagen LCP hasta que transcurre poco más de 7 segundos.
Aquí hay mucho más que el escáner de precarga. Intercalar fuentes no es una gran estrategia porque base64 es un formato ineficiente para los recursos binarios. Otro factor en juego es que los recursos de fuentes externas no se descargan a menos que el CSSOM los determine como necesarios. Cuando esas fuentes se integran como base64, se descargan sin importar si se necesitan para la página actual o no.
¿Una precarga podría mejorar las cosas aquí? Por supuesto. Podrías precargar la imagen de LCP y reducir el tiempo de LCP, pero inflar tu código HTML potencialmente no almacenable en caché con recursos intercalados tiene otras consecuencias negativas para el rendimiento. Primer procesamiento de imagen con contenido (FCP) también se ve afectado por este patrón. En la versión de la página en la que no hay nada intercalado, FCP es de aproximadamente 2.7 segundos. En la versión en la que todo está intercalado, el FCP es de aproximadamente 5.8 segundos.
Ten mucho cuidado al intercalar elementos en HTML, especialmente en los recursos codificados en base64. En general, no se recomienda, excepto en el caso de recursos muy pequeños. Intercalar lo menos posible, porque estar demasiado insertado es un juego de fuego.
Cómo renderizar lenguaje de marcado con JavaScript del cliente
No hay duda de ello: JavaScript definitivamente afecta la velocidad de la página. Los desarrolladores no solo dependen de él para proporcionar interactividad, sino que también ha habido una tendencia a depender de él para entregar el contenido por sí mismo. Esto conduce a una mejor experiencia de los desarrolladores en algunos aspectos, pero los beneficios para ellos no siempre se traducen en beneficios para los usuarios.
Un patrón que puede frustrar al escáner de precarga es el procesamiento del lenguaje de marcado con JavaScript del lado del cliente:
Cuando JavaScript contiene y procesa las cargas útiles de lenguaje de marcado en el navegador por completo, cualquier recurso de ese lenguaje de marcado es efectivamente invisible para el escáner de precarga. Esto retrasa el descubrimiento de recursos importantes, lo que sin duda afecta al LCP. En el caso de estos ejemplos, la solicitud de la imagen LCP se retrasa significativamente en comparación con la experiencia equivalente renderizada por el servidor que no requiere la aparición de JavaScript.
Esto se aleja un poco del enfoque de este artículo, pero los efectos de renderizar el lenguaje de marcado en el cliente van mucho más allá del análisis de precarga. Por un lado, la introducción de JavaScript para potenciar una experiencia que no la requiera genera un tiempo de procesamiento innecesario que puede afectar la Interacción con la siguiente pintura (INP).
Además, renderizar cantidades muy grandes de lenguaje de marcado en el cliente tiene más probabilidades de generar tareas largas en comparación con la misma cantidad de lenguaje de marcado que envía el servidor. Esto, además del procesamiento adicional que implica JavaScript, es que los navegadores transmiten el lenguaje de marcado del servidor y fragmentan la renderización de tal manera que se evitan tareas largas. El lenguaje de marcado renderizado por el cliente, por otro lado, se maneja como una tarea única y monolítica, que puede afectar las métricas de capacidad de respuesta de la página, como el Tiempo de bloqueo total (TBT) o el Retraso de primera entrada (FID), además del INP.
La solución para esta situación depende de la respuesta a la siguiente pregunta: ¿Existe un motivo por el que el servidor no puede proporcionar el lenguaje de marcado de tu página en lugar de que se renderice en el cliente? Si la respuesta es “no”, se debe considerar la renderización del servidor (SSR) o el lenguaje de marcado generado de forma estática siempre que sea posible, ya que ayudará al escáner de precarga a descubrir y recuperar de manera oportuna recursos importantes.
Si tu página necesita JavaScript para adjuntar funcionalidad a algunas partes del lenguaje de marcado, puedes hacerlo con SSR, ya sea con JavaScript vanilla o con hidratación para aprovechar al máximo ambos mundos.
Ayuda a que el escáner de precarga te ayude
El escáner de precarga es una optimización muy eficaz del navegador que ayuda a que las páginas se carguen más rápido durante el inicio. Al evitar patrones que impiden su capacidad de descubrir recursos importantes de manera anticipada, no solo simplificas el desarrollo, sino que creas mejores experiencias del usuario que generarán mejores resultados en muchas métricas, incluidas algunas Métricas web.
En resumen, estas son las conclusiones de esta publicación:
- El escáner de precarga del navegador es un analizador de HTML secundario que realiza análisis antes que el principal si se bloquea para descubrir de manera oportuna los recursos que puede recuperar antes.
- El escáner de precarga no puede descubrir los recursos que no están presentes en el lenguaje de marcado proporcionado por el servidor en la solicitud de navegación inicial. Estas son algunas de las maneras en las que se puede anular el escáner de precarga:
- Se pueden insertar recursos en el DOM con JavaScript, ya sean secuencias de comandos, imágenes, hojas de estilo o cualquier otro elemento que resulte mejor en la carga útil de marcado inicial del servidor.
- Carga diferida de imágenes o iframes en la mitad superior de la página mediante una solución de JavaScript
- Representar lenguaje de marcado en el cliente que pueda contener referencias a subrecursos de documentos mediante JavaScript
- El escáner de precarga solo analiza HTML. No se examina el contenido de otros recursos, como CSS, que pueden incluir referencias a activos importantes, incluidos los candidatos al LCP.
Si, por cualquier motivo, no puedes evitar un patrón que afecte negativamente la capacidad del escáner de precarga para acelerar el rendimiento de carga, ten en cuenta la sugerencia de recurso rel=preload. Si sí usas rel=preload, realiza pruebas en las herramientas del lab para asegurarte de que tengan el efecto deseado. Por último, no precargues demasiados recursos, ya que cuando priorices todo, nada lo será.
Recursos
- Las "secuencias de comandos asíncronas" insertadas mediante secuencias de comandos se consideran dañinas
- Cómo el precargador del navegador hace que las páginas se carguen más rápido
- Precarga los recursos críticos para mejorar la velocidad de carga
- Establece conexiones de red con anticipación para mejorar la velocidad percibida de la página
- Optimiza la métrica Largest Contentful Paint
Hero image de Unsplash, de Mohammad Rahmani .