What's the Difference Between a Web Application Streaming Network and a CDN?
Since the day Gartner VP of research, Lydia Leong, wrote that the Web Application Streaming Network is a replacement for a content delivery network (CDN) we have received many questions about the differences between the two technologies and the problems each aims to solve.
They are two fundamentally different technologies. But since many web publishers already use some CDN, it can serve as a reference point for learning about Web Application Streaming, a new, much-needed technology that comes just in time for the latest generation of ultra-rich and interactive websites and web applications being accessed via wireless networks.
Here are the four main differences we highlight in this blog post. Having a modern focus that includes mobile and wireless last mile networks, adopting a radical new approach that streams a portion of the data vs. requiring a full up front download, moving the Intelligence beyond the network layer to the application layer, and by extending its reach beyond cloud-only CDN solutions to a unique client-cloud architecture using virtualization in the browser. Let’s drill into each in a bit more detail.
Focus: Core Internet latency vs. End-to-End Solution built for wireless
Content Delivery Networks solve yesterday’s Internet problem. They were originally developed over 10 years ago when latency and routing issues in the core “middle mile” of the Internet were the most significant barriers to fast website delivery. CDNs work primarily by keeping copies of frequently accessed images, scripts, and other web site components “cached” closer to users in the edge of ISP networks. CDNs at the time were effective at solving core “middle mile” Internet latency issues back when users were all accessing the Internet over wired connections to their ISPs on desktop systems.
Now core “middle mile” bottlenecks that existed 10 years ago have shifted beyond the reach of CDNs past the edge of the ISP networks into the new wireless “last mile” networks. These new bottlenecks are now on the wireless (3G, 4G, and WiFi) “last mile” connections that exist between end users and their ISPs. CDNs were never designed to address the modern challenges in this new world of mobile devices connecting via wireless networks.
Web Application Streaming was designed thinking mobile first to address the challenges of sending web sites and applications to mobile users over wireless “last mile” networks. It provides a full “end-to-end” solution that enables faster web experiences from the customers’ origin web servers all the way to the user on an iPad in Starbucks or a laptop-toting traveler at an airport hot spot. Web application streaming accelerates user experiences over every mile as an end-to-end solution for today’s Internet delivery challenges that replaces legacy CDN approaches.
Approach: Download vs. Streaming
Content Delivery Networks need to completely download a web application before it can be displayed and the user can interact with the application. This is a key distinction, because with Web Application Streaming, users can view and interact when only a partial download of the application has occurred.
Web application streaming divides web applications into smaller fragments and then intelligently streams the most important portions of the application to the browser first. The remainder of the application then continues to stream down in the background, while the user is already interacting with the web experience. As a result the customer’s wait time is dramatically reduced.
From a user‘s viewpoint, the single most important metric is not full page load times. There is growing recognition that the user experience is more impacted by the wait until the moment when the app loads and first becomes interactive, a.k.a. the time to display. In other words, “How fast can I view, click and do something?” Some call this “time to first interaction.” Web application streaming is designed to reduce the time it takes to get users engaged, not just total download time.
Intelligence: Network layer vs. Application layer
The Web Application Streaming Network knows what is flowing through its systems and has a deep understanding of websites and apps and how they load in web browsers. CDNs do not.
A fundamental limitation of CDNs is that they operate at the network level. They were built to overcome the effects of latency by keeping copies of data closer to users and using TCP acceleration to speed raw data transfer. They are not designed to understand the 1’s and 0’s going across them. And they don’t know or understand which parts of a web site or application are most important to getting the user started and clicking.
As a result, CDNs have to send considerably more data up front, before a browser can parse the information and display it to the end user. As the size of websites and applications continues to grow, this only adds to modern performance challenges.
Web Application Streaming, by contrast, works at the application layer and is able to make intelligent decisions about the data being sent to web browsers. Awareness of various different content formats is built into the Web Application Streaming Network. For example, with a deep understanding of how a .JPG and a .PNG image differ at the byte level, it can determine what bytes per image to send up front for the initial page paint and what bytes can be sent in the background while the user is already in the site or application. And in the case of HTML itself the system can determine which parts of dynamic HTML are actually the same across all users and send that while user specific HTML is still being generated by the backend web servers.
Reach: Cloud-only Architecture vs. Client-Cloud Architecture
Content delivery networks use a “cloud-only” architecture, confined to operating in the backend of the Internet, without the ability to reach beyond the edge of ISP networks. As a result, even the most advanced CDNs can only guess about the conditions on the end users systems.
The Nanovisor also works with a cloud based component called the Personalized AppSequencer. The AppSequencer analyzes web application load and execution profiles and determines which components are highest-priority, meaning “are they needed by the user to get started?” The AppSequencer then uses that knowledge to send the components in the optimal order to the end users browsers.
Those are the biggest differences we talk about, but there are many more. If you are looking for even more detail, we invite you to read our technical whitepaper or better yet, contact us for a free trial and see how we can dramatically improve your web page load times.