Testing on devices you do not own
A simulator tells you about layout. It cannot tell you how the page feels on a four-year-old Android, and pretending otherwise is how bugs reach production.
Simulator Panel previews a page across several device sizes at once, with DevTools built in — console, network and storage — plus screenshot capture across every device, performance and accessibility profiling, a contrast checker, a touch target validator and custom device configurations.
The multi-device part is what changes the workflow. Resizing one browser window is a sequence; seeing four widths side by side is a comparison, and a comparison is where you notice that the card layout collapses awkwardly at exactly one breakpoint.
Which sizes to actually keep open
The temptation is to add every device in the list. Eight previews means eight small windows and you stop reading any of them.
Four is the number that stays useful:
- A small phone — the narrowest width you claim to support. This is where text wraps badly and buttons collide.
- A large phone — where most of your mobile traffic actually is.
- A tablet in portrait — the size everyone forgets, and the one where desktop layouts appear at the wrong moment.
- A laptop — not a 27-inch monitor. Most desktop visitors are on a 13 or 14 inch screen, and designs built on large monitors routinely break there.
Custom device configurations are worth setting up once if you have a real audience skew — a kiosk resolution, a specific tablet a client uses. Do it once, save it, stop thinking about it.
The two checks worth running every time
Accessibility tooling has a reputation for producing a hundred warnings nobody acts on. Two of these are different, because they fail for reasons you can fix in a minute and they affect real people immediately.
Contrast. Grey text on a white background is the single most common accessibility failure on the web, and it usually arrives when someone lightens a colour to make a design look calmer. The checker gives you a number; if it fails, darken the text rather than arguing with the number.
Touch targets. A control that is fine with a mouse can be genuinely difficult with a thumb. The validator flags anything too small, and the fix is usually padding rather than a redesign. This one matters most on the small phone preview, which is exactly the preview people skip.
Run both before the review, not after. A contrast failure caught in review costs a round trip; caught in the panel it costs a keystroke.
Screenshots across every device at once
The capture-all feature is more useful than it first appears, for one specific reason: it is the fastest way to make a layout problem arguable.
"It looks wrong on mobile" starts a discussion. Four screenshots at four widths attached to the task card ends one. And because the shots come from the same moment, nobody can suggest you were looking at a stale build.
Attach them to the card rather than pasting them into chat. The card is where someone will look in three weeks when they wonder why the padding changed.
What a simulator cannot tell you
This is the part worth being honest about, because the failure mode is silent.
A simulator renders your page at a given size in your own browser engine, on your own machine, over your own connection. It is accurate about layout and useless about everything else.
It will not tell you that the page takes eleven seconds on a four-year-old Android, that the font renders differently on a real iPhone, that the sticky header covers the input when the on-screen keyboard opens, or that the animation stutters on hardware without a decent GPU. Those are the bugs that reach production after a clean simulator pass.
So: use the panel for layout, contrast and touch targets — the things it is genuinely good at — and keep one real cheap Android phone on the desk for everything else. One physical device catches a category of problem no simulator can.
For the performance side of the picture, Web Analyzer measures a page as it is actually served rather than as it renders locally. That is a different question from "does the layout hold", and it is worth asking separately before a launch.
Questions people actually ask
How many device previews should I keep open?
Four: a small phone, a large phone, a tablet in portrait and a laptop. Eight previews means eight small windows and you stop reading any of them. The laptop matters more than a large monitor — most desktop visitors are on 13 or 14 inches.
Which accessibility checks are actually worth running?
Contrast and touch targets, every time. Both fail for reasons you can fix in a minute, and both affect real users immediately. Run them before the review rather than after — in review a contrast failure costs a round trip.
Can I stop testing on real devices?
No. A simulator is accurate about layout and blind to everything else: real-world performance, font rendering, the on-screen keyboard covering an input, animation on weak hardware. Keep one cheap Android phone on the desk.
What is the fastest way to report a layout bug?
Capture screenshots across all devices at once and attach them to the task card. Four widths from the same moment turn "it looks wrong on mobile" from a discussion into a fact, and the card is where someone will look for it later.
