Using the DevTools inside the panel
The multi-device preview gets the attention. The DevTools underneath it are the reason you stop switching to a browser.
Simulator Panel has console, network and storage tools built in, alongside performance and accessibility profiling. Most people use the device preview and never open these, which is a shame, because they answer the questions the preview raises.
Network first, always
When a page misbehaves at one width and not another, the network tab settles it in seconds. You are looking for two things: a request that failed silently, and a request that fired twice.
The second is the one that surprises people. A component that re-renders on resize often re-requests, and the only place that shows up is a network panel with two identical rows. The page still works, so nobody notices until the bill or the rate limit arrives.
The console at each width, not just one
Errors are not width-independent. A layout that collapses at a small breakpoint can throw where the desktop one does not — a measurement that returns zero, an element that is not in the DOM yet at that size.
So read the console in the small-phone preview specifically. It is the one people skip and the one where errors cluster.
Storage, for the bug that only happens to you
The storage tool is how you settle "it works on my machine". Half of those cases are a stale value in local storage from an older build — a feature flag, a cached token, a dismissed banner that will never come back.
Clear it and reload before you spend an hour on a bug that no new visitor will ever see.
The profiling run worth doing once
Before a launch, run performance and accessibility profiling at the smallest width you support. Not desktop — the small phone is where a heavy page becomes genuinely slow and where touch targets fail.
One caveat worth stating plainly: this measures the page in your browser on your machine. It tells you about the page, not about a four-year-old Android on a train. Treat a good score as necessary rather than sufficient.
Questions people actually ask
Why check the console at more than one width?
Errors are not width-independent. A layout that collapses at a small breakpoint can throw where desktop does not — a measurement returning zero, an element not yet in the DOM at that size. The small-phone preview is where errors cluster.
How do I catch a duplicated request?
The network tab shows two identical rows. Components that re-render on resize often re-request, the page keeps working, and nobody notices until a rate limit or a bill arrives.
Is a good profiling score enough before launch?
No. It measures the page in your browser on your machine. It is necessary but not sufficient — a real low-end phone on a real network is the test it cannot replace.
