Reduce el bloqueo del renderizado identificando el CSS y JavaScript que el navegador procesa antes de mostrar contenido útil y desplazando el trabajo innecesario fuera de esa ruta. Mantén los estilos esenciales disponibles, elige modos de carga adecuados y evita convertir todo en precarga. Busca una primera vista correcta más temprana, no solo borrar una advertencia a costa de contenido sin estilo o funciones rotas.
Separa renderizado, análisis y trabajo del hilo principal
El navegador convierte HTML en DOM y los estilos en información de presentación. Combina estructura y reglas, calcula la disposición y pinta píxeles. Una hoja que se aplica al documento puede detener el renderizado porque el navegador necesita sus reglas para decidir el aspecto.
Los scripts clásicos sin async ni defer pueden pausar el análisis de HTML mientras se descargan y ejecutan. Este bloqueo del analizador es distinto de una instrucción explícita de bloqueo de renderizado, aunque puede retrasar descubrimiento y primera vista. Un script también puede esperar una hoja bloqueante anterior porque necesita consultar estilos. Importa la cadena de dependencias, no solo la extensión.
Un script descargado de forma asíncrona sigue ejecutándose en el hilo principal salvo que se traslade expresamente su trabajo. Una ejecución larga retrasa renderizado e interacción después de descargar. Los atributos cambian la planificación, no eliminan el trabajo.
Localiza el evento visible afectado. Si una imagen aparece tarde, separa descarga del CSS o JavaScript que impide mostrarla. La guía LCP distingue esas etapas. Si la página se ve pronto pero no responde, utiliza el análisis de ejecución JavaScript.
Lee las dependencias con las herramientas actuales
«Eliminar recursos que bloquean el renderizado» sigue apareciendo en búsquedas e informes antiguos. Lighthouse 13 trasladó muchas auditorías de rendimiento a estadísticas; los informes nuevos pueden mostrar una estadística de solicitudes bloqueantes. El principio permanece, pero los identificadores y ubicaciones antiguos pueden no existir en JSON reciente.
Graba una navegación en Performance e inspecciona la cascada Network. Identifica documento, CSS, scripts, fuentes y recurso LCP. Busca solicitudes descubiertas después de otro archivo y revisa sus iniciadores. Una hoja pequeña encadenada con @import puede comenzar más tarde que otra mayor enlazada directamente.
Conserva una captura o secuencia visual de referencia. Un primer dibujo más rápido con navegación rota o contenido sin estilo no es necesariamente una mejora. Revisa la página completa: el código ausente de la primera pantalla puede servir al contenido inferior.
No sumes ahorros de distintas estadísticas como mediciones independientes. Pueden describir la misma cadena. Aplica un cambio coherente y comprueba tiempos y presentación reales.
Mantén el CSS crítico pequeño y sostenible
El CSS crítico contiene las reglas de la disposición visible inicial. Incluir un conjunto seleccionado en HTML puede evitar su solicitud separada. Incluir la hoja completa del sitio es otra cosa: agranda cada respuesta y evita reutilizarla como archivo independiente en caché.
El primer viewport depende de dispositivo, idioma, consentimiento y contenido. Un conjunto extraído de una captura de escritorio puede omitir navegación móvil, títulos traducidos o errores. Trata la extracción como parte del build con plantillas representativas y comprobaciones visuales.
Este ejemplo incluye la disposición esencial y carga una hoja exclusiva de impresión con una condición de medios.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Performance notes</title>
<style>
body { margin: 0; font-family: system-ui, sans-serif; line-height: 1.6; }
header, main { max-width: 70rem; margin-inline: auto; padding: 1rem; }
img { max-width: 100%; height: auto; }
</style>
<link rel="stylesheet" href="/styles/print.css" media="print">
</head>
<body>
<header>Performance notes</header>
<main><h1>A readable first render</h1><p>Essential content is available immediately.</p></main>
</body>
</html>Una condición que no coincide evita que la hoja bloquee el medio actual, aunque el navegador puede descargarla. No pongas media="print" en una hoja de pantalla y la dejes así: cambia dónde se aplican las reglas. Las técnicas que cambian el medio al terminar la carga deben contemplar fallos de scripts, Content Security Policy y contenido sin estilo.
Si insertas CSS, respeta la política CSP con el nonce o hash previsto. No debilites una política existente solo para copiar un ejemplo. El build debe sincronizar reglas críticas y hoja completa para evitar que reglas antiguas provoquen un salto posterior.
Divide CSS según necesidades reales
Una base compartida más estilos por ruta o componente evita que un artículo sencillo descargue todo el diseño de una aplicación compleja. Mantén la base pequeña y carga estilos cuando exista el componente. Demasiados archivos diminutos añaden planificación y mantenimiento; divide por funciones significativas.
Elimina cadenas @import innecesarias cuando controles la compilación. Descubrir una hoja dentro de otra añade una dependencia. Enlazar estilos esenciales en HTML o resolver importaciones durante el build explicita el descubrimiento. El problema es la cadena de solicitudes, no que toda regla importada sea lenta.
Evalúa CSS-in-JS en ejecución. Algunas implementaciones necesitan descargar y ejecutar JavaScript antes de insertar estilos, lo que retrasa su descubrimiento y puede añadir recálculos. Extraer en servidor o compilación cambia esa ruta, pero depende de biblioteca, framework y versión.
Inspecciona la respuesta generada, no solo el código de componentes. Un framework puede extraer CSS ya, mientras otra configuración lo inyecta durante la ejecución. Comprueba si el HTML inicial incluye estilos utilizables antes de sustituir bibliotecas.
Elige async, defer y módulos por sus dependencias
La carga debe corresponder a la función del script. Uno independiente tolera distinto orden; el código que depende del DOM o de una biblioteca quizá no. Añadir async a todo puede crear carreras.
Estos modos de scripts externos tienen comportamientos diferentes.
| Forma | Descarga | Ejecución y orden |
|---|---|---|
| Clásico sin atributos | Puede detener el analizador | Ejecuta antes de continuar el análisis |
Clásico con defer |
Paralela al análisis | Después del análisis, por orden del documento, antes de DOMContentLoaded |
Clásico con async |
Paralela al análisis | Cuando está listo, sin orden documental garantizado |
type="module" sin async |
Descarga el grafo mientras continúa el análisis | Diferido por defecto, con dependencias en el grafo |
Mantén el orden de scripts clásicos dependientes con defer.
<script src="/scripts/vendor.js" defer></script>
<script src="/scripts/navigation.js" defer></script>Para una entrada modular, declara el tipo y expresa dependencias mediante importaciones.
<script type="module" src="/scripts/app.js"></script>Un script verdaderamente independiente puede utilizar async.
<script src="/scripts/independent-widget.js" async></script>Son alternativas para recursos distintos, no tres versiones de una misma función. defer no tiene efecto útil en un script clásico en línea. Los módulos ya son diferidos; async cambia cuándo se ejecuta su grafo. Consulta la documentación del elemento script antes de modificar una página mixta antigua.
Después prueba menús, búsqueda, validación, pago y consentimiento según proceda, y revisa Console. Una biblioteca con defer puede ser consultada demasiado pronto por un script clásico en línea posterior. Corrige la dependencia, no cambies atributos hasta que una recarga funcione por casualidad.
Usa preload y preconnect para retrasos concretos
Preload anuncia un recurso de la página antes de su descubrimiento normal. No aplica CSS, ejecuta scripts ni muestra imágenes por sí mismo. Sigue necesitando su consumidor habitual y una solicitud compatible.
Este ejemplo adelanta una fuente que el CSS utilizará de inmediato.
<link rel="preload" href="/fonts/site-regular.woff2"
as="font" type="font/woff2" crossorigin>Utiliza as y modo de solicitud correctos. Las pistas incorrectas pueden generar una segunda descarga o una transferencia inútil. No precargues todo: priorizar recursos no esenciales hace competir a los verdaderamente críticos.
Preconnect aborda el establecimiento de conexión, no los bytes ni la ejecución. Puede ayudar con un origen externo crítico descubierto tarde. Limítalo a orígenes necesarios pronto y utiliza el modo CORS apropiado. Una conexión del mismo origen ya utilizada para el documento normalmente no necesita otra pista por compartir más archivos.
modulepreload tiene semántica específica para descargar y preparar módulos. Aprovecha las pistas del framework y examina su salida. No las sustituyas mecánicamente por precargas genéricas sin entender el grafo y el modo de solicitud.
Utiliza Coverage como registro, no como orden de borrado
Coverage muestra partes usadas y sin usar de CSS y JavaScript durante la actividad registrada. Abre el panel, inicia con una recarga y utiliza la página: menús, diálogos, desplazamiento, pestañas y diseños adaptables con componentes diferentes.
«Sin usar» significa sin usar durante esa grabación. El código puede servir a otra ruta, una interacción posterior, un error o un idioma. Las reglas móviles pueden parecer sobrantes al probar solo escritorio. No borres todas las regiones rojas de una única sesión.
Relaciona paquetes grandes con módulos, plantillas o complementos originales. Elimina funciones obsoletas, carga dependencias solo en sus rutas o configura el build para quitar código realmente inalcanzable. Evita editar paquetes generados que la siguiente compilación sobrescribirá.
Repite las pruebas y registra interacciones incluidas. Coverage es más útil junto a un grafo de dependencias y comprobaciones visuales o funcionales. No demuestra que una aplicación dinámica nunca necesite una función.
Revisa conjuntamente las transformaciones del CMS
Tema, caché y complementos pueden combinar estilos, retrasar scripts o reescribir pistas a la vez. El HTML resultante puede diferir mucho de la pantalla de ajustes. Inspecciona respuesta e iniciadores.
No actives todas las opciones de retraso juntas. Guarda una referencia comprensible, modifica una capa y verifica recorridos críticos. Algunos scripts deben preceder una inicialización en línea; algunos estilos sirven a un banner o menú ausente en la prueba de escritorio.
Invalida la caché pertinente tras cambiar plantillas y comprueba respuestas nuevas y almacenadas. Una inconsistencia aparente puede ser dos versiones del sitio, no una anomalía de planificación. Mantén una forma de revertir el ajuste.
Verifica una primera vista correcta más temprana
Repite la navegación bajo condiciones constantes y compara contenido útil inicial, LCP, movimiento y trabajo del hilo principal. Comprueba toda la página e interacciones importantes. Menos solicitudes bloqueantes es evidencia útil cuando experiencia y funciones siguen correctas.
Incluye pantalla estrecha, título traducido largo y caché vacía. Si las fuentes retrasan el texto, continúa con optimización de fuentes web. Registra dependencias en la lista de rendimiento y usa las guías de velocidad para el siguiente cuello de botella. Conserva los cambios cuyo beneficio resista pruebas repetibles.
