Looking at JavaScript Streaming Using Instart's Custom Headers

JavaScript Streaming is one of the performance optimizations we provide to customers for improving website performance. We have a document in our Help Center in the Feature Descriptions section titled What is JavaScript Streaming? that explains the feature and its applicability. The intention of this document is to provide some detail on how you can tell that JavaScript Streaming is enabled and working.

How JavaScript Streaming works

JavaScript Streaming goes through three phases (these are browser- and location-specific, so please take that into account).

Phase 1: Initial request

On the very first request for a JavaScript file, the service sends it unchanged. On the proxy, the file is transformed into an instrumented version.

Phase 2: Profiling

Once the instrumented version is created and stored in the cache, we will deliver this in place of the normal JavaScript file. This instrumented version allows us to track the usage of functions within the code. We spend a period of time learning which functions are used, and grouping them together into clusters of functions that are used at the same time. This is browser-specific, so we can determine which functions are relevant only to Chrome, Safari, IE, etc. Typically this process takes about 10 requests.

Note that profiling of JavaScripts is an ongoing process – the service always sends the instrumented version to about 5% of requests even after the code has been optimized. This allows the service to continually profile the code.

Also, if significant changes to usage patterns are detected, then we automatically drop back to the profiling mode for a period. If the JavaScript file itself changes, then we revert to creating a new instrumented version and relearn the file.

Phase 3: Delivering optimized code

Once we have determined the usage pattern of the functions in the code, we create a new version which contains only the functions that are used, and replace the other functions with stubs that can be called in real time should they turn out later to be actually required. Requests for this script will be served this optimized version, except for about 5% of requests which will get the instrumented version again as noted above.

Determining that JavaScript Streaming is enabled

Because of how JavaScript Streaming works, you need to allow the service time to learn the file for each location and each browser type you test with before the optimized code is delivered and the performance benefits can be noted.

We insert an X-Instart-Streaming header into the HTTP response to browser requests. This header provides information about JavaScript Streaming status. Let's look at what this header contains when JavaScript Streaming is enabled.

Note

The X-Instart-Streaming header also holds information for HTML Streaming. HTML Streaming is covered in the document titled Looking at HTML Streaming Using Instart's Custom Headers and Cookies.

Use browser developer tools to view the request and response headers. (If you don't know how to do this, see the document titled How to Use Browser Developer Tools to Collect the X-Instart-Request-ID Header.) Before you start, clear your browser's cache and cookies so that no stale objects from the browser cache are served.

Note that if JavaScript Streaming is disabled, or if this the first request for this file, these headers will not be present.

While the learning period is in effect during phase 2, the following response header is sent:

x-instart-streaming:  js_profiled

Once the Instart service has properly learned the website, the following HTTP header is sent:

x-instart-streaming:  js_optimized

If JavaScript Streaming is disabled, or if this was one of the early requests that first trigger the feature (before the instrumented code is served), these headers will not be present. If JavaScript Streaming is enabled and you don't see the headers after several requests, the configuration is probably not correct or the files may be under 10KB, in which case JavaScript Streaming will not apply.

When the optimized code is delivered, we might also send the X-Instart-OriginalAlias header. The presence of this header indicates that the optimized content size exceeded the original size of the JavaScript file, and hence the original content is being delivered instead of the optimized. The presence of this header might be temporary, as collection of more performance data can potentially reduce the optimized JavaScript size.