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
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
- parse the CSS 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.
|Metric||without HTML Streaming|
(Chrome @ 5mbps)
|with HTML Streaming enabled|
(Chrome @ 5mbps)
|Time to First Byte||0.796 sec||0.101 sec (87% improvement)|
|Start Render||1.453 sec||0.988 sec (32% improvement)|
|onLoad Time||3.138 sec||2.661 sec (15% improvement)|
What web performance metrics will be positively impacted by using HTML Streaming?
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:
|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 Render||This 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 Complete||This 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?
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 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.