Jonathan Tweed

tricks for mobile performance

One of the things we’ve spent a lot of time on recently is optimising the performance of our listings widgets on mobile devices. I thought it might be useful to share some of things we’ve done during that process. And by the way, the widgets *rock* on mobile now. Our Luke is a hero.

reduce http requests

I almost didn’t put this one in, but it always bears repeating. The single most important thing you can do to improve performance is to reduce the number of HTTP requests. This is even more important on mobile than it is on desktop.

For the widgets, the main thing that was causing a large number of requests was loading the channel logos. In the case of a platform like Sky, there are hundreds of channels. Each was causing a separate request to load its logo. We can’t easily make a sprite for these images as they change and the set for each TV platform and region is different. Even given this, most users will not scroll down and look at all channels so it may still be a waste on a 3G connection to load all logos.

Our solution was to load channel logos progressively, as the user scrolls down and looks at a new block of channels. If the user doesn’t scroll down, the logos they don’t see are never even loaded.

use native scrolling

This one had an incredible impact. Without it, scrolling the grid was a frustrating experience that took a lot of finger movements and a long time. By setting -webkit-overflow-scrolling: touch in the right place, we got buttery smooth scrolling on the grid and featured content carousel.

perception beats reality

This one can be a little counter intuitive, but boils down to this:

sometimes the thing that takes longer, feels faster

It is incredibly important to profile and optimise things, but don’t let that lead you down a rabbit warren. Often there is something simpler that can be done that provides feedback to the user more quickly and creates the perception of a faster, more fluid experience.

This might even be something that causes things to take longer overall. That’s ok. It’s more important that things are broken down such that each piece happens quickly, ensuring things stay responsive for the user.

build for device capabilities

pull to scroll

With today’s modern machines and fast browsers, pretty much anything reasonably sensible will work on desktop. The same is not true on mobile. The devices are slower, which means the overhead of requests and subsequent processing is greater, and they also have less memory.

We wanted to have the same experience on mobile: a continuously scrolling 15 day grid, that supported hundreds of channels. This turned out to be too much for a phone to deal with, even though we were progressively loading data in six hour chunks and reusing parts of the DOM (minimising the number of DOM elements is critical to maintaining performance).

Ultimately device constraints won out. We still have continuous scrolling on desktop, but on mobile we now only show a maximum of a day and the user has to pull to scroll between days. One day, we’ll be able to have the same functionality on all platforms, but for today we’ll go as far as we can.

what of the widgets?

Stay tuned. The first users are now in beta, so we should able to share details of some shiny client integrations soon. If you’d like to know more, maybe even use the widgets on your own site, please do get in touch.

blog comments powered by Disqus