Field Notes · Testing

It looks perfect in Framer. Then someone opens it on a real phone.

Modern builders make responsive design fast — but a beautiful preview is not the same as a tested experience. Here’s why real devices still decide whether your site actually works.

Topic

QA & Performance

Read Time

8 min

Level

All builders

Updated

Jul 2026

01 / The Premise

The editor isn’t the real world

You publish. It looks beautiful in preview, every breakpoint seems right, animations are smooth, and Lighthouse gives you a respectable score. Then a customer opens it on a three-year-old Android phone — the page stutters, the menu is hard to tap, images shift, and a video starts downloading before it’s even visible. This happens more often than most people realize.

Previews run on your computer, your browser, your CPU and GPU, your network, your memory. Your visitors have none of that. The same site behaves differently on an older iPhone, a budget Android, a throttled connection, Low Power Mode, or with accessibility settings enabled.

What your machine has

  • A fast, modern CPU and GPU

  • Plenty of memory

  • A stable, high-speed network

  • A large desktop display

What visitors might have

  • An older iPhone or budget Android

  • A slow CPU and limited memory

  • Low Power Mode or battery saver

  • A poor cellular connection

  • Accessibility settings enabled

02 / Blind Spots

Why desktop testing can mislead

Modern laptops are powerful enough to hide problems that appear instantly on real phones. Your machine barely notices these — a four-year-old mobile device certainly does:

  • Heavy blur and backdrop effects

  • Multiple autoplaying videos

  • Oversized, unoptimized images

  • Complex scroll-linked animations

  • Dozens of intersection observers

  • Expensive JavaScript on every scroll

The result is a site that feels fast during development but frustrating for the people it’s built for.

03 / Beyond Breakpoints

Responsive doesn’t mean tested

Many designers stop after checking breakpoints — desktop, tablet, mobile, done. But responsive layout is only one piece. Everything should behave naturally, not just look correct. It’s worth verifying:

  • Touch interactions and tap targets

  • Scrolling performance and sticky elements

  • Keyboard behavior and orientation changes

  • Image and video loading

  • Navigation, forms, and CMS content

  • Dynamic sizing and browser compatibility

The reality

A website isn’t finished until it has been tested on actual devices.

Your editor shows what the design should look like. A real device shows what your visitors actually experience — and the gap between the two is where the most important bugs live.

04 / Coverage

Test across screen sizes

Don’t limit yourself to a single iPhone. Visitors use hundreds of screen sizes, and each category tends to expose a different class of problem.

Small phones

Expose cramped layouts, oversized type, and buttons that are hard to tap. Try an iPhone SE or an older Android.

Standard phones

Where most visitors live. iPhone 15/16, recent Pixels, and the Samsung Galaxy S series.

Large phones

Big displays often reveal spacing issues that appear nowhere else. Think iPhone Pro Max and Galaxy Ultra.

Tablets

Many sites look like stretched mobile versions here. Test both portrait and landscape.

Desktop

Don’t only test your own monitor. Compare 13”, 15”, 27”, and ultrawide — large screens reveal over-wide text and loose spacing.

05 / Feel

Performance matters more than appearance

A page can look identical while performing very differently. The chart below is illustrative — but it captures a pattern you’ll see again and again: interactions that feel instant on a laptop become sluggish on a mid-tier phone.

Perceived smoothness — high-end laptop vs mid-tier phone

Tap responsiveness

Laptop

Phone

Scroll smoothness

Laptop

Phone

Menu opening speed

Laptop

Phone

High-end laptop

Mid-tier phone

06 / Limits

Simulators help — but they’re still simulations

Chrome DevTools, Safari Responsive Design Mode, and Framer Preview are all excellent — use them freely. But remember they can’t perfectly reproduce:

  • Slower CPUs and thermal throttling

  • Battery saver and memory pressure

  • Real GPU limitations

  • Real touch hardware and gestures

  • Mobile Safari quirks and browser bugs

07 / Debugging

How to identify device-specific issues

Sometimes a bug only appears on one device. The first step is pinning down exactly where it happens — the more detail you capture, the faster the fix:

  • Device model and operating system

  • Browser and version

  • Screen size and orientation

  • Network speed and conditions

  • Page URL and reproduction steps

08 / Conditions

Test under realistic conditions

Most developers work on fast Wi-Fi. Many visitors don’t. If your site still feels smooth under these conditions, you’re in great shape:

  • Slow 4G and Fast 3G throttling

  • High network latency

  • 4–6× CPU throttling

  • Battery saver enabled

  • Multiple browser tabs open

09 / Toolkit

Tools worth using

No single tool catches everything. A healthy workflow combines a few — lab tests for diagnosis, and real-user data for what visitors actually feel.

Browser DevTools

Inspect console errors, network requests, layout shifts, repaints, and JavaScript execution. They explain why something happens.

Lighthouse

Audits performance, accessibility, SEO, and best practices. Remember it’s a lab test — not real-user data.

PageSpeed Insights

Pairs a Lighthouse lab run with real-world CrUX field data when available, so you can compare the two.

WebPageTest

Test from different locations, devices, and network conditions with detailed loading waterfalls and visual timelines.

Chrome UX Report

Reflects how real visitors experience your site over time — one of the best signals you can watch.

Microsoft Clarity

Watch real sessions for rage clicks, dead clicks, excessive scrolling, and abandoned forms that synthetic tools miss.

Device clouds

Platforms like BrowserStack let you interact with real phones and tablets remotely — great for browser-specific issues.

10 / Setup

Build a small device lab

You don’t need fifty phones. A surprisingly effective kit catches the overwhelming majority of real-world issues:

One recent iPhone

One older iPhone

One Android device

One tablet

One laptop

One desktop browser

11 / Pre-Launch

A simple checklist before publishing

Every page loads correctly

Navigation works on touch devices

Forms can be completed and submitted

Videos don’t download unnecessarily

Images load at appropriate sizes

Animations stay smooth

Sticky elements behave correctly

Text stays readable across devices

Buttons are easy to tap

No console errors appear

Performance holds up on slower devices

Core Web Vitals are healthy

12 / Takeaway

The best websites aren’t simply responsive

Modern builders like Framer have dramatically reduced the time it takes to ship beautiful, responsive sites — but they haven’t removed the need for real-world testing.

Your editor shows what the design should look like. A real device shows what your visitors experience. The best sites are tested, measured, and refined on the devices people actually use.

06 / Availability — 07 / Contact

Open Channel

One founder, fully embedded. I take on a small number of partners each quarter, so every system gets the attention it deserves.

Let’s build your system.

Let’s build your system.

© 2026 The Good People Studio LLC · Wyoming, USA · Worldwide