Faster Performance for Dynamic HTML Pages | Instart Logic

1
FASTER PERFORMANCE FOR DYNAMIC HTML PAGES
BY SHARAD JAISWAL
2
INTRODUCTION
As the web evolves to deliver more engaging and
interactive experiences, one prominent outcome is
the increasing size and complexity of web pages.
As reported by httparchive, the average page size
of the top 100 websites has grown from 400KB to
1300KB over the past five years, due to the
increase in heavy images and complex JavaScript
and HTML code. This creates some serious web
performance challenges.
3
At Instart Logic we address this challenge with
our software-defined application delivery
(SDAD) platform that optimizes the delivery of
the underlying components of complex web pages,
such as images (Image Streaming), and
JavaScript (JavaScript Streaming). However,
another prominent trend is that for a significant
percentage of these sites, the underlying HTML
itself is not cacheable. As per httparchive,
nearly 40-50 of the analyzed sites have explicit
do not cache directives in the HTTP response
headers. Our internal analysis of the Internet
Retailer top 100 websites (a collection of the
most popular e-commerce websites) suggests that
almost half of web pages are not cacheable. A
page is marked as non-cacheable typically when it
involves a degree of personalization a trend
that is increasingly common across a wide range
of web sites. Since personalization requires the
execution of some server-side business logic,
such pages can lead to significantly long delays.
Dynamic pages usually represent some of the most
interactive, media-rich (and thus latency-prone)
pages on the web. Yet, their non-cacheable nature
conflicts with the traditional approach of
speeding up the delivery of web objects to
cache and serve from local browser storage or the
edge. So, we asked ourselves is there a
systematic way to bring better performance to
modern, hard-to-cache, dynamic HTML web pages?
Instart Logics answer to this question is our
new SmartSequence technology with HTML Streaming.
4
HTML STREAMING WHAT IT IS AND HOW IT WORKS

• HTML Streaming is a novel, principled and
  transparent approach to the delivery of dynamic
  HTML pages from our SDAD service. The basic
  insight is that an HTML page should not be
  treated as a monolithic object, but as being made
  up of two types of components
• elements that change rarely across requests
• elements for which change is frequent (for
  example, changes across users due to
  personalization)
• Given an HTML page, our goal is to identify and
  store the rarely-changing HTML elements on an
  Instart Logic edge server, so it can be served
  quickly to an end user's browser when a request
  arrives. We term this cacheable subset a stub,
  and it includes the client-side Nanovisor. The
  non-cacheable elements are freshly fetched from
  the origin, and then patched-in with the
  previous elements already received.
• Take a look at the timing diagram below, and
  let's assume a request is triggered from the
  browser at time t1. It is received by the HTML
  Streaming service in an Instart Logic server, and
  if the stub for the HTML page is present, then
  the client immediately gets a response, which
  arrives by time t3. If instead the stub
  was not present, the request would have gone all
  the way to the origin, waited through the server
  processing delay, and arrived at the client at
  time t7. The difference t7 - t3 is the head start
  a browser gets because of HTML Streaming.

5
Now, after sending the stub, the Instart Logic
server will make a request to the origin. When
the response arrives back at the server (at time
t5) the HTML Streaming service within the server
compares the HTML in the response to the one sent
out earlier with the stub. Any differences are
patched by sending instructions to the client
Nanovisor. If the resulting patch is found to be
unsafe, then the server and the client work in
conjunction to reload the page automatically
before anything is shown to the end user.
6
The head start a browser receives when it
processes the stub can result in substantial
performance gains (up to 40 over certain crucial
web page performance metrics such as Start
Render, and DOM Content Loaded).
CHALLENGES FOR HTML STREAMING
Our first iteration of HTML Streaming could only
be applied to pages where the ltHEADgt portion of
the HTML was the same across all users. Now with
our new enhancements, the service can handle even
the most dynamic HTML. However, transparently
(for the origin) creating a subset of a dynamic
HTML page that can be speculatively pre-executed
and patched to create the full page, exposes
several challenging technical problems. We will
now discuss some of these challenges. First, to
safeguard end-user privacy, any user-specific
information should be identified and removed from
the stub. Second, the patching should ensure the
execution order of both cached and patched-in
scripts is maintained as in the original page,
and that the page loads correctly. Third, the
stub should evolve and keep up with changes in
the origin content (while retaining the above two
properties). Finally, any unsafe or incorrect
behavior caused by the pre-execution of the
cached stub in the browser should be detectable,
and corrective action initiated if it happens. A
key design goal of HTML Streaming was thus to
learn a "safe" stub, that is, a subset of the
HTML which satisfies the criteria outlined above,
and allows us to detect unsafe pre-execution of
its content, if any. Now lets take a deeper look
into how we compute a safe stub.
7
LEARNING A SAFE STUB
The starting point behind building a safe,
cacheable stub is to periodically examine
requests over a learning period, and identify
elements in the head which are common across
requests. This, however, does not ensure safe
execution. For example, consider a HEAD with a
element of the form
ltmeta id"csrf-token" value"dkked32"gt
Assume that the value attribute of this ltMETAgt
element changes across requests, and hence this
element is not included in the cached stab (and
will be subsequently patched-in). Now suppose
there is a ltSCRIPTgt element, present in the stub,
further down the ltHEADgt which accesses this
ltMETAgt element. This could lead to problems in
the page load, since the accessed ltMETAgt element
was not included in the stub. To deal with this
issue, we virtualize the changing element. This
entails removing all sensitive (changing)
attributes, and then, using the Nanovisor, to set
up a watch by intercepting all access functions
for this element. The watch allows us to
determine if a subsequent patching of this
changing element is safe or not. In addition,
there are other conditions (e.g. preserving the
execution order of scripts) that also have to be
further satisfied to ensure correctness, which we
are not going into today as part of this blog
post.
8
AUTO-TUNED LEARNING WITH SMARTSEQUENCE
HTML Streaming has several moving parts involved
in the creation of a safe/performant stub, which
have to adapt to a wide range of web sites and
updates in the site content. The SmartSequence
technology powers and monitors the HTML Streaming
feature to ensure this adaptation is transparent
to the origin and end users. As dynamic HTML
flows through the service, SmartSequence allows
the system to first learn the patterns of which
portions of the HTML are unique and truly
dynamic, and also monitor for any requests that
are triggering a reload, and the reason for this.
Based on this information, the system
automatically adjusts the periods of up-front
learning and even adjusts for which pages the
feature is active, on a per-URL (and even
per-browser) basis, all by learning from live
production traffic. This process is continuous
and allows the system to automatically evolve as
the website or user behavior changes over time.
9
CONCLUSION
In summary, modern web sites are moving towards
personalization for better user engagement.
However, often this comes at the cost of
performance due to non-cacheable dynamic HTML. At
the same time, users are growing increasingly
impatient and want to view content as soon as
possible. Performance is thus an important
imperative for these web sites. Instart Logics
HTML Streaming feature powered by SmartSequence
technology is a new mechanism to accelerate
dynamic web page performance and improve user
experience. Evaluations of HTML Streaming applied
to Internet Retailer Top 100 sites with dynamic
HTML content demonstrate significant performance
gains for a wide range of sites. In fact, we have
observed gains greater than 20-30 on a range of
metrics such as Start Render, Load Time and Speed
Index, for 20-40 of the sites considered
(depending on the metric). These gains hold
across first and repeat views, and end user
connection types (wired cable or mobile
3G). HTML Streaming is being deployed today by
several of our customers who are enjoying these
great performance benefits.
10
Visit our Blog for more information