Understanding Optimization Techniques

This section discusses various optimization principles employed by Web Content Accelerator. The first part relates to the concept of “Web page speed rules” and how Web Content Accelerator applies those rules to optimize your Web content. This is followed by a discussion on a number of techniques Web Content Accelerator uses to apply optimization to Web applications.

Web Page Speed Rules

These broadly fall into four categories, each of which can be applied to your Web application in order to provide a better response to the client browser:

•Reduce the number of objects being loaded by Web page

•Reduce the size of everything sent to and from the server

•Cache as much as possible to speed up repeat views

•Reduce the time it takes for the server to respond to a request

The sections that follow describe each in more detail.

Reduce the Number of Objects Being Loaded by Web Pages

For each element on your Web page, the browser will issue a HTTP request to the host where the resource is stored. Browsers limit the number of simultaneous connections that can be established to each server; therefore fewer Web page elements mean a faster Web page load. It is this time optimization step that will accelerate Web page loading the most.

Web Content Accelerator automatically reduces the number of objects by combining files when appropriate, creating “combined resource sets” by resource type. Specific information regarding the most common types is shown below:

Image In-Lining and Combination

Images are important elements in every Web page. They can be separated into CSS background and HTML images, with different approaches for each type:

•CSS background images

CSS background images are referenced from the background property in a custom style sheet or directly in a style property within a Web page. To reduce the number of requests for these resources, Web Content Accelerator will convert them to base64 data and embed this in the style sheet file or HTML.

The exact acceleration behavior differs depending upon the browser:

•For Internet Explorer (version 6 and 7) the base64 data is served in a separate file, with the style sheet background URL referencing this file using MHTML notation;

•For all other browsers, the base64 data is embedded directly into the CSS using the “data:uri” notation.

•HTML images

HTML images are images referenced from an <img> tag in a page. To accelerate these images, Web Content Accelerator can create a combined CSS sprite that contains all images of a particular format.

Web Content Accelerator then attaches some CSS style information to the <img> tag to reference this sprite as a background image, and sets the source attribute to reference a transparent GIF.

JavaScript Minification

Reducing the amount of superfluous content in JavaScript files run from within the HTML can help to improve overall page load time. Content such as redundant whitespace and comments, although useful from a software development perspective, serve no functional purpose in the operation of the page so are removed in order to reduce the file size.

Style Sheet Combination

Reducing the style sheet request count is an important step in accelerating the time a browser starts rendering a Web page. Combining style sheets is generally a safe and effective way of accelerating page load time.

Accelerating Third-Party Domain Content

By default, Web Content Accelerator applies Web page acceleration rules to elements served from the same Web subdomain from which the page is served. Consider the example of an image URL in the <img> tag for the Web site “www.example.com”:

URL	Result
/images/sample1.jpg	Web Content Accelerator optimized
www.example.com/images/sample1.jpg	Web Content Accelerator optimized
images.example.com/sample1.jpg	Not optimized
images.otherexample.com/sample1.jpg	Not optimized

It is possible to modify this configuration to include other Web subdomains, even third party domains, effectively accelerating partners’ content required to display your Web pages.

Web Content Accelerator can rewrite these resource references to either:

•Combine the object into a CSS sprite set.

•Apply versioning (see Resource Naming and URL Versioning) to the original URL, which will be served from the domain host.

A technique to increase the number of concurrent resource downloads is “domain sharding”, where some of these resources are downloaded from different Web domains or subdomains. This approach provides more benefits than domain sharding, because every distinct Web domain name used on a Web page requires additional DNS resolution time and TCP connection establishment time. Also, the chance of some content being unavailable is greatly reduced, since this content is now being served from your Web server.

Reduce the Size of Everything Sent to and from the Server

By default, Web Content Accelerator works to automatically reduce the size of content sent from the server.

•Text based objects are compressed using the gzip compression algorithm.

•JavaScript and style sheet files are minified by removing all redundant whitespace characters and comments.

•Redundant image information (such as metadata) is removed, and JPEG images are, by default, resampled to 85% of their original quality.

Cache as Much as Possible to Speed Up Repeat Views

Browsers can locally cache resources for faster reuse on subsequent Web page visits.

Web Content Accelerator automatically applies cache headers to all resources, providing browsers with information needed to manage those resources. By default, Web Content Accelerator applies different cache durations to resources depending on how they are referenced, as shown in the following table:

Condition	Cache for
Object is combined into a resource set	1 year
Object URL was versioned by Web Content Accelerator	90 days
Original object URL was requested	1 hour

Public Proxy Caching

Optionally, Web Content Accelerator can help leverage any intermediary caching proxy server, such as those commonly used in corporate environments and Internet service providers (ISPs). By using a specific attribute, Web Content Accelerator will add “cache-control: public” headers to all or any specific resources.

Marking resources as proxy cacheable can provide a significant improvement in both first view and repeat view load times for users who access a Web page on a Web site other users have already accessed.

Reduce the Time It Takes for the Server to Respond to a Request

This rule applies to the time it takes for your server to start sending a HTML response to your client’s browser. As previously mentioned, this can be up to 20% of the Web page load time.

Reducing this time is directly related to your server, application design and maintenance. Possible solutions can involve scaling up (achieved by adding system resources such as processor and memory to existing servers), scaling out (achieved by increasing the number of server nodes to distribute workload over more nodes), code profiling and tuning, database tuning, sharding (distributing the database over multiple servers), Web server tuning and more.

This rule applies to your Web server and application, thus outside the scope of this chapter.

Resource Naming and URL Versioning

Web Content Accelerator will create a new identity for each “combined resource set” or “URL auto versioned resource” created in the process of accelerating your Web pages. This approach allows the Traffic Manager to inform the browser when a resource has changed rather than telling it to check back with the Traffic Manager every so often to see if it has changed. We do this by making the URL of the resource dependent on its content.

For example, a resource set could be named:

/optimized-gif-kjmMLxSEdXYqXt3coAasow4F=-ds3432d.gif

and an auto-versioned URL could look like:

/images/optimized-jpg-23dgdsds5563gfv=-P9vry3Uq22.jpg

The string of numbers and letters in these URLs represent a unique hash value of the settings, the content and any child resources that make up a particular resource. Whenever a setting is modified, any resources for which that setting applies will automatically be recalculated. Thus, any change to the content of a resource will also cause this unique value to change.

Under normal circumstances, where the Traffic Manager is simply serving pages without auto-versioning enabled, the following typical data flow is in operation:

1.The client requests an HTML page through a service running on the Traffic Manager.

2.The client receives the HTML page back, with links to regular resources (for example, style sheets, images, and so on).

3.The client fetches these resources.

4.The Traffic Manager serves them from the back-end server, possibly optimized depending on the Web Content Accelerator settings used.

5.The client caches any available resources locally.

6.Some resource is changed on the back-end server for whatever reason (for example, bug fixing, a layout change, and so on).

7.The client requests another HTML page on the same website.

8.The client receives the HTML page from the Traffic Manager with a link to the same resources.

9.The client is unaware of the change on the server, and refers to its own locally cached (and unexpired) versions of any identified resources and does not re-request them from the Web service.

As shown in the last step, one essential flaw with this scenario is that the client will wait a period of time before re-requesting a cached resource, which may or may not have changed. The client could therefore be using an out of date copy of a resource until some event occurs to prompt the re-request.

With auto-versioning enabled, the Traffic Manager provides the assurance that the client will always be using the most up-to-date copy of a resource contained in a Web page. The following data flow demonstrates this:

1.The client requests an HTML page from a Web service provided through the Traffic Manager.

2.The Traffic Manager notices the HTML page references one or more resources.

3.The Traffic Manager fetches these resources (and possibly optimizes them, depending on the Web Content Accelerator settings), examines the content and creates a hash value based upon it.

4.The Traffic Manager creates a new URL for such resources that includes the computed hash value, and replaces all references in the HTML page.

5.The altered page is returned to the client.

6.The client requests the in-page resources from the Traffic Manager, via the new URL.

7.The Traffic Manager serves the identified content from its cache (or fetches it from the back-end server if its not in the cache).

8.The client locally caches resources using the new URL.

Subsequent page requests are then served from the Traffic Manager with the test that the computed hash value of each resource has not changed (based on the resource content at the back end):

1.The client requests another HTML page.

2.The Traffic Manager observes that the contained resources have not changed on the back-end server and writes in the same computed hash-value URL as last time.

3.The client uses its cached copies of those resources.

Should a resource change on the back-end server, subsequent page requests will be affected by virtue of the computed hash-value being different. The following scenario occurs:

1.A resource change forces a re-compute of the content-based URLOne or more resources change on the back-end server.

2.The client requests another HTML page.

3.The Traffic Manager observes that the desired resource has changed on the back-end server and creates a new URL based on the new content - different to the previous one.

4.The client does not have a cache entry for the new URL, so it requests it from the Traffic Manager, which serves it back.

5.The client is immediately using the new version of any changed resource.

Using a Content Distribution Network

Content Distribution (or Delivery) Networks (CDNs) host some or all of your resources on servers that are geographically distributed, reducing latency between your Web server and the customer. For further information on CDNs, refer to http://en.wikipedia.org/wiki/Content_distribution_network.

You can leverage a CDN with Web Content Accelerator using the URL rewrite to CDN configuration setting on the Web Content Accelerator Profiles edit page (custom profiles only).

This setting instructs the Traffic Manager to rewrite the HTML for requests that match that rule so that resources are then downloaded from the domain provided by your CDN instead of your own Web server.

The Traffic Manager will automatically use the scheme (HTTP/HTTPS) of the incoming request when accessing a CDN host, but it is possible to manually specify the scheme and virtual path in the URL rewrite to CDN setting if required. This allows the scenario of switching all traffic to SSL if the target Web site is reverse proxied through another device that terminates the SSL connection.