¿Qué es la ruta de renderizado crítica?

¿Qué es la ruta de renderizado crítica?

La ruta de renderizado crítica (Critical Rendering Path, CRP) es la secuencia de pasos con la que el navegador convierte HTML, CSS y JavaScript en píxeles en pantalla: construir el DOM, construir el CSSOM, combinarlos en un árbol de renderizado, calcular el diseño y, por último, pintar. Todo lo que el navegador debe descargar y procesar antes de ese primer pintado está en la ruta, así que acortarla es la forma de mostrar contenido antes a los visitantes.

Cómo recorre el navegador la ruta

• DOM. El navegador analiza el HTML en tokens, luego en nodos y construye el Document Object Model. Es un proceso incremental, así que puede empezar antes de que llegue todo el archivo. Según MDN, cuantos más nodos haya, más tardan los pasos siguientes.
• CSSOM. El CSS se analiza y forma el CSS Object Model. A diferencia del DOM, no es incremental, porque las reglas posteriores pueden sobrescribir las anteriores.
• Árbol de renderizado. Se combinan el DOM y el CSSOM. El árbol solo contiene el contenido visible: los elementos con display: none y sus descendientes quedan fuera, igual que el head.
• Diseño (layout). El navegador calcula el tamaño y la posición de cada elemento. Depende del ancho del viewport, por lo que se repite cada vez que se cambia el tamaño de la ventana o se gira el dispositivo.
• Pintado (paint). El navegador dibuja los píxeles. Al cargar se pinta toda la pantalla; después solo se repintan las zonas que cambian.

Las métricas de un informe de velocidad se apoyan en esta ruta. First Contentful Paint es el primer momento en que se pinta contenido, así que cada milisegundo que la ruta pasa esperando se suma directamente a ese valor.

Qué bloquea la ruta

El CSS bloquea el renderizado. Según MDN, el navegador retiene el renderizado hasta recibir y procesar todo el CSS, porque las reglas pueden sobrescribirse y no se puede dibujar el contenido antes de que el CSSOM esté completo.

Los scripts clásicos bloquean el análisis. Un script sin async, defer ni type="module" se descarga y ejecuta de inmediato, antes de que el navegador siga analizando la página (MDN). Lighthouse marca como bloqueante un script en el head sin defer o async, y un enlace a una hoja de estilos cuyo media coincide con el dispositivo. Los dos atributos se comportan distinto: defer ejecuta el script tras el análisis, en el orden del documento y antes de DOMContentLoaded; async lo ejecuta en cuanto se descarga, sin orden garantizado. Consulta la carga asíncrona para saber cuándo usar cada uno.

Ejemplo

Una página de marketing carga una hoja de estilos grande para todo el sitio, un script de gestor de etiquetas en el head y una librería de carrusel. El primer pintado espera a la hoja de estilos y a que el script se descargue y se ejecute, aunque el visitante solo necesita al principio el titular y la imagen principal. La solución tiene tres partes: incluir en línea, dentro de un bloque <style>, las pocas reglas de la parte visible, añadir defer a los scripts que la primera pantalla no necesita y pedir pronto la imagen principal con un resource hint.

<style>/* solo las reglas de la primera pantalla */</style>
<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">
<script src="/app.js" defer></script>

Cómo acortar la ruta

• Menos recursos críticos. Elimina todo lo que la primera pantalla no necesite. La pestaña Coverage de Chrome DevTools muestra el CSS y el JavaScript sin usar.
• Recursos críticos más pequeños. Minifica y comprime el CSS y el JavaScript, y evita que el DOM crezca sin necesidad.
• CSS crítico en línea y el resto cargado sin bloquear. Si divides las hojas de estilo con el atributo media, el navegador solo se bloquea con las que coinciden con el dispositivo.
• defer o async para los scripts que no hacen falta en el primer pintado.
• Mejor orden. Haz que los archivos que se descubren tarde, como una imagen de fondo en CSS o una fuente, empiecen pronto con un hint.

Errores frecuentes

• Incluir todo el CSS en línea. Cada página pesa más y la hoja de estilos pierde la caché; incluye solo lo que necesita la primera pantalla.
• Poner async en scripts que dependen entre sí. El orden no está garantizado, así que ahí conviene defer.
• Retrasar un script que construye contenido visible, porque puede dejar un hueco vacío o hacer que el diseño salte después.
• Ajustar los selectores CSS para ganar velocidad. MDN señala que la mejora es solo de microsegundos; es mejor dedicar el tiempo a los archivos bloqueantes.
• Comprobar solo con una conexión de escritorio rápida. En un móvil lento, cada petición bloqueante cuesta más.

Relación con las pruebas y el monitoreo

Las auditorías de laboratorio enumeran las peticiones que bloquean el renderizado de una página, y la cascada muestra qué esperó el primer pintado. Para seguirlo en el tiempo, LoadFocus Page Speed Monitoring ejecuta auditorías de Google Lighthouse con una programación que va de cada hora a cada semana, desde 25 regiones en la nube, con alertas por correo, Slack o Microsoft Teams. El verificador gratuito de Core Web Vitals muestra LCP, INP y CLS de usuarios reales a partir de los datos CrUX de Google, para ver si una corrección llegó a los visitantes. Hay más mejoras de frontend en la guía de 10 pasos para acelerar tu web. Las definiciones exactas están en la guía de MDN sobre la ruta de renderizado crítica.

Preguntas frecuentes: ruta de renderizado crítica

¿Cuáles son los pasos de la ruta de renderizado crítica?

Construir el DOM a partir del HTML, construir el CSSOM a partir del CSS, combinarlos en un árbol de renderizado con el contenido visible, calcular el diseño y pintar los píxeles.

¿JavaScript bloquea el renderizado?

Un script clásico sin async, defer ni type module bloquea el análisis del HTML mientras se descarga y se ejecuta, y Lighthouse lo marca como bloqueante si está en el head. Con defer o async deja de bloquear.

¿Por qué el CSS bloquea el renderizado?

Las reglas CSS posteriores pueden sobrescribir las anteriores, así que el navegador espera a que el CSSOM esté completo antes de dibujar nada.

¿Qué es el CSS crítico?

Es el pequeño conjunto de reglas necesarias para dibujar la primera pantalla. Se incluye en línea en el head y el resto del CSS se carga sin bloquear el primer pintado.

¿Cómo mido la ruta de renderizado crítica?

Ejecuta una auditoría de Lighthouse para ver las peticiones bloqueantes y lee una cascada de red para ver qué esperó el primer pintado. Repite la medición desde varias regiones y con una conexión limitada.