Defina un presupuesto de rendimiento para scripts externos

Defina el presupuesto de scripts externos según bytes transferidos, costo de ejecución y condiciones de carga, y asigne a alguien para hacerlo cumplir. Contar etiquetas no basta: un cargador pequeño puede descargar mucho código después. El presupuesto debe cubrir el comportamiento que introduce, no solo el primer archivo del HTML.

También es una decisión de compra. Cada chat o herramienta de seguimiento pide a los visitantes tiempo y recursos de su dispositivo antes de que se haya demostrado su utilidad para el negocio.

Inventaríe la función antes de medir el costo

Para cada herramienta, registre responsable, propósito, plantillas afectadas, condición de carga y método de eliminación. Pregunte qué decisión permite tomar o qué tarea del visitante resuelve. “Lo pidió mercadeo” explica su origen, pero no justifica cargarla indefinidamente en todas partes.

Separe las dependencias necesarias para la tarea principal de los complementos opcionales. Una dependencia del pago y un video insertado en un artículo no deberían heredar automáticamente la misma política de carga.

Revise también las herramientas del administrador de etiquetas. Una aplicación ligera puede quedar debajo de una colección costosa de scripts inyectados.

Presupueste el recorrido que realmente prueba

Elija condiciones repetibles: perfil de dispositivo, red, navegador, caché y estado de consentimiento cuando corresponda. Defina el período de observación. Pruebe la navegación inicial por separado de abrir el chat o reproducir contenido.

La guía de web.dev sobre JavaScript de terceros explica cómo comparar bloqueando dominios externos para aislar su efecto. Use esa comparación para diagnosticar y después confirme que el recorrido real funcione con la política de carga prevista.

Limite tanto transferencia como ejecución. Los bytes no revelan código que llega rápido pero ocupa el hilo principal. Conserve trazas o reportes para revisar excepciones con evidencia, en lugar de discutir capturas de una puntuación.

Una decisión de presupuesto hipotética

Suponga que un sitio hipotético de servicios limita todos sus scripts externos a 200 KB de transferencia comprimida y 120 milisegundos de trabajo atribuido en el hilo principal durante los primeros cinco segundos de una navegación móvil controlada. Son límites ilustrativos del proyecto, no estándares ni mediciones de 5e Labs.

En el ejemplo, la analítica utiliza 60 KB y 30 milisegundos. Un chat propuesto agrega 110 KB y 160 milisegundos. La transferencia conjunta cabe, pero la ejecución supera el presupuesto. Aprobarlo solo por el peso del archivo ocultaría el problema.

El equipo podría cargar el chat después de una solicitud explícita, buscar una alternativa ligera o documentar por qué acepta una excepción. Vuelva a probar la interacción que lo abre; posponer el costo no lo elimina. Compruebe además que un fallo del proveedor no bloquee el formulario normal de consultas.

Ponga fecha de revisión a las excepciones

Antes de aprobar un script, confirme:

• Una persona puede explicar para qué sirve.
• Las plantillas afectadas y el momento de carga son intencionales.
• Las mediciones incluyen las dependencias descargadas.
• La página sigue siendo útil si falla el proveedor.
• Existe una fecha de revisión y una forma de retirarlo.

Agregar async no resuelve todo. MDN documenta su comportamiento: la descarga asíncrona no elimina el costo de ejecución ni conserva el orden entre dependencias.

Empiece desactivando una herramienta opcional en una prueba controlada y compare el mismo recorrido. Use esa evidencia para definir el presupuesto inicial con desarrollo web de 5e Labs, en vez de elegir un límite que solo acomode todas las etiquetas instaladas.