Single-Page Apps Are More Complicated Than You Think

People expect a lot from their Web experiences these days, with two seemingly conflicting demands — a faster and more efficient end user experience with no delays whatsoever, and more features and functions within the context of the Web app itself.

Conventional wisdom used to hold, and still does to some extent, that faster performance for Web apps is achieved with a thinner app, but thinner apps are not what users want and need. They want fatter apps with plenty of functionality, and increasingly, they want that functionality on every device, including mobile.

They also want that feature-rich app to perform as if it were a single-function thin app. Giving the user more, and making it faster than ever, is accomplished to some degree with the innovation of Single Page Apps (SPAs).

Promoting Performance

An SPA differs from a traditional Web app. It provides a more fluent user experience, making it closer in use to an actual desktop app. Because all code is retrieved in a single page load and then runs it on the client side, an SPA becomes as responsive as a traditional native client-side app, and in many ways, that is what it is. The application model resides on the client side, with a real, honest-to-goodness piece of software. Multiple server roundtrips are no longer needed to retrieve HTML, and no re-loads are required.

There are some misconceptions, and the Single Page App is not really what it would seem to be — a Web app in which everything is contained in a single screen. While this may be the case with some apps, they still call external scripts for things like analytics or advertising networks. As such, SPAs do solve some of the performance issues commonly seen in Web apps by moving more of the processing to the client side, but often not everything simply can be enclosed in a single SPA.

When a user breaks out of a given workflow, another SPA has to be created, and the best functional Web sites are done with several apps rather than just one, with each one potentially having multiple Views. In this way, larger-scale development can be supported while still preserving the performance advantage that the SPA brings.

The Strategic Role of the Content Delivery Network

As SPAs becomes the de facto standard for Web app development, developers using this strategy have come up with a set of best practices to ensure optimum performance. Most of these are programmatic tactics, such as generating the majority of the HTML on the server side.

Despite the fact that the SPA approach does deliver some performance boost, it cannot solve all of the problems that end users complain about. There are still external scripts and databases that may have to be called, and libraries that must be served. A common recommendation from those who create SPAs is to use a Content Delivery Network (CDN) for serving these things, but the CDN too, goes only half way, and a new paradigm for optimization needs to go beyond the CDN, just as the SPA paradigm goes beyond standard app development.

Content Orchestration = Just in Time Optimization

The CDN plays an important role in delivering heavy content through a network of proxy servers, but what happens after the data leaves the CDN’s proxy servers – the “last mile” – is just as important. An SPA takes performance a step further by executing code on the client side, but even that is not enough in an environment where users demand everything now, without a millisecond’s delay.

Content Orchestration, a fundamental part of the Yottaa solution, fills the performance gap left by the CDN with a “just in time” approach to optimization, manipulating – without any code changes required — how elements get prioritized, how the app instructs the browser, or when to download and render.

More crucial elements get in front of the user immediately, and dynamic content is sequenced for just-in-time delivery exactly when it’s needed.