How to Evaluate the Performance of Responsive Websites

Posted: May 4, 2014 under Web Design, Web Performance

A lot of the time, when someone talks about making a website responsive, they mean that the layout will change depending on what device is being used to view the site. But there is more to responsive design than that. Perhaps an even more critical factor is the performance of the site, particularly on mobile.

At its heart, responsive design is about opitimizing the user experience across a wide range of devices. This can be a hard job, no doubt about it. But we've been making things harder than they need to be.

A major culprit has been the choices that are made with recent design trends - large images, lots of JavaScript libraries and even the continued use of carousels. This has led to swelling page sizes, with the current median page size of a top 500 website now coming in at over 1.5 MB - 33% larger than the year before!

What follows are some tips on evaluating responsive websites across different devices. We'll see how to use several tools and techniques - using a real website as an example - that can provide hard data on how your site is going to perform on mobile devices and help identify problem areas.

Dev Tools

The first tool to become familiar with is Chrome Dev Tools Mobile Emulation. The details of using that tool can be found via the provided link, but a quick point about mobile emulation is that it's much more than resizing the viewport. It sends user agent information (useful if the site targets specific devices) as well as simulating a touch device.

As useful as mobile emulation is, by itself it doesn't tell us much about the performance of the site. That's where the Network tab of Chrom Dev Tools comes in. You can get information about page load time as well as a detailed listing of the resources on the page and how long they took to load.

A Quick Example of Dev Tools in Action

Let's take a look at how these two work by trying them out in a quick example. I've chosen Stuff and Nonsense, the website of designer Andrew Clarke, for this example because I think his site is quite well done. It also illustrates several points I'd like make about responsive websites. In the screenshot below is an image of his site open in my Dev Tools with the Network tab displayed. You can click the image to view a larger version.

Stuff and Nonsense in Dev tools

Notice in the lower left of the image that we can see that there were 39 requests for a page size of 1.8 MB and that it downloaded in 2.7s. The speed isn't too bad considering the page size, which is larger than average. Now some might comment that Clarke should try to remove some of the images and other resources that are making the page size so large, but should he?

Performance in Context

Performance is very important, but there are always trade-offs. Andrew Clarke is a designer and I think it can be argued the images are important for expressing his brand - playful and humorous, while technically impressive. Would this message be the same without the imagery?

Generally speaking, on a desktop you'll want your page to load in under 3 seconds for a good user experience. Faster is better and can pay big dividends, but in practice you will often need to find the balance between speed and message and how your site compares to those it is directly competing with.

Now let's take a look at the site using mobile emulation. In the screenshot below you'll see that I'm calling the page as an iPhone 4.

Site in dev tools mobile emulation mode.

You'll also notice that there were only 30 requests for a download size of 1.1 MB that completed in 1.84 seconds. Clarke has reduced the number and size of the images being used on the page. This was done using media queries - providing different images, and fewer of them - when the site is viewed on a mobile.

Working with images can be challenging, but the technique demonstrated here is pretty straightforward and can be easily adopted, though it often is not. When using content management systems, you can also also add modules like Adaptive Image to your site that will reduce the size of images served to mobile users.

The point is that thinking about the resources on a given site - and how they might be reduced, particularly for mobile users - will pay big dividends when working with responsive websites. Start working with a few of the many free resources for optimizing performance to see where you might improve a site you're working on.

Emulating Mobile Networks on the Desktop

So far we've got some good information about our site, but we still don't have any data about how the site will perform on mobile out in the wild. This is where our next tool, Network Link Conditioner, comes in. It allows us to simulate the network conditions on mobile - a default 3G profile is provided, but you can create custom profiles as well.

Network Link Conditioner is only available for Mac, but there are others you might want to try out. The Android simulator also has network settings that do much the same thing. Let's take a look at our example site's performance on mobile.

Site in dev tool simulating 3G network speeds

Load time has gone up to 15.3 seconds - possibly a challenge for mobile users. I also tested the mobile load time of one of the blog posts and it came in at ~ 10 seconds. Is this too long for mobile users?

In these sorts of cases, taking a long look at your analytics is very helpful. What is your bounce rate and time on page for mobile vs. desktops users? These and other metrics can help you measure how the mobile experience you are providing is going over with users.

Measuring Specific Real World Conditions

So far we've looked at several tools we can use to evaluate the performance of responsive websites. Although they can provide us with some great data, we may want to set up something more specific, say emulate a 4G connection from a particular location in town. How might we do that?

A great app for testing this sort of thing comes from speedtest.net. All you have to do is install the app on the device you want to test and head to the location you'd like to collect data from. Run a few tests and use the data to create a profile on Network Link Connector - or other similar program - for testing back at the shop.

Imagine you are building a website for a special event where you expect a lot of site traffic from users at the event location - a music festival, for example. The data you collect in that sort of situation could be essential in making sure the site is even usable if the location has a poor signal.

Faster Is Better, Context Is Important

Hopefully the tools I've discussed will come in handy in your future projects. The data are clear, faster is better, but context is also important. A website for a photographer would undoubtedly be faster without images, but would it be better? Judgement and continuously looking for savings are the key things.

If you have any comments on this post, you may politely leave them below.

About the Author

John Hannah

I’m John Hannah, a front end developer at Lullabot . When I'm not building websites, I travel as much as possible and enjoy hanging out with my wonderful family. My favorite place to spend my coffee breaks is Twitter, so please feel free to connect with me there.