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.

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:

The sections that follow describe each in more detail.

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:

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

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.

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.

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”:

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:

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.

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

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:

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.

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.

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 Virtual Traffic Manager to inform the browser when a resource has changed rather than telling it to check back with the Virtual 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:

and an auto-versioned URL could look like:

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 Virtual Traffic Manager is simply serving pages without auto-versioning enabled, the following typical data flow is in operation:

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 Virtual 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:

Subsequent page requests are then served from the Virtual 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):

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:

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 Virtual 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 Virtual 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.