Customers often ask us about best practices for performance and especially for mobile performance. We maintain an
OSS note where we collect extensive documentation on performance and there is a high level
performance blog post. In this blog post, we’ll discuss the performance best practices for mobile.
When tuning performance on mobile, you need to keep a few things in mind:
- Connection bandwidth can be limited. When the GPRS icon is showing, the connection speed is less than that of a dialup modem. E is comparable with a 90’s era dialup modem, or slightly faster. 3G is supposed to be able to achieve 2 megabits per second. LTE is fast, with speeds comparable to older Wifi connections.
- Network latency is ALWAYS an issue. If the user is on the same local area network as the BIP server and everything is functioning correctly, they should expect about 500ms of latency per interaction. Even if the user is on LTE, there is an additional network latency of at least 100ms, while 3G adds another 500ms.
- Design Studio applications are Javascript+HTML and specifically use UI5. This has a wonderful advantage, allowing apps to be run in any browser. Javascript can be a CPU intensive beast however. It is a duck typed, interpreted language and incurs vastly more overhead than a native application would.
- CPU performance is very weak on mobile devices. You can expect a laptop or desktop to have an order of magnitude more processing horsepower available than a phone or tablet. Again, this becomes relevant when executing complex Javascript.
- Mobile browser cache sizes are considerable smaller. Having everything in the cache presents a significant performance increase and mobile browsers simply can't cache like laptops and desktops can.
Best Practices
So how does this all translate into performance tips? Follow the KISS Principle!
- Keep scripting to a minimum!
- This means as few scripted events as possible. Remember that every time a script is being executed, you are looking at a second’s worth of latency, at a minimum and network latency is per script. Latency that is not noticeable on a laptop back at the office may become a showstopper on a tablet on a mobile data connection. Good design is usually simple design, especially on mobile.
- Don’t try a “one app to rule them all” approach.
- Responsive Design is great! It also imposes a cost in terms of development resources and runtime performance. If you expect an app to be used on the desktop and on a mobile device, build two versions.
- Keep in mind that when you encounter professional grade desktop+mobile responsive design on websites, they have a great deal of logic for shifting elements around or showing/hiding them on demand, based on the rendering device; based on CSS media queries, but also liberal use of Javascript. You’d have to implement a rats’ nest of scripting to do this and this imposes a performance cost.
- You can build a more performant app in less time by making your mobile app mobile specific.
- Minimize the number of data sources! (you are already doing this on your desktop apps, right?)
- Tables and Crosstabs
- Consider very carefully when and how you want to display data in tabular format. Start with chart overviews and only switch to tables when the user wants a deeper look at the underlying data. Think twice about even using tables! The W3C best practices page says this about tables, "Where possible, use an alternative to tabular presentation".
- If you must use tables, keep the number of columns to the bare minimum and answer the specific question. Mobile means on-the-go and large, expansive crosstabs with lots of dynamically places dimensions and measures is a desktop use case.
- Use Pixel Based Scrolling with a max cell count (that is Row limit x Cell Limit) of no larger than 500 cells. That's 100 rows if your table has five columns. If you feel like this is a constraint, then you probably need to think about whether or not you are following mobile design best practices.
Hopefully these tips will help you build responsive mobile apps.
