Los scripts de terceros se han convertido silenciosamente en una de las mayores fuentes de ruido, distorsión y falsos fallos en las pruebas de carga. Cada herramienta de marketing, píxel de analytics, framework de optimización y widget añade otra dependencia remota que su aplicación no controla. Con tráfico real, la mayoría se comportan “suficientemente bien”. Bajo carga sintética, se comportan como minas terrestres y a menudo reportan sus fallos como sus fallos.
Este artículo reduce el problema a lo que realmente ocurre en el navegador, por qué el tráfico sintético exagera estos efectos y cómo realizar pruebas de carga con inteligencia —sin permitir que el código de terceros secuestre sus resultados. Está escrito para equipos que usan LoadView, pero los principios se aplican en cualquier sitio donde realice pruebas de rendimiento basadas en navegador.
El peso oculto del código de terceros
Las páginas modernas no son solo HTML y su propio JavaScript. Son un ensamblaje de:
- Motores de analytics
- Frameworks de pruebas A/B
- Rastreadores de reproducción de sesión (session replay)
- Gestores de etiquetas
- Widgets de chat
- Bibliotecas alojadas en CDN
- Banners de consentimiento
- Balizas publicitarias
- Cargadores de feature flags
Cada uno de estos scripts se ejecuta en su propio cronograma, realiza sus propias llamadas de red y puede bloquear la página de formas que su equipo de backend nunca ve.
En una prueba de carga, no solo está probando su sistema: está probando la disponibilidad global de 15–30 servicios que no posee y que no puede controlar. Algunos son rápidos. Algunos son lentos. Algunos se vuelven inestables cuando genera miles de “visitas” casi idénticas por minuto.
Por eso los equipos suelen ver este patrón:
- Métricas del servidor de aplicación: estables
- Latencia de la base de datos: sin cambios
- Prueba de carga sintética: “página lenta”, “waterfall bloqueado”, “ejecución de JS detenida”
- Cuando esas cosas no correlacionan, el código de terceros es casi siempre el culpable.
Qué ocurre realmente cuando los scripts de terceros se ejecutan durante una prueba de carga
Para entender por qué los resultados se contaminan, observe lo que el navegador tiene que hacer:
- Parsear su HTML.
- Cargar su CSS y JS.
- Detectar scripts externos e iniciar DNS → TCP → TLS → GET.
- Esperar a que el proveedor remoto responda.
- Ejecutar el código que llega.
- Ese código a menudo carga más scripts.
- Esos scripts a menudo hacen más peticiones.
Nada de esto es hipotético. Abra el waterfall de DevTools y lo verá: gestores de etiquetas que generan una docena de scripts adicionales, trackers que obtienen configuraciones, herramientas de replay que cargan recursos de grabación, analytics que llaman a endpoints de batching.
Bajo carga, estas cadenas externas no se aceleran. Se vuelven más lentas. A veces mucho más lentas.
Lo más importante: el navegador no sabe ni le importa que esto sea una prueba de carga. Ejecuta todo exactamente como lo haría para un usuario real. Si el proveedor de terceros se ralentiza, el navegador se ralentiza.
Cómo los scripts de terceros inflan y desvían los resultados
Las pruebas sintéticas en navegador miden lo que los usuarios sienten: LCP, DOMContentLoaded, evento load, TTI y otros hitos en tiempo de ejecución. Los scripts de terceros distorsionan todos ellos de maneras como:
Scripts bloqueantes detienen el parsing
Si una etiqueta script no es async ni defer, el navegador detiene el parsing del HTML hasta que el proveedor remoto responda. Si ese proveedor es lento —o limita la tasa de su tráfico— los tiempos de su prueba se disparan.
La latencia de cola larga altera los percentiles
El rendimiento de terceros es inherentemente errático. Algunas peticiones tardan 50 ms. Otras, 800 ms. Cuando ejecuta una prueba de carga completa, estos outliers se acumulan en sus percentiles 95 y 99, haciendo que su aplicación parezca inestable cuando no lo está.
El código asíncrono aún consume CPU y tiempo del event loop
Incluso si se carga de forma asíncrona, scripts pesados de analytics o replay imponen carga en el runtime de JS. Bajo carga, esto se amplifica.
La expansión del waterfall oculta el verdadero cuello de botella
Cuando cada script de terceros genera cinco peticiones más, identificar qué es suyo y qué es externo se vuelve doloroso. Muchos equipos pierden horas persiguiendo un “problema de latencia del backend” que en realidad es un gestor de etiquetas bloqueado.
En resumen: su sistema puede estar sano, pero su prueba de carga no lo parecerá.
Variabilidad de CDN y latencia en cascada bajo carga sintética
Los scripts de terceros no se ejecutan desde su infraestructura; se ejecutan desde CDNs repartidos por todo el mundo. Esos CDNs enrutan el tráfico según geografía, congestión, acuerdos de peering, mantenimiento en curso y cualquier lógica de balanceo dinámica que estén ejecutando en ese momento. Bajo carga sintética, donde dispara peticiones desde múltiples regiones simultáneamente, esa variabilidad se amplifica.
Cientos de navegadores que solicitan el mismo script externo a la vez pueden ser enrutados a POPs completamente diferentes. Una región puede aterrizar en un nodo edge caliente y responder instantáneamente. Otra región puede golpear un POP congestionado o frío y retardarse unos cientos de milisegundos. Una tercera región puede degradarse temporalmente o reencaminarse, añadiendo aún más imprevisibilidad. Nada de esto refleja la salud de su aplicación, pero todo aparece en los resultados de la prueba como si lo hiciera.
La consecuencia es predecible: una zona de carga que aparece lenta en su informe en realidad no está luchando con sus servidores; está lidiando con un píxel de marketing, una etiqueta de analytics o un script de replay alojado en un CDN cuyo POP más cercano está teniendo un mal momento. Mientras tanto, sus métricas de infraestructura cuentan otra historia: CPU estable, memoria estable, latencia de base de datos sin cambios. Todo en su lado parece estar bien.
Pero su waterfall está inflado con barras externas largas, ejecución de scripts retrasada y hitos de tiempo inflados. Esa discrepancia es la firma típica del código de terceros bajo presión sintética.
Los proveedores de terceros odian las pruebas de carga (problemas de rate-limiting)
Uno de los patrones de fallo más engañosos en pruebas de carga basadas en navegador proviene de que los servicios de terceros se protegen a sí mismos, no de que fallen. Plataformas de analytics, gestores de etiquetas, herramientas de replay y píxeles de marketing están construidos para manejar tráfico normal y orgánico —disperso, irregular y diverso. Para ellos, lo que no están diseñados es para manejar miles de sesiones sintéticas casi idénticas que golpean los mismos endpoints en ráfagas apretadas y uniformes. Para sus sistemas de detección, eso no es “prueba”. Es un ataque.
Así es como ocurre:
- Comienza la prueba de carga.
- Todos los navegadores cargan su página.
- El objetivo de terceros ve una avalancha repetitiva y antinatural.
- El proveedor decide que eso parece scraping o un DDoS.
- Las peticiones se ralentizan o devuelven errores.
- El navegador queda bloqueado esperando respuestas.
- Sus métricas de prueba se hunden.
El resultado parece que su aplicación se desmoronó, cuando en realidad nada en su infraestructura cambió. La CPU permanece plana, la memoria estable, la latencia de la base de datos no se altera. La ralentización no es suya: es un servicio de terceros que limita la tasa porque considera abusivo el tráfico. A menos que inspeccione archivos HAR o rastree cuidadosamente los waterfalls externos, es fácil diagnosticar esto erróneamente como un problema de rendimiento interno. La solución no es ajustar sus servidores, sino reconocer que una dependencia externa se está defendiendo contra su tráfico de prueba.
Por qué los usuarios reales no ven las mismas ralentizaciones (ad blockers y consentimiento)
Una de las mayores brechas entre los resultados sintéticos y el rendimiento real del mundo surge de la simple realidad de que los usuarios reales no cargan todo lo que su entorno de pruebas carga. Una parte significativa de su audiencia usa bloqueadores de anuncios o extensiones de privacidad que impiden que analytics, píxeles de seguimiento y scripts de marketing se ejecuten. Incluso sin extensiones, muchos sitios requieren el consentimiento del usuario antes de cargar esos scripts, lo que los retrasa o suprime por completo.
Los usuarios sintéticos, en cambio, cargan cada dependencia porque se comportan como navegadores limpios sin bloqueo, sin extensiones y sin control de consentimiento. Eso significa que cada script de terceros —etiquetas de seguimiento, herramientas de replay, frameworks de optimización y más— se ejecuta en cada sesión sintética, aunque un gran porcentaje de usuarios reales nunca los active.
El resultado es una discrepancia predecible: la producción parece estable, mientras que la prueba de carga muestra tiempos inflados y waterfalls pesados. La prueba no está equivocada —mide un escenario en el que se aplica de forma uniforme todo el peso de los scripts de terceros—, pero tampoco refleja la distribución real del comportamiento del usuario, por eso estas discrepancias aparecen tan frecuentemente.
Cuándo incluir scripts de terceros en las pruebas de carga — y cuándo bloquearlos
No existe un único enfoque correcto. Depende de lo que esté midiendo.
Incluya scripts de terceros si le importan:
- La experiencia real del usuario
- Tiempos UX (LCP, FID, TTI)
- El renderizado de la página bajo tráfico pico
- Cómo se comporta su sitio cuando todo —incluido el “fluff” de marketing— está activo
Exclúyalos o bloquéelos si le importan:
- Escalabilidad del backend
- Rendimiento de las API
- Capacidad de la base de datos
- Cuellos de botella de infraestructura
- Optimización de red y balanceadores
- SLAs de rendimiento y tasa de errores
El enfoque inteligente —el que adoptan la mayoría de los equipos maduros— es ejecutar ambos:
- Ejecuciones limpias (bloquear o emular dependencias externas).
- Ejecuciones completas (permitir que el navegador cargue todo).
La diferencia entre ambas le dice exactamente cuánto peso están añadiendo los proveedores de terceros a su experiencia real.
LoadView facilita esto: use las funciones de blocklist/allowlist para ejecutar ambos escenarios sin reescribir scripts.
Los scripts de terceros no son solo frontend
Un malentendido frecuente en las pruebas de carga es suponer que los scripts de terceros solo interactúan con proveedores externos y por tanto no afectan su propia infraestructura. En la práctica, esto es raro. Muchos scripts obtienen datos, envían eventos o solicitan configuraciones directamente a su backend, creando tráfico adicional que los equipos suelen pasar por alto.
Ejemplos incluyen:
- Frameworks de pruebas A/B consultando su API por la configuración de experimentos.
- Scripts de personalización solicitando atributos del usuario autenticado.
- Scripts de atribución enviando transiciones de página o marcadores de sesión.
- Widgets de chat consultando endpoints de disponibilidad o listas.
- Herramientas de analytics agrupando eventos hacia su propio dominio para evitar bloqueos cross-site.
El resultado es un efecto de amplificación silencioso: un solo script de terceros puede generar varias llamadas adicionales al backend por carga de página. Bajo carga, esto se multiplica de forma dramática: lo que parecía una prueba “solo frontend” genera tráfico backend significativo. Si sus métricas de infraestructura muestran picos inesperados de API o mayor actividad de base de datos durante un escenario centrado en UI, este patrón de interacción suele ser la causa.
Reconocer estos puntos de contacto backend ocultos es esencial para interpretar correctamente los resultados de la prueba de carga. Sin tenerlos en cuenta, es fácil culpar a la parte equivocada del sistema o subestimar la demanda real que enfrenta su aplicación bajo el comportamiento de los navegadores.
Pruebas más inteligentes: stubs, mocks, overrides y comportamiento externo controlado
Cuando el objetivo es ejecutar pruebas de carga limpias y fiables, el objetivo no es fabricar una realidad distinta, sino aislar el sistema específico que desea medir. Las dependencias de terceros introducen ruido, imprevisibilidad y comportamientos de rate-limiting que no tienen nada que ver con su infraestructura. Controlar esas variables le permite medir su propio rendimiento sin heredar la inestabilidad de servicios externos.
Una opción es usar overrides de DNS, dirigiendo dominios conocidos de terceros a un endpoint mock local que responda instantáneamente. Esto permite que el navegador complete la secuencia de peticiones esperada sin esperar a CDNs o proveedores de analytics remotos. Bloquear scripts logra el mismo resultado con menos configuración: en LoadView puede simplemente bloquear dominios como googletagmanager.com, hotjar.com u optimizely.com para que el navegador no pierda tiempo cargándolos o ejecutándolos durante la prueba.
Los endpoints mock ofrecen otra capa de control al devolver payloads mínimas y previsibles. Esto mantiene la ejecución de scripts consistente entre ejecuciones y elimina la latencia de cola larga que de otra forma contaminaría las métricas de tiempo. En algunos casos, los equipos optan por alojar copias de reserva de bibliotecas externas localmente para controlar tanto la disponibilidad como el tiempo de respuesta sin alterar la lógica de la aplicación.
Todas estas técnicas preservan un comportamiento de navegador realista mientras eliminan los retrasos y fallos aleatorios que los servicios de terceros introducen bajo carga. El resultado es una prueba que refleja el rendimiento de su aplicación —no la salud o el nivel de congestión del CDN de otro.
Cómo LoadView gestiona el ruido de scripts de terceros en las pruebas de carga
Las pruebas de carga basadas en navegador de LoadView le dan la visibilidad necesaria para separar “su código es lento” de “el servicio de otro se ahogó”.
Ventajas clave:
- Visibilidad a nivel Waterfall: Vea exactamente qué peticiones de terceros bloquearon la página.
- Bloquear/Permitir dominios externos: Ejecute pruebas de comparación limpias vs. completas sin mantener múltiples versiones de scripts.
- Ejecución a nivel navegador: Mida exactamente lo que experimentan los usuarios —incluso si los scripts de marketing están lastrando la performance.
- Zonas de carga (Load Zones): Detecte ralentizaciones externas específicas por geolocalización que de otro modo se atribuirían a sus servidores.
- Control de scripting (Selenium): Inyecte condiciones para prevenir llamadas externas o reemplazarlas por mocks previsibles.
Esto es lo que requieren las pruebas de carga modernas: control fino sobre el ruido.
Leer los resultados: no persiga fantasmas de terceros
Cuando una prueba se desmadra, aquí tiene un patrón de triage rápido que evita que los equipos persigan la raíz de causa equivocada.
Si las métricas del servidor son estables pero los resultados del navegador se ven mal:
Casi siempre son scripts de terceros o sobrecarga de ejecución del lado del cliente.
Si los percentiles 95/99 se disparan mientras las medias permanecen limpias:
Ese es el clásico comportamiento long-tail de terceros.
Si solo una zona geográfica de carga está lenta:
Golpeó un POP de CDN externo que está teniendo un mal momento.
Si los fallos muestran errores DNS o TLS para dominios externos:
Está siendo rate-limited o bloqueado.
Si el tráfico backend es mayor de lo esperado durante una prueba “frontend”:
Algún script “solo del lado cliente” está llamando secretamente a sus APIs.
Interpretar correctamente los resultados no es solo una habilidad —es un requisito para pruebas válidas.
Conclusión
Los scripts de terceros no van a desaparecer. Cada equipo de marketing, proveedor de analytics y producto de personalización añade otra dependencia a la página. Así funciona la web moderna.
Pero las pruebas de carga no deben permitir que el servidor lento de otro le convenza de que su infraestructura está fallando.
Las pruebas realistas significan:
- Saber cuándo incluir código de terceros
- Saber cuándo bloquearlo
- Saber cómo interpretar la diferencia
- Ejecutar escenarios limpios y completos
- No permitir que el ruido del CDN o proveedores de analytics que limitan la tasa distorsionen sus SLAs
LoadView da a los equipos la visibilidad y el control para hacer exactamente eso —probar el sistema que usted opera realmente, no el montón de scripts externos pegados a él.