How to test your sites on multiple devices

BrowserSync helps you test your sites easily and effectively on multiple devices and browsers.

There's no denying that, for a growing percentage of users, the primary means of internet access is some form of mobile device – be it a smartphone, tablet, notebook or anything in-between.

As designers and developers, you'll already be aware that these devices may or may not be touch enabled, have varying screen sizes and pixel densities, offer an unknown (at least until page load) set of supported features and may be connected to any type of network ranging from an extremely slow EDGE connection to a super-fast Wi-Fi connection.

You should also be well aware that testing your website on as many of these actual devices as possible is the only way to ensure your designs and code work smoothly and correctly for as many people as possible.

BrowserSync is a free, open source project, which runs on Windows, Linux and Mac OSX. It was designed from the ground up with exactly this type of multi-browser, multi-device testing workflow in mind. As such, it makes the whole process a breeze.

BrowserSync has many amazing features, but there are three fundamental ones that directly address the most common pain-points for testing:

  1. Accessing a localhost website on all of your test devices whilst in development
  2. Auto-reloading all devices when you change files
  3. Synchronising interactions across all devices

Let's take a look at each of these key features...

Setting up

First up, install BrowserSync as per the guidelines on browsersync.io. You'll also need to set up a new folder, create an 'index.html' file and a CSS folder containing the file 'style.css'. The contents of 'index.html' would look something like this:

<!doctype html>
<html lang="en-US">
<head>
    <meta charset="UTF-8">
    <title>BrowserSync example</title>
    <link rel="stylesheet" href="css/style.css"/>
</head>
<body>
    <h1>BrowserSync example</h1>
</body>
</html>

Accessing a localhost website

BrowserSync has the ability to create a mini server from any folder on your computer and expose that server over your Wi-Fi network. On the command line, navigate into the folder that contains the 'index.html' file and run the following:

$ browser-sync start --server

You'll be presented with two URLs: a 'localhost' address and an IP-based address. The localhost address is the one you typically use on the same machine that you develop from, while the IP-based address is for any device that's connected on the same Wi-Fi network.

Using these two addresses, you now have access to your website on any phones or tablets you can get your hands on (as well as your main development machine). This means you can spot and fix issues with your layout, CSS and JavaScript as early as possible in the development process.

If you're in a situation where you already have a server setup (such as WordPress running on MAMP/WAMP, for example), then you would replace the --server option for --proxy and provide your existing URL:

$ browser-sync start --proxy http://local.wordpress.com

Auto-reloading devices

Now you can easily access your work-in-progress website on any device connected to the same Wi-Fi network. However, you'll quickly realise that this type of workflow actually introduces a new issue: viewing the latest version each time you change a file requires you to reload all browsers on all devices manually. This is where BrowserSync's built-in File Watcher comes in handy. Not only does it reload all browsers automatically when it notices a file change, but it can actually inject CSS changes directly, without even reloading the page.

Building upon the previous server example, you can provide a --files flag with glob patterns that match your project files. By doing this, you are instructing BrowserSync to watch a subset of files for changes and, when it sees a change occur, either perform a hard reload or inject changes into all connected browsers automatically.

$ browser-sync start --server --files="*.html, css/*.css"

With the above command, any changes to 'index.html' will cause every browser to perform a hard reload, whereas changes to 'css/style.css' will be injected into the page without reloading it. Now you can go ahead and start coding your latest creation – each time you hit Save, you'll be able to instantly see the changes on each and every device simultaneously.

Once you've experienced the level of efficiency this workflow affords – with its instant feedback and shorter iteration times – you'll find it almost impossible to believe you ever managed to work without it!

Synchronising interactions

The final piece of the awesome-workflow puzzle is the synchronisation of actions across all connected devices. We realised early in the development of BrowserSync that being able to scroll inside one browser and see that action mirrored in all others is not simply a cool party trick, but actually an essential counterpart to the auto-reloading feature. The Action Sync feature (enabled by default) will copy scroll position, clicks and form inputs from one browser to all of the others that are connected.

A perfect example of why this is useful would be a mobile slide-out navigation. You could have your site open on a multitude of devices that all fall below a breakpoint that causes the navigation to be hidden. Now, when you tap or click the 'menu reveal' button on any of the devices, that same click will be replayed across them all – thus revealing your navigation and highlighting any layout or CSS bugs that may be different across platforms.

Other helpful features

The three features we've just looked at form the basis of BrowserSync, but that's just the beginning. By accessing the browser-based UI that comes bundled with BrowserSync, you'll find a range of additional features.

These include 'remote debugging' (like Chrome's 'inspect element', but for all browsers), 'URL history' (records your test URLs so you can push them back out to all devices with a single click), 'sync customisation' (toggle individual sync settings to create your preferred test environment) and 'URL tunnelling' (create a secure public URL to share your local sites with any internet-connected device). So get stuck in!

This article first appeared in issue 269 of net magazine.

Words: Shane Osbourne

Liked this? Read these?