Mobile web debugging
This article is Ready to Use.
Debugging web applications on multiple platforms requires careful prioritisation, different from developing for desktop alone. This article explains techniques and tools available, with links to external resources.
Mobile web debugging
Debugging web applications on multiple platforms requires careful prioritisation. This article explains techniques and tools available, with links to external resources.
- Prioritise testing on a variety of real devices.
- Add simulators and emulators to your toolkit.
- Use remote debugging tools such as Chrome DevTools and Adobe Edge Inspect.
- Report bugs!
Debugging for mobile can be more complex and demanding than for desktop, simply because mobile devices often have a complex variety of functions and inputs:
- Proximity detector
- Ambient light sensor
- Multi-touch, gestures and keyboards
CPU, memory and storage are far more constrained and variable on mobile devices than for desktops and laptops, and debugging needs to be done with the whole mobile stack in mind:
- browser software
- app software
Two factors are characteristic of mobile web usage: variability and instability. Both can lead to a buggy user experience.
- Devices: screen size and resolution, touch screen type and quality, CPU, memory, storage – even for devices running the same OS
- Users: they're mobile – changing location, context and mood
- Latency: there is a massive range of potential delays at every 'hop'
- Bandwidth: far less predictable than desktop
- Location: position in a network cell, distance from wifi access points
- Time of day: mobile users are likely to access web apps at all times of day and night – bandwidth and latency vary considerably at different times
- Carrier: different carriers may provide different levels of bandwidth and latency
- Flakey cell connectivity
- On/off: train through a tunnel, moving between network cells or rooms
- Poor and shared wifi
- Cheap, low-spec devices: slower CPU, less memory, lower quality displays and less responsive touch screens
- More failed UI interactions than for desktop devices
When dealing with bugs, it's also important to consider user context: environment, mood, posture and time of day. Different contexts have different performance requirements: watching video while lying on a sofa compared to quickly checking a map while on a crowded bus, for example. The variety of usage contexts on mobile is likely to expose more bugs than for a traditional desktop setup in which a person sits at a table using a keyboard and mouse, with a large display and a computer 'plumbed in' for power and network connectivity.
To get a sense of what people are actually consuming on the mobile web, take a look at HTTP Archive Mobile. This provides analysis of browsing data for Alexa's top one million sites.
Facebook data show that over 7000 different devices access their site every day. Even if your site or app doesn't have this level of traffic, it's important to test web apps on multiple platforms, and to develop a strategy for prioritising which devices and browsers to test on.
If you don't have access to many devices, there may be an open device lab near you, where you can use or even borrow devices for free: www.opendevicelab.com.
More suggestions on how to set up a device lab:
Strategies for choosing devices:
Testing 'without breaking the bank':
Mobile simulation in the browser
Before testing on mobile devices, it's often best to do as much design and development as possible on a development computer. With that in mind, a number of tools have been built to mimic the mobile environment in the browser.
Chrome provides many features for mobile device simulation:
- touch simulation
- user agent overriding
- device metrics overriding (resolution and font scale factor)
Firefox provides Responsive Design View:
Other Firefox developer tools are listed here:
Debugging responsive design
Responsive Web Design (RWD for short) is an approach that emphasises design which works well across a variety of platforms, in particular by using media queries, fluid grids (layouts) and fluid images.
For responsive design to work well, it is especially important to test sites and applications at different viewport sizes. Remy Sharp's responsivepx makes it possible to adjust viewport width and height values, in order to find points at which responsive layouts 'break'. Developer Brad Frost recently produced the ish resizer, which emphasises that 'breakpoints' – size ranges for displaying particular layouts and content – should be based on content rather than fixed device dimensions.
For responsive typography, designers have found that body text should generally have between 45 and 75 characters per line, A very simple trick for testing layouts, suggested by Trent Walton, is to add an asterisk to _lorem_ text after 45 and 75 characters. If both asterisks appear on the same line at a particular viewport width, the font size needs to be changed.
A huge range of other tools is available for testing and debugging responsive design components including images, fonts and layouts.
Simulators and emulators
Simulators aim only to mimic the behaviour of a device. Emulators are designed to replicate the way a device actually works, in terms of hardware and software. For example, the Android emulator runs a full Android system stack down to the kernel level, whereas iOS provides a simulator. (There's a long discussion on Stack Overflow on the difference.)
Simulators and emulators are available for many platforms, and browsers can be installed on most of these: mobilexweb.com/emulators. (It's not included on this list, but a simulator is also available for the Kindle Fire.)
The Opera Mobile simulator can run multiple Opera Mobile instances, each with its own settings (such as resolution and pixel density) and can be used in collaboration with the Opera Dragonfly development tools.
Several paid-for online tools enable developers to test sites in a variety of real or virtual devices and browsers.
Appthwack gives screenshots from different browsers running on real devices, and provides load time estimates.
BrowserStack allows interaction with emulators or simulators running on virtual machines.
Saucelabs provides integration with Selenium RC and WebDriver.
Several tools enable developers to run a debugger user interface on one device in order to debug a web page running on another: for example, from your laptop debug a web page displayed on your phone.
Most tools for remote debugging require some setup; in particular, browser tools require port forwarding to be initiated from the command line.
The Chrome tools enable remote debugging via USB. The full set of developer tools is available, including:
- DOM access
- DOM debugger
- Network and resource tools
- Source information and editing
- Timeline data
For more information see developers.google.com/chrome-developer-tools/docs/remote-debugging.
WebKit remote debugging
More information about web app debugging on iOS is available from mobilexweb.com/blog/iphone-5-ios-6-html5-developers.
General information about using the iOS simulator is available from Apple's Xcode documentation.
Remote debugging tool. Reuses WebKit Web Inspector – and is used by Adobe Edge Inspect.
Useful for remote debugging with pre-Jelly Bean (4.1) Android devices, and iOS pre version 5:
Adobe Edge Inspect
Previously known as Adobe Shadow; uses weinre (see above) for remote inspection.
Edge Inspect enables wireless synchronised browsing on multiple devices, as well as remote inspection, screenshot tools and other features. A number of platforms are supported. Edge Inspect is available as part of Adobe's Creative Cloud for free and paid memberships.
Installation requires three steps:
1. Install Edge Inspect on the development computer.
2. Install Chrome and the Edge Inspect Chrome Extension on development computer.
3. Install the Edge Inspect application on iOS and/or Android devices.
Adobe has also published a beginner's guide to the Edge tools.
Firefox remote debugging
Firefox has tools for remote debugging, though these are currently more limited than the Chrome tools:
- remote debugging only for scripts, i.e. not HTML or CSS or anything else
- after opening the remote debugging window, incoming requests must be accepted on the secondary device
- breakpoints can be set, and there is a scope panel, but no console, so you can't get variable values (or information about an object by hovering over it, as with the Chrome tools)
The Firefox tools can be used via wifi. Note, however, that debugging via wifi affects the remote device's connectivity environment, unlike connecting via USB.
Instructions from the Mozilla blog:
Information about the Mozilla remote debugging protocol:
There is a bookmarklet that allows Firebug to run on iOS:
This tool, built by Maximiliano Firtman, can be useful for debugging apps running on Safari for iOS pre version 6.0 – can also be used with PhoneGap apps: iwebinspector.com.
Debugging performance issues
Performance bugs are a significant barrier to producing a successful site or web app.
For more information about improving mobile web performance, see Google's mobile web best practice documentation.
When considering performance problems, bear in mind that some bugs go unnoticed on desktop computers but become problematic on devices with more constrained memory and caching. Remember that users – even on mobile – are leaving web apps open for longer than they used to. In particular, beware of memory leaks when using event listeners or creating DOM elements.
The Chrome DevTools have several features for analysing memory usage. These tools also provide a timeline and Frame Mode for understanding the time taken to display each 'frame' in the browser – loading, scripting, rendering and painting – and how to maintain an acceptable 'frame rate'.
The Navigation Timing API is a great 'tool' for debugging performance problems:
The API provides timing data for page load and navigation events, including DNS resolution and redirects. Data from the web.performance can be accessed via Google Analytics.
In order to avoid performance bugs, it is crucial to incorporate performance checking in your workflow.
There are several tools for this.
Google tool to 'help developers optimize their web pages by applying web performance best practices'. A similar tool is available from the Audit panel in the Chrome DevTools.
Akamai service for 'front end optimisation'.
W3C also offers a tool to check web pages for 'mobile friendliness': validator.w3.org/mobile.
Browser and device capability
Mobile and desktop browser capabilities, with links to documentation
Capability information for mobile browsers.
Feature detection library supported by most web platforms.
Test for CSS3 feature support.
Fing is a native app for checking the network environment – you can even run ping and traceroute.
Reporting browser bugs
It's extremely important for the developer community that you report browser bugs as soon as you encounter them, however frustrating or trivial they may seem.
For more information about how to report bugs – and why you should do that – see coding.smashingmagazine.com/2011/09/07/help-the-community-report-browser-bugs.
Simple bug reporting tool for Chrome for Android: new.mcrbug.com
Internet Explorer: connect.microsoft.com
Whatever you build, try to test it on a variety of mobile devices in a variety of contexts.
You don't need a complex test suite and usability lab for that: just get friends and colleagues to try out what you've built. Discount usability is a lot better than none at all!
The mobile web is changing fast, unpredictably – what matters now may not matter in six months – so make sure to incorporate testing early in your workflow.
Brad Frost's guide to testing and tools:
Smashing Magazine articles about mobile web app design:
Optimising mobile web app performance:
Ilya Grigorik on performance:
Brian Leroux on debugging mobile web apps:
Resources for finding information about web development, and how to help others: