La ruta de procesamiento crítica hace referencia a los pasos que se deben seguir hasta que la página web comienza a renderizarse en el navegador. Para renderizar páginas, los navegadores necesitan el documento HTML en sí, además de todos los recursos críticos necesarios para renderizar ese documento.
El módulo de consideraciones generales de rendimiento de HTML cubrió el paso del documento HTML al navegador. Sin embargo, en este módulo, veremos lo que hace el navegador después de descargar el documento HTML para procesar la página.
Renderización progresiva
La Web se distribuye por naturaleza. A diferencia de las aplicaciones nativas que se instalan antes de usarse, los navegadores no pueden depender de que los sitios web tengan todos los recursos necesarios para renderizar la página. Por lo tanto, los navegadores son muy buenos para renderizar páginas de manera progresiva. Por lo general, las apps nativas tienen una fase de instalación y, luego, una fase de ejecución. Sin embargo, en el caso de las páginas y las apps web, las líneas entre estas dos fases son mucho menos distintas, y los navegadores se diseñaron específicamente con eso en mente.
Por lo general, una vez que el navegador tenga recursos para renderizar una página, comenzará a hacerlo. Por lo tanto, la elección se vuelve cuándo renderizar el contenido: ¿cuándo es demasiado temprano?
Si el navegador se procesa lo antes posible cuando solo tiene HTML, pero antes de tener el CSS o el JavaScript necesario, la página se verá dañada temporalmente y cambiará considerablemente para la renderización final. Esta es una experiencia peor que presentar inicialmente una pantalla en blanco durante un tiempo hasta que el navegador tenga más de estos recursos necesarios para una renderización inicial que ofrezca una mejor experiencia del usuario.
Por otro lado, si el navegador espera a que todos los recursos estén disponibles en lugar de realizar un procesamiento secuencial, el usuario se quedará esperando durante mucho tiempo, con frecuencia innecesariamente, si la página se pudo usar mucho antes.
El navegador necesita saber cuál es la cantidad mínima de recursos que debe esperar para evitar presentar una experiencia claramente dañada. Por otro lado, el navegador tampoco debería esperar más del tiempo necesario antes de presentarle contenido al usuario. La secuencia de pasos que realiza el navegador antes de realizar esa renderización inicial se conoce como ruta de renderización crítica.
Comprender la ruta de renderización crítica puede ayudarte a mejorar el rendimiento web, ya que te aseguras de no bloquear la renderización inicial de la página más de lo necesario. Sin embargo, al mismo tiempo, es importante que no permitas que la renderización se realice demasiado temprano; para ello, debes quitar los recursos necesarios para esa renderización inicial de la ruta de renderización crítica.
La ruta de renderización (crítica)
La ruta de renderización incluye los siguientes pasos:
- Construye el modelo de objetos del documento (DOM) a partir del HTML.
- Construye el modelo de objetos de CSS (CSSOM) a partir del CSS.
- Aplicar cualquier JavaScript que altere el DOM o el CSSOM.
- Construcción del árbol de representación a partir del DOM y el CSSOM
- Realiza operaciones de estilo y diseño en la página para ver qué elementos caben en cada lugar.
- Pintar los píxeles de los elementos en la memoria.
- Componer los píxeles si alguno de ellos se superpone
- Dibuja físicamente todos los píxeles resultantes en la pantalla.
Solo después de que se hayan completado todos estos pasos, el usuario verá el contenido en la pantalla.
Este proceso de renderización ocurre varias veces. La renderización inicial invoca este proceso, pero a medida que haya más recursos disponibles que afectan el procesamiento de la página, el navegador volverá a ejecutar este proceso (o quizás solo partes de él) para actualizar lo que ve el usuario. La ruta de renderización crítica se centra en el proceso descrito antes para la renderización inicial y depende de los recursos críticos necesarios.
¿Qué recursos hay en la ruta de representación crítica?
El navegador debe esperar a que se descarguen algunos recursos críticos para poder completar la renderización inicial. Entre estos recursos, se incluyen los siguientes:
- Es parte del HTML.
- CSS que bloquea la renderización en el elemento
<head> - JavaScript que bloquea la renderización en el elemento
<head>.
Un punto clave es que el navegador procesa HTML en forma de transmisión. Apenas el navegador obtiene una parte del HTML de una página, comienza a procesarla. El navegador puede decidir renderizarla mucho antes de recibir el resto del código HTML de la página.
Es importante destacar que, para la renderización inicial, el navegador no suele esperar lo siguiente:
- Todo el código HTML.
- Fuentes.
- Imágenes.
- JavaScript sin bloqueo de renderización fuera del elemento
<head>(por ejemplo, elementos<script>colocados al final del HTML) - CSS sin bloqueo de renderización fuera del elemento
<head>o CSS con un valor del atributomediaque no se aplica al viewport actual.
El navegador suele considerar las fuentes y las imágenes como contenido que se debe completar en las renderizaciones posteriores de la página, de manera que no es necesario demorar la renderización inicial. Sin embargo, esto puede significar que quedan áreas de espacio en blanco en la renderización inicial mientras el texto está oculto a la espera de fuentes o hasta que las imágenes estén disponibles. Y lo que es peor, cuando no se reserva suficiente espacio para ciertos tipos de contenido (en especial cuando no se proporcionan dimensiones de imagen en el código HTML), el diseño de la página puede cambiar cuando este contenido se carga más adelante. Este aspecto de la experiencia del usuario se mide con la métrica Cambio de diseño acumulado (CLS).
El elemento <head> es clave para procesar la ruta de acceso de renderización crítica. Tanto es así que en la siguiente sección se explica con más detalle. La optimización del contenido del elemento <head> es un aspecto clave del rendimiento web. Sin embargo, para comprender la ruta de renderización crítica por ahora, solo debes saber que el elemento <head> contiene metadatos sobre la página y sus recursos, pero no el contenido real que el usuario puede ver. El contenido visible se encuentra dentro del elemento <body> que sigue al elemento <head>. Antes de que el navegador pueda procesar cualquier contenido, necesita tanto el contenido como los metadatos sobre cómo hacerlo.
Sin embargo, no todos los recursos a los que se hace referencia en el elemento <head> son estrictamente necesarios para la renderización de la página inicial, por lo que el navegador solo espera los que sí lo son. Para identificar qué recursos se encuentran en la ruta de renderización crítica, debes comprender los conceptos de CSS y JavaScript que bloquean la renderización y los que bloquean el analizador.
Recursos de bloqueo de procesamiento
Algunos recursos se consideran tan fundamentales que el navegador detiene el procesamiento de la página hasta que los haya resuelto. CSS se incluye en esta categoría de forma predeterminada.
Cuando un navegador ve CSS, ya sea un CSS intercalado en un elemento <style> o un recurso al que se haga referencia externamente y que un elemento <link rel=stylesheet href="..."> especifica, el navegador evita renderizar más contenido hasta que termine de descargar y procesar esa CSS.
El hecho de que un recurso bloquee la renderización no necesariamente significa que el navegador no realice ninguna otra acción. Los navegadores intentan ser lo más eficientes posible. Por lo tanto, cuando detecten que necesitan descargar un recurso CSS, lo solicitarán y detendrán el procesamiento, pero seguirán procesando el resto del HTML y buscarán otras tareas por hacer mientras tanto.
Recursos de bloqueo de la renderización, como CSS, que se utilizan para bloquear toda la renderización de la página cuando se descubren. Esto significa que el bloqueo de procesamiento de algunos CSS o no depende de que el navegador lo haya descubierto. Algunos navegadores (en un principio y también Chrome) solo bloquean el procesamiento de contenido debajo del recurso de bloqueo de procesamiento. Esto significa que, en el caso de la ruta crítica de bloqueo de renderización, por lo general, nos interesan los recursos de bloqueo de renderización en <head>, ya que bloquean la renderización de toda la página de forma efectiva.
Una innovación más reciente es el atributo blocking=render, agregado a Chrome 105. Esto permite a los desarrolladores marcar de forma explícita un elemento <link>, <script> o <style> como bloqueador de renderización hasta que se procese, pero, mientras tanto, el analizador continúa procesando el documento.
Recursos que bloquean el analizador
Los recursos que bloquean el analizador son aquellos que evitan que el navegador busque otra tarea al continuar con el análisis del HTML. De forma predeterminada, JavaScript bloquea el analizador (a menos que esté marcado específicamente como asíncrono o diferido), ya que puede cambiar el DOM o el CSSOM al momento de su ejecución. Por lo tanto, no es posible que el navegador siga procesando otros recursos hasta conocer el impacto total del JavaScript solicitado en el código HTML de una página. Por lo tanto, el JavaScript síncrono bloquea el analizador.
Los recursos que bloquean el analizador también son eficaces para bloquear la renderización. Dado que el analizador no puede continuar pasando un recurso que bloquea el análisis hasta que se haya procesado por completo, no puede acceder al contenido ni procesarlo después de él. El navegador puede procesar cualquier HTML recibido hasta el momento mientras espera. Sin embargo, en lo que respecta a la ruta de renderización crítica, cualquier recurso que bloquee el analizador en <head> significa que todo el contenido de la página está bloqueado para que no se procese.
Bloquear el analizador puede generar un alto costo de rendimiento, mucho más que solo bloquear la renderización. Por este motivo, los navegadores intentarán reducir este costo mediante el uso de un analizador de HTML secundario conocido como análisis de precarga para descargar recursos futuros mientras el analizador de HTML principal está bloqueado. Si bien no es tan bueno como analizar el HTML, al menos permite que las funciones de red del navegador funcionen antes que el analizador bloqueado, por lo que es menos probable que se vuelva a bloquear en el futuro.
Identifica los recursos de bloqueo
Muchas herramientas de auditoría de rendimiento identifican recursos que bloquean la renderización y los analizadores. WebPageTest marca los recursos que bloquean el procesamiento con un círculo naranja a la izquierda de la URL del recurso:
Todos los recursos de bloqueo de renderización deben descargarse y procesarse antes de que se pueda iniciar el procesamiento, lo que se indica con la línea sólida verde oscuro en la cascada.
Lighthouse también destaca los recursos que bloquean la renderización, pero de una manera más sutil, y solo si el recurso realmente retrasa la renderización de la página. Esto puede ser útil para evitar falsos positivos en los que, de lo contrario, podrías minimizar el bloqueo de renderización. Si ejecutas la misma URL de página que la figura anterior de WebPageTest a través de Lighthouse, solo se identifica una de las hojas de estilo como un recurso de bloqueo de la renderización.
Cómo optimizar la ruta de renderización crítica
La optimización de la ruta de procesamiento crítica implica reducir el tiempo para recibir el código HTML (representado por la métrica de tiempo hasta el primer byte (TTFB)) como se detalla en el módulo anterior y el impacto de los recursos de bloqueo de renderización. Estos conceptos se investigarán en los siguientes módulos.
La ruta de acceso de renderización crítica con contenido
Durante mucho tiempo, la ruta de renderización crítica se ha preocupado por la renderización inicial. Sin embargo, surgieron más métricas centradas en el usuario para el rendimiento web, lo que cuestiona si el punto final de la ruta de procesamiento crítica debe ser el primer procesamiento de imagen o uno de los más con contenido que siguen después.
Otra opción es concentrarse en el tiempo hasta el Procesamiento de imagen con contenido más grande (LCP) (o incluso el Primer procesamiento de imagen con contenido (FCP)) como parte de una ruta de renderización con contenido (o la ruta de acceso clave, como podrían llamarla otros). En este caso, es posible que debas incluir recursos que no necesariamente bloqueen (como ha sido la definición típica de ruta de acceso de renderización crítica), pero que son necesarios para renderizar pinturas con contenido.
Independientemente de tu definición exacta de lo que definas como “crítico”, es importante que comprendas lo que impide la renderización inicial y el contenido clave. El primer procesamiento de imagen mide la primera oportunidad posible de renderizar cualquier elemento para el usuario. Idealmente, debería incluir algo significativo (no algo como un color de fondo, por ejemplo), pero incluso si no tiene contenido, de todos modos habrá un valor en presentar algo al usuario, que es un argumento para medir la ruta de renderización crítica como se ha definido tradicionalmente. Al mismo tiempo, también es valioso medir cuándo se presenta el contenido principal al usuario.
Cómo identificar la ruta de renderización con contenido
Muchas herramientas pueden identificar elementos LCP y cuándo se renderizan. Además de el elemento LCP, Lighthouse también ayuda a identificar las fases del LCP y el tiempo dedicado a cada una para ayudarte a comprender dónde es mejor enfocar tus iniciativas de optimización:
En el caso de sitios más complejos, Lighthouse también destaca las cadenas de solicitudes críticas en una auditoría independiente:
Esta auditoría de Lighthouse observa todos los recursos cargados con una prioridad alta, por lo que incluye fuentes web y otro contenido que Chrome establece como recurso de alta prioridad, incluso si en realidad no bloquea la renderización.
Pon a prueba tus conocimientos
¿A qué se refiere la ruta de renderización crítica?
¿Qué recursos están involucrados en la ruta de acceso de renderización crítica?
<head><head>.¿Por qué el bloqueo de renderización es una parte necesaria de la renderización de la página?
¿Por qué JavaScript bloquea el analizador de HTML (suponiendo que los atributos defer, async o module no se especifican en un elemento <script>)?
<script> bloquea el analizador y el procesamiento.A continuación: Cómo optimizar la carga de recursos
En este módulo, se abordó parte de la teoría detrás de la manera en que el navegador procesa una página web y, en particular, lo que se necesita para completar la renderización inicial de una página. En el siguiente módulo, se analiza cómo se puede optimizar esta ruta de renderización. Para ello, se aprende cómo optimizar la carga de recursos.