Testing across real devices

You own one or two devices. Your visitors have hundreds. This lesson is how to get reasonable confidence without buying anything, and — more usefully — what device emulation does not tell you, because that is where the bugs you ship come from.

Start in the browser

Device mode — Ctrl + Shift + M (Cmd + Shift + M) — is the first pass and catches most layout problems.

Two habits worth forming:

Use the responsive handle, not the device presets. Drag the width slowly from 320px upward and watch for the point where something breaks. The presets check three widths; dragging checks all of them, and real bugs sit between presets far more often than on them.

Reload after switching. Anything that runs on load — a srcset choice, a matchMedia check — does not re-evaluate when you resize.

The widths that actually matter

320px   the narrowest you should support. Older small Androids, and any phone at 200% zoom
360px   the most common Android width in India by a wide margin
390px   current iPhone
768px   tablet portrait / small laptop
1024px  tablet landscape
1440px  common laptop

320px is the real test. If it works at 320 it works everywhere narrower-feeling, and it is also what a 390px phone becomes when somebody zooms to 200% — which WCAG requires you to support.

What emulation does not tell you

This is the important half of the lesson. Device mode changes the viewport and the user agent string. It does not change the browser engine, the hardware, or the network.

It is still your desktop browser. On a Mac, device mode "iPhone" is Chrome's Blink engine pretending. A real iPhone runs WebKit, and every browser on iOS runs WebKit — Chrome on iOS is WebKit with a Chrome interface. So iOS-specific rendering bugs are invisible in device mode, by construction. This is the single biggest gap.

Touch is not a mouse. Emulated touch does not reproduce a fingertip's size, the lack of hover, the 300ms tap delay on old configurations, or scroll momentum.

Your laptop is fast. A mid-range Android has a slower CPU, less memory and a weaker GPU. A page that scrolls smoothly for you can stutter badly there.

Your wifi is not mobile data. Latency, not just bandwidth, is what makes a page feel slow, and each extra request pays it again.

Fonts differ. system-ui is a different typeface on each platform with different metrics, so a heading that fits on two lines for you may take three.

So: emulate to find layout bugs, and do not conclude the page is fine.

Throttling, which you should always do

In the Network tab, set Slow 4G. In the Performance panel's settings, set a 4× CPU slowdown. Then reload.

This is the closest thing to honest testing you can do on a laptop, and it changes what you build. A hero image you had not thought about becomes a three-second wait. A font without font-display: swap becomes a second of invisible text.

Do it once per project at minimum. The course's stated audience is somebody on a mid-range Android on mobile data in Pune, and on office wifi you cannot see what they see.

Test on your own phone, properly

The highest-value thing in this lesson, and it takes two minutes.

Your dev server is on localhost, which your phone cannot reach. Bind it to your network instead:

python3 -m http.server 5500 --bind 0.0.0.0

Find your machine's address on the network:

ipconfig getifaddr en0

That prints something like 192.168.1.7. On your phone, on the same wifi, open http://192.168.1.7:5500. You are now looking at your real page on a real device.

If you are using VS Code's Live Server, its settings have a useLocalIp option that does the same.

Then actually use it. Tap the buttons with your thumb rather than a fingernail. Fill the form. Scroll fast. Rotate it. You will find things no emulator shows you: targets too small, a sticky header eating a third of the screen, a form field that zooms the page when focused because its font size is under 16px.

Testing what you do not own

BrowserStack and LambdaTest give you real devices in a data centre, including iPhones. Both have free tiers that are enough for occasional checks, and this is the only realistic way to test iOS WebKit from a Windows or Linux machine.

Safari Technology Preview on a Mac, plus Safari's Responsive Design Mode, gets you much closer to iOS than Chrome's emulation does, because it is at least the right engine.

Ask somebody. For an internship project, sending the link to five friends with different phones is free, fast, and finds real problems. "Does anything look wrong?" gets you further than any emulator.

A checklist worth running

Before calling a page done:

Layout

320px with no horizontal scrollbar. Run the console snippet from the box-model lesson.
360px, 768px and 1440px.
Dragged slowly across the whole range, watching for breaks between breakpoints.
Zoomed to 200% in the browser, and to 400% if you can.
Long content: a four-word business name in the header, a 200-character product title, an empty state.

Keyboard and focus 6. Tab through everything. Every interactive element reachable, in a sensible order. 7. A visible focus ring on each, and nothing hidden behind a sticky header when focused.

Preferences 8. Dark mode, in the Rendering panel and once against your real OS setting. 9. Reduced motion. 10. Forced colours.

Performance 11. Slow 4G plus 4× CPU throttling. 12. Lighthouse, reading the accessibility section in particular. 13. Network tab sorted by size — is the biggest file justified?

Content 14. Stylesheet switched off: does it still read as a document? 15. Images switched off: does alt text carry the meaning?

A real device 16. Your own phone, over the network, actually used.

Two things that only show up on hardware

Worth naming because they are common and specific.

iOS zooms the page when a form field with text under 16px is focused. The layout jumps, the visitor is confused, and it looks like a bug. font-size: 16px minimum on inputs, as the typography lesson said.

100vh on a phone historically excluded the browser's address bar, so a 100vh section was taller than the visible area and its bottom was cut off — and it changed size as the bar hid on scroll. 100dvh accounts for it. You cannot see this in device mode at all, because there is no address bar to hide.

Check your work

The first pass. Device mode, dragging the width rather than using presets.

Why reload after switching. Load-time behaviour like srcset does not re-evaluate.

Why 320px. The narrowest to support, and what a 390px phone becomes at 200% zoom.

The biggest gap in emulation. It is still your engine — and every browser on iOS is WebKit, so iOS bugs are invisible by construction.

Four other things emulation misses. Real touch, CPU speed, network latency, and platform fonts.

What to throttle. Network to Slow 4G and CPU to 4×.

How to reach your dev server from your phone. Bind to 0.0.0.0 and use your machine's LAN address.

Why use the phone rather than look at it. Thumb-sized targets, form zoom and sticky-header space only show up in use.

How to test iOS from Windows. A real-device service like BrowserStack; there is no local substitute.

Two hardware-only bugs. iOS zooming on a sub-16px input, and 100vh versus the address bar.

Practice

Open your page in device mode and drag from 320px to 1440px. Note every width where something breaks.
Compare that list with the preset devices. How many breaks were between presets?
Run the horizontal-scrollbar console snippet at 320px.
Zoom to 200% and then 400%. Note what becomes unusable.
Put a four-word business name in your header and a 200-character product title in a card.
Throttle to Slow 4G with 4× CPU and reload. Time it, and note the slowest file.
Bind a server to 0.0.0.0, find your LAN address, and open the page on your phone.
On the phone: tap every button with your thumb, fill the form, scroll fast, rotate. Write down three things you would not have found otherwise.
Put a font-size: 14px input on the page and focus it on a real iPhone.
Build a 100vh section and scroll it on a real phone. Then 100dvh.
Emulate dark mode, reduced motion and forced colours in the Rendering panel.
Tab through the whole page with no mouse.
Switch off the stylesheet, then images, and read the page both ways.
Run Lighthouse and fix the top three accessibility findings.
Send the link to three people with different phones and ask what looks wrong.

Official documentation

Chrome DevTools — Simulate mobile devices with device mode — Including an explicit list of what device mode does and does not simulate.
Chrome DevTools — Network throttling — Setting up and customising throttling profiles.
WebKit — Safari Web Inspector — The right tool for anything iOS, since every iOS browser is WebKit.
W3C — Understanding WCAG 1.4.10 Reflow — The requirement behind testing at 320px and at 400% zoom.
web.dev — Lighthouse — What each audit measures and how to act on it.

You can now build a page that works at any width, on any device, honouring what the visitor has already asked for — and you know which of your checks are honest and which are only reassuring.

Next module: accessibility, which several of these lessons have been quietly building towards.