How Apps and APIs are Changing the App Acceleration Game

Modern apps are changing. And I’m not just talking about the rush to containerize apps or put them in the cloud. I’m talking about app architectures and, more specifically, the techniques behind them that are having a significant impact on networking and app services. No, not microservices or containers. I’m talking about how apps are composed and the division of duties within an app architecture.

Way back in the early days of the web (in the ‘e-commerce’ era), the need for speed propelled a number of “acceleration” technologies into data centers everywhere. These “front-end” acceleration services were focused primarily on caching and compression at the time. It was an appropriate response to an app model in which the server-side response bore most of the burden for delivering an app. The traditional “layers” of an application: presentation, logic, and data, were all bound up in a single – often large – response wrapped up in HTML.

Web 2.0 and AJAX started to change that. More of the presentation layer of the app was moved onto the client (the browser). Responses became smaller and the notion of dynamic content drove us toward newer acceleration techniques designed to address the unique challenges of these applications. Image optimization, inlining scripts, and reordering of content became an expected response to improving the speed with which these apps performed. Connection (TCP) related optimizations became imperative as a single web app started to consume often eight-times the number of connections (and commensurately, compute and memory) to achieve the dynamism users craved.

Today, REST-based API-driven apps are becoming (if they aren’t already) the norm. At this point, presentation logic is almost completely contained within the client via JavaScript-based frameworks like JQuery and Angular.  The presentation layer has always (necessarily, some might say) been the fattest of the three layers. That remains true, but with most of it constrained to the client (browser or native mobile app), the burden on the server-side has been dramatically reduced. Responses to queries are now JSON, for the most part, and often fit within the somewhat restrictive size of a single packet (about 1460 bytes). HTTP/2 and WebSockets with request pipelining capabilities and binary payloads have made connection (TCP) management on the client side nearly impotent in terms of improving performance because it’s implicitly included in the protocols themselves. The days of needing to multiplex connections are gone thanks to protocols like SPDY and HTTP/2 that provide the same result and require only a single connection.

For most apps, the images that used to provide visual cues (the icons) have moved from individual images to sprites to web icon sets from offerings like Font Awesome. With relatively tiny footprints, such icon sets provide the same visual cues at a greatly reduced data footprint and reside client-side, not server side, making image optimization less of an problem for most modern applications.

The scripts driving the UI and app logic on the client side, too, are almost universally offered in an already minimized form. Developers know to grab the “.min.” script for deployment and judiciously load them from their hosted sites – already backed by a CDN and cached for more immediate and timely response. In the past year the percentage of HTML being served via a CDN has risen to 20%. For JavaScript, it’s 21.5% of the Quantcast Top10k and 7% of the BuiltWith Top Million.

But Lori, you’re thinking, then why is the average size of a web page going up and not down?

Well, all those scripts and presentation logic are heavy. The actual size of a web page is going up because it’s now containing much of the presentation and logic that used to be delivered from the server. It’s still delivered initially by the server, but then most of the actual interaction with the app occurs dynamically, with very small chunks of data being exchanged with the server side logic. Consider the change in the composition of a “page” over the past year. Where fonts, JavaScript, and CSS have increased, HTML has actually decreased by 18%. That’s a significant change.

What this all means is that the focus of “front-end acceleration” services are changing, necessarily. The focus has to shift from manipulating and modifying content to streamlining and managing protocols. Compression may be beneficial – particularly on the first visit to an app – and caching thereafter, but performance improvements where modern apps are concerned will be best achieved through the use of protocols like HTTP/2 and optimization and offload on the server-side of the equation.

Apps are changing; not just where and in what they’re deployed, but their basic composition. That means the technologies and tools traditionally used to improve performance and address capacity issues has to change, as well.