Testing a mobile website from a desktop browser is useful, but it does not tell the whole story.
A page can look responsive in DevTools and still feel slow, cramped, or difficult to use on a real phone.
For our mobile testing workflow, we treat Android, iPhone Safari, network conditions, and small-screen interaction as separate parts of the test.
The goal is not simply to ask:
“Does the page load?”
The more useful question is:
“Can a real user actually use it comfortably on a phone?”
Start with real devices
Desktop emulation is convenient during development, but real phones expose problems that are easy to miss.
A real device gives us a better view of things such as:
- actual viewport behaviour
- browser UI taking up screen space
- touch target size
- keyboard behaviour
- scrolling
- fixed headers and bottom bars
- image loading
- browser-specific rendering
- transitions between pages
- installation or download flows
For Android testing, Chrome is usually one of the first browsers we check.
For iPhone testing, Safari deserves its own test rather than being treated as “the same thing, but on iOS.”
The two environments can behave differently even when they open the same URL.
Loading time is more than first paint
One mistake in mobile testing is measuring only when something first appears on screen.
That number can be useful, but it does not always represent when the page is actually usable.
For example, a page may display the logo and background quickly while:
- navigation is still loading
- buttons are not yet responsive
- images are still blank
- a content list is incomplete
- JavaScript is still initializing
- the next page cannot yet be opened
So we separate “something appeared” from “the user can start using the page.”
When testing manually, we usually pay attention to three moments:
- When the page first becomes visually recognizable
- When the main controls become usable
- When the important content has finished loading
These three moments can feel very different on a mobile connection.
Test on normal 4G, not only fast Wi-Fi
A mobile experience should not be judged only from a stable office connection.
Users may open a site:
- outdoors
- while travelling
- between areas of different coverage
- on congested mobile networks
- with fluctuating signal quality
A page that feels instant on Wi-Fi can feel very different when the connection becomes slower.
When testing on 4G, we look at more than the total loading time.
We also watch for:
- images appearing late
- layout shifting while assets load
- blank spaces
- delayed menu response
- buttons that appear active but do nothing
- repeated taps caused by slow feedback
- pages loading twice after impatient tapping
This last point is surprisingly important.
When a button takes too long to respond, users often tap it again because they are not sure whether the first tap was registered.
That can create duplicate navigation or unexpected behaviour.
Small screens reveal navigation problems quickly
A desktop navigation bar has space.
A phone does not.
On a small screen, every extra step becomes more noticeable.
We check:
- whether the main menu is easy to find
- whether important buttons are large enough
- whether text remains readable
- whether content feels overcrowded
- whether search is easy to access
- whether the user has to scroll too much before reaching important sections
- whether fixed UI elements cover content
A responsive layout is not automatically a good mobile layout.
It is possible for every element to fit inside the viewport and still create a frustrating experience.
Mobile usability depends on how quickly a user can understand what to do next.
Android app and mobile browser should be tested separately
Some services provide an Android app or APK in addition to a mobile website.
We do not treat the existence of an app as proof that the mobile experience is better.
If an APK is available, useful things to record include:
- file size
- download source
- installation steps
- whether unusual permissions are requested
- whether installation completes normally
- whether the app opens correctly after installation
Then we compare that experience with simply opening the same service in Chrome.
Sometimes the browser version is more practical because there is nothing to install.
In other cases, the installed app may provide a more consistent experience.
The important part is to test both rather than assuming one is better.
Safari needs its own workflow
iPhone users often access mobile services through Safari.
So we check Safari separately.
Typical things we look at include:
- registration forms
- login fields
- navigation
- touch behaviour
- page transitions
- browser keyboard behaviour
- fixed headers
- buttons near the bottom of the screen
- Home Screen support where available
We also avoid assuming that something tested on Android works identically on iPhone.
If a function was only tested on Android, we record it as an Android result.
If the iPhone flow could not be completed, it should not be presented as though it was verified.
Do not guess what happens after login
Another useful rule is simple:
If we did not test it, we do not treat it as a test result.
Some areas of a mobile service may only become available after:
- creating an account
- verifying a phone number
- logging in
- meeting another access requirement
In that situation, testing only the public homepage is not enough to make conclusions about the logged-in interface.
We separate:
- tested
- partially tested
- not tested
This makes comparisons more useful later.
Record the environment
A performance number without context is not very helpful.
When documenting a mobile test, we try to keep basic environment information together with the result.
For example:
text
Device: Android phone
Browser: Chrome
Network: 4G
Test type: mobile web
Area checked: homepage, navigation, search
Top comments (0)