It flashes for 40 milliseconds on my machine and I have declared victory. Deep breath. Let us talk about loading states.
Rant, summarised
A spinner you have never watched for more than 100 ms is untested.
Slow the API on purpose and watch: flicker, layout jumps and dead buttons show up fast.
Fix the ugly ones, keep the delay rule for next time.
The flash of nothing
Fast API, fast UI, everyone is happy. Then a real user on a real connection sees your loader for four seconds, and every design decision you skipped presents its invoice.
It is never the framework. Except when it is the framework.
What to look for once you slow it down
Layout jumps when content replaces the spinner. Reserve space, use skeletons.
Buttons that stay clickable while a request is in flight.
Text that says "Loading..." forever when the request fails.
Spinners that appear for 50 ms and flicker. Delay showing them slightly.
A page that is blank, not loading, when the response is empty.
A delay rule, conceptually
JSON
1{
2"urlPattern":"*/api/products*",
3"delayMs":3000
4}
The practical bit
Add a delay to the endpoint from the dashboard or the DevTools panel, reload, and use the page like a person on a bad train connection. Fix what annoys you. Repeat with a forced 500 for the error branch.
Vimal builds the front-end and runs the search and campaign side of ProxyCeptor, which means he cares about how a page feels and how people find it. He writes code-first guides for developers: the snippet comes before the theory, and the loading spinner gets a fair trial. Expect practical steps, honest opinions about browsers and a soft spot for a well-behaved fetch call.
Manifest V3 removed blocking webRequest, leaving developers wondering how to modify response bodies. Here is why declarativeNetRequest cannot touch payloads and how modern interceptors bypass the limitation.
Local Overrides is Chrome's built-in way to fake a response. It is great for quick edits and awkward for everything else. Here is exactly where the line is.