A Dimensional Research survey of more than 3000 mobile app users confirmed what many of us believe about customer expectations today.
These performance-related statistics may be frustrating because we, as tech professionals, understand that the app is only a small piece of the performance equation.
We know that application performance is accretive. The measure of application performance relies on the performance of all the layers that lie beneath it. Which, in the grand OSI scheme of things, is everything but the actual code and data that make up an application.
Consider this (highly simplified) representation of 'the stack.' Each of these layers have their own performance profiles and challenges. Even the physical layer can dramatically impact application performance. Power degradation in your cable modem, for example, can cause application performance to plummet because ultimately it is the signals at the bottom layer that are transferring data. If those signals degrade, data may need to be retransmitted. Retransmission means it takes longer to transfer the entire message. That causes the customer experience to degrade because everything that relies on a strong, steady signal is negatively impacted.
I could repeat this relationship all the way up the stack. Issues with window-sizes, out of order packets, and an overloaded web server all wind up contributing to the overall performance of "the app." If any layer is performing sub-optimally, it's likely so is the application. App performance really is the sum of all the performance in the layers beneath it.
It has always been the case that per-app application services are the best option for managing app performance. Using per-app (dedicated) app services means those services can be tuned specifically to meet the needs of the application.
App performance aficionados know that some TCP settings are better for long-lived app sessions while others are better for short, bursty transactions. Little things like the MTU at the network layer can have a significant impact on the time it takes for you to download that 20GB game for your Xbox.
Application performance is impacted by many factors. All should be optimized for each application if organizations are after an optimal customer experience.
This is why I've noted so many times in the past that performance (optimization and acceleration) is an application-centric service. Increasingly that means that app acceleration services—like load balancing and app protection—must be more closely associated with the app they serve. Emerging deployment models based on notions of immutability, cloud-native architectures, containers, and infrastructure-as-code facilitate the ability to deploy and operate per-app acceleration, protection, and optimization services along with their application. This is important stuff, as these are the services that help ensure apps—mobile or web—are meeting customer performance expectations.
But we can't stop there.
We can't forget that the delivery of an optimal customer experience also depends on the same stack in the customer environment. Device capabilities, connection strength and speed, as well as system load can impact this stack of variables and degrade performance.
This is one of the reasons that application services need visibility. Information gleaned from the customer environment and combined with that of the application environment provide valuable insights into the source of performance problems. The ability to adjust those environments, too, is one that is critical to meeting or exceeding customer expectations for their application experience.
Visibility remains a key enabler of an organization's ability to secure, scale, and speed up applications. The wider we distribute those apps—across containers, across clouds, and into customer environments—the more widely we need to distribute the application services that can ensure not just visibility but action in the face of degrading performance.