Posted by: James Denman
mobile performance, web development, website performance
Last week the Boston Web Performance Meetup Group joined forces with Boston’s Mobile Experience Optimization Group to discuss issues around Web-based mobile app performance. The discussion was led by Ariel Weil, a representative from Yottaa’s adaptive Web performance team, and Ilya Grigorik just happened to be a part of the audience. The discussion centered more around user experience than I expected, but they definitely raised some good points.
Of course it’s important to remember that mobile apps run on mobile devices and mobile devices go pretty much everywhere. The mobile apps we develop aren’t just going to run in the office with a fast and stable WiFi connection so we can’t just test them that way. We need to at least attempt to test them under the conditions we expect them to run. We also want to optimize our applications for those same conditions.
Weil explained what demographics Yottaa sees as being the most important. The questions seem pretty familiar to me, as a journalist. Who, what, where, when, why? That’s what mobile app developers want to know.
Who are your users and how familiar are they with mobile apps? This is a little bit ageist, but younger folks are likely to be more tech savvy than older folks. That affects how you present your content and how much explanation goes along with it.
What devices do your users have? Each manufacturer and type of device has its own advantages and constraints. If you know what devices they do and don’t use, you can focus more on the devices that matter.
What wireless carriers are they using? Different carriers have different levels of service in different areas. Verizon customers in City One might get great service while Sprint customers suffer. Meanwhile, in City Two it’s exactly the opposite. Knowing what kind of connection to expect is important.
Really, I think you should just plan to have most mobile applications work even when the connection is really bad. Still, I can see the argument for not worrying too much about dropped packets if you know the connection will be spot-on all the time.
Where is your user base located? Are they in the US, Europe or Asia? While Asian mobile networks are lightning fast, mobile devices tend to lag in the US. It also matters if they’re in a densely populated city or way out in rural America. Users in Times Square will have a very different network experience than those in the hills of Maine.
When are your users accessing the app? Is it a constant stream of use or are there big spikes and long lulls? Handling major spikes might prompt a mobile application team to pay more attention to the app’s bandwidth than if the app tends to have a steady stream of use.
You also want to know why users are accessing your application. Mobile apps tend to be more successful when they do one thing very well than when they add on extra bells and whistles. Paring down function can improve performance. However, taking away the features that users want and need is a sure way to disaster, so you don’t want to go overboard there.
It might be obvious that an app that will only be run on company owned iPads doesn’t need a streamlined Android interface, but less obvious situations may arise where the vast majority of users tend to use the same type of device. You can apply the 80/20 rule here to focus your efforts and reduce wasted efforts.
Gathering this information might not be as hard as you think. One of the most prominent Web analyzers is Google, but they have plenty of competitors. A good Web traffic analysis tool will tell you the who, what, where, and when of the actual use your website is getting. The why takes a little more creative researching, but it can and certainly should be done.
The discussion after the main presentation was arguably even better than the tips Weil brought up. I hope to post the advice from that bit later this week. I just don’t have the time or space to cram them in here. So until next time, remember that done is better than perfect and it’s better late than never.