Bloquear peticiones: la tijera que corta el cable
Cortar recursos por URL o por patrón para comprobar qué pasa sin ellos, con los seis experimentos que esta capacidad hace posibles.
Bloquear un recurso y ver qué pasa es una forma de bisección aplicada a la red: divide el conjunto de cosas que la página carga en las que importan y las que no, y lo hace con la única prueba que de verdad decide, que es quitarlas. Es la herramienta que convierte “creo que este script de terceros nos está costando caro” en un número, y la que permite probar los caminos de degradación que nadie prueba nunca porque hacen falta condiciones que no se pueden provocar.
- Bloquear recursos por URL exacta y por patrón con comodín.
- Diseñar experimentos de bloqueo con una sola variable.
- Probar los caminos de degradación de tu aplicación sin modificar código.
- Medir el coste real de un recurso de terceros.
Cómo se bloquea
Hay dos vías.
Desde el panel de red, con el menú contextual de una petición: bloquear esa URL, o bloquear el dominio entero. Es la más rápida cuando ya estás mirando la lista.
Desde la pestaña de bloqueo de peticiones del cajón inferior, accesible desde el menú de comandos escribiendo blocking. Ahí se ven todos los patrones activos, se pueden añadir a mano, activar y desactivar individualmente, y hay un interruptor general.
Los patrones admiten el comodín asterisco en cualquier posición.
*.woff2
*/analytics/*
https://cdn.terceros.com/*
*/api/pedidos*
*sentry*Las peticiones bloqueadas aparecen en la lista tachadas y en rojo, con el estado correspondiente, y el código de la página recibe un error de red igual que si el servidor no estuviera disponible. Eso es importante: no es un 404, es un fallo de red, que es un camino de error distinto y a menudo peor probado.
El bloqueo es una intervención que persiste mientras las DevTools estén abiertas y que se olvida con facilidad. El indicador es discreto y el síntoma —una página que de repente carece de estilos, o una fuente que no carga— se confunde con un problema real. Cuando algo deje de funcionar sin explicación, la pestaña de bloqueo es de los primeros sitios donde mirar.
Los seis experimentos
Uno: medir el coste de un tercero. Mide la carga completa con el script de terceros y sin él, en las mismas condiciones. La diferencia es su coste real, que casi siempre es mayor que el tamaño del fichero porque incluye la resolución de su dominio, la conexión, la ejecución, y las peticiones que él mismo dispara. Este experimento es el que convierte una discusión de opiniones sobre si merece la pena tener cierta herramienta en un dato.
Dos: probar el fallo de la fuente. Bloquea *.woff2 y observa cómo se ve la página con la tipografía de reserva. Si el diseño se descuadra, tu font-display o tus fuentes de reserva necesitan trabajo. Es un escenario que ocurre de verdad —conexiones malas, redes corporativas que filtran, CDN caídos— y que no se prueba prácticamente nunca.
Tres: probar la degradación sin JavaScript de terceros. Bloquea el dominio de un widget incrustado, un chat de soporte, un mapa. ¿Se rompe la página entera o simplemente falta ese trozo? Un tercero que puede tumbar tu aplicación al caerse es un riesgo que conviene conocer antes de que ocurra.
Cuatro: simular el fallo de una API. Bloquea el endpoint concreto y observa qué hace la interfaz. ¿Aparece un mensaje de error útil, se queda un cargador girando para siempre, o se rompe con una excepción? Este es el camino de error que más se escribe sin probar.
Cinco: verificar la carga diferida. Bloquea un fragmento de código cargado bajo demanda y comprueba que la aplicación se comporta razonablemente cuando ese fragmento no llega. En aplicaciones con división de código por rutas, un despliegue puede dejar temporalmente fragmentos antiguos inaccesibles, y esa situación es exactamente esta.
Seis: encontrar quién depende de qué. Bloquea un recurso y mira qué otras peticiones dejan de hacerse. Es una forma de descubrir la cadena de dependencias más contundente que leer la columna de iniciador, porque prueba la relación en vez de reportarla.
Bloqueo con una sola variable
La disciplina que hace válidos los experimentos anteriores es la misma que la de cualquier otro: un patrón por experimento. La pestaña de bloqueo permite tener varios activos y desactivarlos individualmente, precisamente para poder ir uno por uno sin borrarlos.
El procedimiento para medir el coste de tres terceros distintos.
Mide la línea base sin bloqueos, tres veces, y quédate con la mediana. Una sola medición no vale porque la varianza de red es alta.
Bloquea el primero, mide tres veces. Desactívalo.
Bloquea el segundo, mide tres veces. Desactívalo.
Y así. Al final tienes tres números comparables con la misma línea base.
Bloquear los tres a la vez da un número distinto y también útil —el coste conjunto— pero no permite atribuirlo, y como los terceros compiten entre sí por ancho de banda, el conjunto casi nunca es la suma de las partes.
Lo que el bloqueo no hace
No bloquea lo que ya está en caché. Si el recurso se sirve desde la caché de memoria o desde un service worker, la petición no llega al punto donde se aplicaría el bloqueo. Para experimentos limpios hay que combinar con la caché desactivada y, si hay service worker, saltárselo.
No bloquea peticiones de extensiones.
No simula lentitud. Un recurso bloqueado falla inmediatamente; un recurso lento tarda. Son dos escenarios distintos y el segundo se prueba con throttling, no con bloqueo. En la práctica, el escenario lento suele ser peor: un fallo rápido dispara el camino de error, mientras que una respuesta que tarda treinta segundos deja la interfaz colgada sin que nada la rescate.
Hay una asimetría entre cómo se desarrolla y cómo se usa el software que esta herramienta expone con crudeza. El desarrollo ocurre casi siempre en condiciones ideales: red rápida y estable, servidor local o cercano, todos los servicios funcionando, ninguna extensión bloqueando nada. En esas condiciones, los caminos de error se escriben y no se ejecutan nunca, y el código que no se ejecuta nunca es código que no funciona: un mensaje de error con una variable mal escrita, un estado de carga que no se limpia, un reintento que entra en bucle, un catch que asume una forma de error que no llega. Los usuarios, en cambio, viven en el mundo real: túneles, redes corporativas con filtros, bloqueadores de anuncios que cortan dominios enteros, CDN con incidencias, y conexiones que se caen a mitad de una petición. La proporción de sesiones donde algo falla es mucho mayor de lo que cualquiera imagina desde su escritorio, y en esas sesiones lo que el usuario experimenta no es tu aplicación sino tu manejo de errores. La conclusión operativa es una práctica concreta que casi ningún equipo tiene y que cuesta muy poco: antes de dar por terminada una funcionalidad, bloquea sus peticiones y mírala fallar. Las tres preguntas que hay que poder responder con un sí son si el usuario se entera de que algo ha ido mal, si tiene alguna forma de reintentar sin recargar toda la aplicación, y si el resto de la interfaz sigue siendo usable. Con la pestaña de bloqueo esas tres respuestas se consiguen en dos minutos por funcionalidad, sin escribir ni una línea de código de prueba, sin montar un servidor falso y sin tocar el proyecto. Es probablemente la comprobación con mejor relación entre coste y valor de toda esta guía, y la más fácil de saltarse porque nadie la pide.