Phone Frustration and Performance
by Jon Bosanac (LinkedIn)
The graphic above was from a New York Times piece about how our phone can be this interesting source of anger and frustration. This anger and frustration can be inspired via content or the lack of content speediness. When I was at Radware Kent Alstad and the team at WebPerformanceToday.com had commissioned a few studies and one of them was the perception of performance an the outcomes of people who experience it. I don’t think that the findings were landmark, but Radware did create a way to more effectively study this relationship in a way that would have allowed the industry to have a keen thought leader. Not surprisingly, damaged brand, lower carts, lower total spend over a life time, and well yes, throwing phones were all outcomes of slow applications and slow webpages. If I may confess, I have tossed a phone or 3, screamed at my phone, and I have vowed in the past to completely avoid some companies all together as a result of slow or terrible performance. Mobile applications are a completely different beast when compared to the mobile browsing experience at which the study was targeted. Products like FastView, Strangeloop, and FEO are completely ineffective in their ability to address this market as are standard CDNs, because mobile applications are far removed from the Web Apps that spawned them. I’ll tackle how mobile apps are different in a moment, but the biggest issue has been how do you truly measure a user experience inside of a mobile app and the affect of your changes? Mobile apps are generally put together with a lot of JSON calls, API connections, and SDKs from all over. These 3 different items then pull content and information from the internet and your phone then assembles the pieces together, hopefully in a way that is pleasing to you, though often times, the different SDKs have varying levels of performance and can also offer blocking to other elements of the app intentionally and intentionally. Mobile application developers in some cases have accounted for this and essentially packaged most of the content into the download of the app. This works really well if the app is say a game or something light weight and simple where there aren’t many updates or constantly changing content. If your app does have a high amount of change, then developers need to have a process to refresh the content in the app. The refresh process will often times occur when either an action is taken by a user, i.e. a user touched this or that or when the application is turned on. In either case, without performance users will become frustrated and either leave your application, including deletion, or will see your brand tarnished resulting in potentially lower revenue over time. With the information being so fragmented, how can you maintain an app that is light weight and is super responsive to downloading content quickly over high latency mobile connections? The answer is ironical, with another SDK. One of the determining factors to fast downloads to a mobile connection is bandwidth or connection fragmentation. The more connections you have to your phone, the more power, memory, and so forth an application requires of the phone, but if you simplify the connection pool to a single edge node, you can then improve all of the connections for a given application. Using current protocols like QUIC or HTTP2 are great steps towards pipelining requests, but if all of the content is coming from multiple domains, then the efficiencies promised in these protocols quickly diminish. So if you pool all of the connections to the edge, you can build a pipeline for all of the content to a given mobile app with a single session, taking potentially dozens of round-trips off of all of the content and connection requests inside of an application. This new connection pooling will benefit many of the current technologies used most often in a mobile app, like ad companies. Ad companies are losing 10’s of billions of dollars in impressions because the ad simply doesn’t render. This is the easiest problem to solve through caching and infrastructure diversity. One of the unique features that this type of connection pooling can allow is the ability to measure 1st and 3rd party content in an A/B testing scenario. This is interesting because you can pinpoint where you are having difficulty by app component, geolocation, or even network type/speed/device. All of this will provide a very clean and detailed look at where revenue can be improved or performance problems can be avoided – all of which can lead to the best possible personalized service for your clients. If you want to see what this looks like or how this all works, visit our site.