What is HTML Streaming?

With traditional web delivery approaches, personalized dynamic HTML must be generated for each request before any content can be sent back to the requesting browser. The browser makes a request, and then there is a delay while the back end web and application servers generate the user-specific HTML and deliver it over the global Internet to the requesting browser. Traditional content delivery services therefore provide only basic network acceleration for dynamic HTML.

Fig. 1 – Traditional HTML delivery

To overcome this obstacle, Instart has invented a new technology called HTML Streaming. The technology is based on the recognition that most “dynamic” HTML is not completely dynamic – that is, there are often significant parts of it that do not change (for example, the CSS and JavaScript used on the page), and other parts that do (such as user-specific content). HTML Streaming distinguishes between the unique and non-unique dynamic HTML, and saves time by streaming the non-unique dynamic HTML from an Instart server close to the end user's browser while the backend server is generating the unique dynamic HTML.

Fig. 2 – HTML Streaming

The browser can then make use of previously wasted time, as it can begin processing the non-unique parts of the HTML while the backend server is generating the unique HTML. Until now, these logically separate activities could only occur sequentially.  The browser can begin rendering the page, and soon after, using the client-side Nanovisor, seamlessly patch in the remaining HTML when it arrives. The result is a dramatic decrease in the time it takes to respond to dynamic requests – meaning that the browser can start rendering the page sooner.

HTML Streaming works by storing information about the <head> element from previous loads of the same URL by other users and determining which parts have changed and which parts have not. The service actually learns which parts of the <head> are unique and which are not based on analysis of a collection of requests from real users. It can then send portions of the <head> of dynamic HTML from our proxy servers in advance of receiving the full dynamic HTML from the backend origin server.

A common example of dynamic content in an otherwise static <head> is the use of unique user-specific tokens which are used to defend against cross-site request forgery (CSRF) attacks, or customers putting user- or session-specific information in the <head>.

HTML Streaming sends the non-unique portions of the <head> on the dynamic HTML request to the client while also requesting the full dynamic HTML from the backend origin. Once the dynamic HTML is received by the Instart proxy, it compares it with the <head> HTML sent in advance to the requesting browser. It then generates a series of patch commands that are sent to the requesting browser to update the DOM and run any skipped scripts before processing the <body> element of the HTML. This allows the browser to perform a number of operations in advance while waiting for the full HTML from the back end to be delivered.

Using HTML Streaming, a browser is able to do the following in advance of receiving the full dynamic response from the origin:

  • make DNS lookups, create TCP connections, and, if applicable, establish SSL connections for domains referenced in the <head> element of the HTML
  • warm the local browser cache with external CSS, JavaScripts, and other objects referenced in the <head>
  • parse the CSS files referenced in the <head>
  • parse the JavaScript files referenced in the <head>

The following are example waterfalls and metrics for the Instart blog, one with HTML Streaming turned off and one with it turned on.

Metricwithout HTML Streaming
(Chrome @ 5mbps)
with HTML Streaming enabled
(Chrome @ 5mbps)
Waterfall

Time to First Byte0.796 sec0.101 sec (87% improvement)
Start Render1.453 sec0.988 sec (32% improvement)
onLoad Time3.138 sec2.661 sec (15% improvement)

What web performance metrics will be positively impacted by using HTML Streaming?

Our testing has established that the largest benefit comes from the ability to parse external JavaScript referenced in the <head> HTML. The other items listed above also contribute incremental performance improvements.

While actual results will vary depending on a number of factors (such as the number and size of external scripts and stylesheets), our testing shows that HTML Streaming can improve the following web performance metrics:

MetricDescription
TTFB (Time to First Byte)This is the largest area of performance improvement, as the browser will receive a faster initial response from our edge servers vs. having to wait for back end HTML generation and delivery over the internet.
Start RenderThis is the next area of performance improvement, as the browser will begin processing HTML, downloading external JS and CSS, and even start parsing some of those elements. As a result it will be able to start rendering the page to the screen faster than traditional approaches that only start processing dynamic HTML once it is generated at the origin, sent back, and received by the browser.
Document CompleteThis is another area of potential improvement, but will likely vary depending on the number of objects referenced in the <body> HTML. This is a metric that can be impacted by many things that occur based on elements in the <body>, and so in some cases the document complete, which is an indicator of page ready and first paint, will improve.

Where does HTML Streaming have the most impact on performance?

This feature will most significantly benefit sites that have heavy <head> elements in their dynamic HTML and longer back end HTML generation times. By "heavy <head>" we mean that the more external CSS and JavaScript files and the more unique domains that are referenced in the <head>, the better this feature will perform vs. traditional approaches. This is because the browser can get started with DNS lookups, TCP connections, and downloading and parsing external JS and CSS files.

Additionally, the longer the HTML generation time and the more network distance between the end user and the back end, the better this feature will perform vs. traditional approaches.

Where does HTML Streaming have the least impact on performance?

Sites with light <head> elements, meaning there is not much content in terms of external CSS and JavaScript references present, or few additional domain references, will see minimal improvements. Sites with extremely fast HTML back end generation times also may not benefit much from this feature.

Sites that use fast flushing of dynamic HTML – where the <head> is sent in advance of the rest of the HTML – might not benefit as much from the HTML Streaming feature as others, because this approach also allows the browsers to start processing the HTML before the entire HTML page is delivered. Our platform may still provide a substantial geographical advantage in these cases, so it is worth doing some case-by-case benchmarking.

What do I need to do to enable HTML Streaming?

HTML Streaming does not require changes to the backend web servers nor to the code that makes up the web site or application. As the HTML flows through the Instart platform, the service automatically learns which portions of the dynamic HTML are non-unique across users, and continues to relearn as the web site or application is updated over time.

All that is required is that your configuration be set up to enable HTML Streaming on the site. Like all of our features, it can be selectively enabled for certain hosts, specific directories, or under certain conditions.