Recursos para bloquear el renderizado

Los recursos que bloquean la renderización son archivos que el navegador debe descargar y procesar antes de poder mostrar cualquier contenido. Se trata principalmente de hojas de estilo a las que se hace referencia en la cabecera del documento y de scripts síncronos que se encuentran durante el análisis, y son la razón más común por la que una página tarda más en cargarse de lo que justifica su contenido.

Las hojas de estilo bloquean la carga por una razón justificable. Si se mostrara el contenido antes de que los estilos estén disponibles, se produciría un destello de contenido sin estilo seguido de un redibujado brusco, por lo que los navegadores esperan. El problema no radica en que las hojas de estilo bloqueen la carga, sino en que los sitios web suelen cargar mucho más estilo del que requiere la vista inicial, incluyendo estilos para componentes posteriores, otras plantillas y funciones que el visitante quizás nunca utilice; todo esto debe cargarse antes de que se muestre nada.

Los scripts se bloquean porque un script encontrado durante el análisis puede modificar el documento, por lo que el analizador se detiene hasta que se haya ejecutado. La mayoría de los scripts no requieren este comportamiento: las herramientas de análisis, los widgets de chat, las herramientas de personalización y la mayor parte del código de la aplicación pueden ejecutarse después de que se haya analizado el documento sin perder ninguna corrección. Agregar el atributo `defer` permite que el análisis continúe y ejecute los scripts en orden posteriormente, mientras que `async` los ejecuta tan pronto como llegan sin garantías de orden.

La solución habitual para las hojas de estilo consiste en separar los estilos necesarios para la ventana gráfica inicial del resto. La parte crítica se inserta directamente en el documento, por lo que no se requiere ninguna solicitud, y el resto se carga de forma que no bloquee la compilación. Esto es eficaz, pero aumenta la complejidad del proceso, ya que el conjunto crítico debe regenerarse cada vez que cambian los estilos, y el CSS crítico obsoleto produce defectos visibles.

Los recursos de terceros suelen ser los que más contribuyen al costo y los más difíciles de controlar. Los gestores de etiquetas, las plataformas de consentimiento, los proveedores de fuentes, las herramientas de chat y los marcos de prueba generalmente se agregan al encabezado del documento con un comportamiento de bloqueo, y cada uno requiere una conexión a un origen independiente. El retraso acumulado es considerable, y dado que cada uno fue agregado por un equipo diferente por una razón justificable, nadie es responsable del total. Auditar el costo total y atribuirlo a la función solicitante es lo que permite visualizar la compensación.

Las fuentes requieren un manejo especial porque bloquean la visualización del texto, no la estructura de la página. Dependiendo de la estrategia de visualización, el texto puede permanecer invisible mientras se descarga una fuente, lo que significa que el contenido que ya se ha cargado por completo se oculta deliberadamente. Elegir una estrategia que muestre el texto alternativo de inmediato y lo reemplace cuando la fuente se cargue, y precargar las fuentes que se usan en la parte visible de la página, evita que una página se muestre técnicamente pero aparezca en blanco.

Medir el costo real requiere cuidado, ya que eliminar un recurso que bloquea el flujo no siempre produce el ahorro previsto. Los recursos se descargan en paralelo, por lo que eliminar uno puede simplemente permitir que otro se convierta en la limitación, y la mejora observada suele ser menor que la suma de las estimaciones individuales. Verificar mediante mediciones después de cada cambio, en lugar de confiar en los totales proyectados, permite mantener las expectativas precisas.

Identificar qué es lo que realmente causa el bloqueo es sencillo con las herramientas estándar, que informan sobre los recursos que lo impiden y estiman el ahorro que se obtendría al solucionar cada uno. Estas estimaciones deben considerarse indicativas, no precisas, ya que eliminar un recurso que causa el bloqueo suele revelar que otro era la verdadera limitación, y las mejoras se verifican mejor mediante mediciones que a partir del informe.

Debido a que los recursos involucrados suelen ser agregados por varios equipos a lo largo del tiempo, la remediación requiere tanto gobernanza como ingeniería. En la práctica, la auditoría y la priorización se encuentran dentro de rendimiento web trabajo, los cambios de compilación se implementan a través de desarrollo de productosy las decisiones sobre qué herramientas de terceros justifican su costo de bloqueo necesitan un acuerdo con los equipos que las solicitaron, lo que para la mayoría de los sitios significa el departamento de marketing digital.