E2 · Fetch/XHR Filter: cutting the noise: The Fetch/XHR filter is like a **radio tuning dial**: the ether (all network traffic) is full of hundreds of frequencies (images, CSS, f
The Fetch/XHR filter is like a **radio tuning dial**: the ether (all network traffic) is full of hundreds of frequencies (images, CSS, fonts, ad scripts, API calls); without a filter, loading one page produces dozens of rows and finding the ONE API request you want becomes finding a needle in a haystack. Turning the filter to "Fetch/XHR" leaves only the requests JavaScript itself started from code (exactly your API calls) — static files (images, fonts, styles) go quiet. So why does the browser show EVERYTHING by default, making an API tester's job harder? Because the Network panel is NOT only for testers — a frontend developer doing performance work wants to see ALL resources (images included); the filter lets YOU cut the noise according to YOUR role. The Java equivalent is log-level filtering: at `DEBUG` level EVERYTHING is logged, but you only want to see `ERROR` — you filter by level in log4j/logback, and in DevTools you filter by request TYPE. For QA, working without this filter is a real risk: MISSING the real API request in a 50-row page load means walking right past a defect without ever seeing it.
From Noise to Signal
Clicking the `Fetch/XHR` option in the filter bar above the Network panel reduces the list to only the requests started by JavaScript code (`fetch()`/`XMLHttpRequest`). You can narrow it further with a text search (`bugs`). Together these get you to exactly the API request you want, in seconds, out of dozens of static files.
Unfiltered List → Narrowed with Fetch/XHR
🎬 The One API Request Lost Among 50 Rows
Tester searches by eye
One row: /api/v1/bugs
The page loads: images, fonts, styles, ad scripts, and ONE API request — 50 rows total.
Without a filter the tester searches row by row with their eyes — slow and error-prone.
The "Fetch/XHR" option is selected in the filter bar — only JavaScript-started requests remain.
50 rows shrink to a single row: `GET /api/v1/bugs`. The defect you are looking for can no longer slip past.
The lesson — the filter is not a "nicety"; working without it risks missing a real defect among dozens of unrelated rows.