This warning is triggered in IE if it is displaying a secure HTTPS page that has caused a non-secure (i.e. HTTP based) resource to be downloaded. The message box doesn’t allow the user to control whether the non-secure content should be downloaded, only whether it should be displayed. 

This seems rather pointless as the damage may already have been done if the non-secure content was a picture of your passport, bank statement or credit card! However, this is the default setting in IE so it is best to avoid this warning being generated on your web site.

This setting can be changed in IE by:

1. In IE go to Tools->Internet Options->Security
2. Select the ‘Security’ tab
3. Click the ‘Custom Level’ button
4. In the ’Miscellaneous’ section change “Display mixed content” to Enable

Recently, we saw this warning in the shopping cart of an  computer store,  so we fired up HttpWatch to see what was causing the problem. A quick search for a URL starting with ‘http:’ should have located the request causing the problem:

No HTTP requests were recorded for this page in HttpWatch. So what was causing the ‘Do you want to display nonsecure items’ message?

It turns out that IE warns about HTTP based content even if it was read from the browser cache or the IE image cache. Requests from the browser cache are shown as (Cache) in HttpWatch, but as we previously described access to the IE image cache is not recorded.

The resource causing the warning on this page must have been read from the image cache. We confirmed this by refreshing the page in IE and performing another search:

The refresh forced IE to download all the embedded resources on the page and it became clear that it was the Google Checkout image that was causing the problem. Changing this image’s URL to use HTTPS would prevent the warning from appearing.

“My team has been using HttpWatch for a few months now to analyze the client side performance of SkyDrive.  Previously, I had relied on some internal tools we use that are based on NetMon, as well as Fiddler and Firebug with the YSlow plugin.  While these tools were pretty good, here’s why I think HttpWatch beats them all”

from HttpWatch - My favorite web performance tool,

“Inspecting the payload your server is issuing out can be quite tricky, luckily for the likes of you and I the boffin’s at Microsoft created Fiddler and Simtec created HttpWatch (which I use every single day - probably the best developer tool I’ve got in my arsenal, it’s also coincidentally the tool you’ll see screen shots from throughout this article)”

from Pimp my ASP.NET web application - Part One

“Wow, I thought I was good at learning about new tools, but I never heard about HttpWatch … It works much in the same way as Firebug, as a add-in to Internet Explorer. It looks really really cool, and some of the features are even better than Firebug. I like how it even gives you insight into the TCP level of your browsing sessions, such as how much time a DNS lookup takes”

from Httpwatch: Commercial alternative to Firebug for Internet Explorer

“While modifying a website which uses AJAX, we are converting from a rather non-standard implementation of AJAX calls to one that is a lot more standard.  But, we’re still concerned about the number of the objects being downloaded, the size of each object, the time each object takes to download, the number of round-trips, etc. We wanted a way to easily visualize what’s happening. HttpWatch provides a way”

from A New Tool in My Tester’s Tool Box - HttpWatch

“HttpWatch is a great add-on tool to Internet Explorer that captures your IE HTTP traffic. The best part for me is that it can be driven programaticly from my Watir Tests.“

from Using HttpWatch with Watir

The technology to make HTTP calls from JavaScript embedded in an HTML page was first introduced for general use by Microsoft in IE5 in order to support Outlook Web Access way back in 1999. However, the XmlHttpRequest object was not widely used until it was adopted by Mozilla in 2002. In 2005 the programming model was given the name Ajax which has now been widely recognised and stands for Asynchronous JavaScript + XML.

From a performance perspective Ajax has two main benefits:

1. It can reduce the number of round trips by minimizing the number of page transitions in a web application
2. It can reduce the size of uploaded and downloaded data because it allows the web programmer to control exactly what is transferred. For example, if a user performs a search the data can be returned in a compact data format (e.g. JSON ) rather than HTML.

In order to illustrate how Ajax can increase the speed and usability of a site let’s first look at a traditional web site and then compare it to an Ajax example.

This is what happens on Expedia.com when we try to book a flight but we specify a partial or mispelled city code. In this case we typed in “LOND” instead of “LON” or “London”. We expectantly press the submit button hoping for a list of possible flights, but instead we’re directed to an error page:

Using HttpWatch we can see that Expedia took 4.4 seconds, 30 round trips and 156K of data (of which 41K was uploaded)  to display the error page:

Even if there are no further mistakes we will still have to make further page transitions before we get the results we’re expecting.

Let’s look at a similar example on BA.COM where Ajax has been used:

Here we did exactly the same thing - typed “LOND” instead of London. Instead of having to press submit, fetch a new choices page (with all linked page components) and drag the user through an additional form, the page used background processing to query the server and display a list of possible choices.

The beauty of this approach is that is that it didn’t require any user interaction, is very fast and it didn’t leave the search page. Here’s the Ajax request in HttpWatch:

BA.COM uses the DWR framework for Ajax to request the possible airports. The framework returns a JavaScript list used to render the content into the dropdown list control. The single HTTP call required is much smaller and faster than the Expedia model where the whole page must be fetched and rendered.

Due to the inconsistencies between the programmable object models on different browsers, most developers now choose a framework to ease JavaScript development and most provide Ajax helper functions that wrap XmlHttpRequest. Java’s DWR has RPC style support. ASP.Net’s Ajax library, Dojo, Yahoo’s YUI and Google’s GWT support a whole suite of UI and control extensions as well as offering some kind of Ajax support. Similarly, Prototype and jQuery are two extremely lightweight and popular JavaScript libraries.

Let’s say you wanted to populate a list box with city codes based on the country a user selects. In Web 1.0 you would have to submit a form making a round-trip to the server with your choice of country so that the server could render the appropriate list of choices on the resulting HTML page.

With Ajax, this can all be done in the background. A lot of services use the XML data format, but there’s no restriction on the content type that XmlHttpRequest can send or receive. It could be HTML, JSON or any other format that the page’s JavaScript can parse.  Here’s an example of using the jQuery library to populate a list control from an Ajax request:

<script type="text/javascript" src="jQuery.js“></script>
...
<h2>Products</h2>
<div id="products“>(fetching product list …)</div>
<script>
…
new Ajax.Updater(’products’, ‘/productListHTML.aspx’, { method: ‘get’ });
…
</script>


The products <div> is initially empty, but the Ajax class Updater method wraps XmlHttpRequest and fetches some HTML from the server and uses it to populate the <div>.

One of the drawbacks people found with using Ajax was that they ended up breaking the back button. Clicking the Back button in some Ajax applications did not go to the previous logical operation. For example, if you were viewing the results of a search you would expect Back to take you to the search page so that you could modify the search criteria. Instead, the user would be taken to whatever happened to be the previous page in the browser’s history list.  In some cases, they may even have been the previous web site that the user had visited.

More recently though, browsers have exposed object models to help Ajax applications manipulate the browser history artificially so that they can correct the flow of operations as the user uses the forward and back buttons.

The Blocked time in HttpWatch is shown as a gray block at the start of a request:

We measure this time by looking at the time interval between these two events:

1. The point at which IE determines that it requires the resource at a certain URL. For example, it may have downloaded some HTML and encountered an <img> tag that refers to a GIF file.
2. At some later time IE peforms a network action required to download or validate a cached copy of the resource.

During this time interval, IE will check the cache to see if the resource is stored locally, determine what headers and cookies would have to be sent in a GET request to the server, and if necessary, wait for an existing connection to become available.

Although, IE is multi-threaded and could start downloading many resources in parallel it is subject to a connection limit per host name. The HTTP 1.1 specification (RFC2616) recommends that HTTP clients should have no more than two connections active per host name. Therefore, a web page that has all its embedded images, CSS and javascript files on the same hostname (e.g. www.example.com) will only be able to use a maximum of two connections to download content.

Here’s a screenshot from HttpWatch that shows what happens when you force a refresh (Ctrl+F5) of our home page using IE 7:

At any one time, only two HTTP requests are actively downloading content. The rest are in the blocked state waiting for their turn to use one of the two connections to the web server. The two yellow segments in the first two requests indicate that two TCP connections were made to the server (a yellow segment in an HttpWatch time chart indicates the TCP connect time).

For many web pages this has a major performance impact and is a strong motivator for reducing the number of round trips whenever possible.

Microsoft has just released IE 8 Beta 1. One of the most significant changes compared to IE 7 is that the maximum number of connections per host name has been changed. If you are on a fast, broadband connection it now uses a maximum of six rather than two connections per host name.

BTW, if you are going to use HttpWatch with IE 8 Beta 1 please make sure that you download and install version 5.3.

This screen shots shows the six connections being made with IE 8 and the increased concurrency during download:

The increase in the number of connections leads to a major reduction in blocked time. We found that the load time for our home page, with an empty cache, is on average 50% less in IE 8 Beta 1 compared to IE 7.

Steve Souders, author of ‘High Performance Web Sites’, has written a blog post entitled ‘Roundup on Parallel Connections’ that discusses the connection limits of other browsers and the possible effect on existing web servers.

However, you may not be aware that IE uses two caches for holding images. First, there is the regular browser cache that keeps a copy of downloaded image files in your Temporary Internet Files folder. It’s this cache that can be controlled by HTTP response headers such as Cache-Control and Expires.

There is also an image cache that IE uses to hold recently used images in memory. The main difference between the image cache and the browser cache is:

• The image cache is never written to disk and is always emptied when IE closes
• The image cache contains an expanded, Windows bitmap version of  GIF, JPG or PNG files
• HttpWatch does not record access to the image cache, unlike the 304 and (Cache) responses that you’ll see when IE reads content from the browser cache

The point of the image cache is that it can be used to quickly render images without taking the CPU hit required to convert them from their native compressed format into a Windows bitmap.

The only documentation about the image cache is the ”Image Cache Limits” section of the registry settings for IE on Windows CE:

http://msdn2.microsoft.com/en-us/library/aa908131.aspx

Here’s the relevant section:

Although, these settings don’t work with IE 6 or 7 they do show that the image cache has limits on the size of images, the number of images cached and the maximum amount of memory that can be used. Limits like this have to be set because the expanded images can take up to 500% more memory than the original PNG, GIF or JPG format.

Let’s see the effect of the image cache by starting a new instance of IE and visting www.httpwatch.com:

The (Cache) responses shown in HttpWatch indicate that the images on our home page were read from the browser cache.  The image cache would have been empty at this point because IE had just started.

If you click on the Download tab and then click back on the Home page tab you’ll see that only two images are shown in the resulting HttpWatch trace:

Clearly, all the images for the home page must have been loaded from somewhere because the page was correctly rendered, but only two images requests from the browser cache are seen in HttpWatch. This is because the other images were read from the image cache.

Why were two of the PNG files still read from the browser cache? These two images are the largest image files on the page and they would expand to approximately 500 KB and 300 KB if they were both placed in the image cache. They probably breached the maximum image size limit in the IE 7 image cache and were therefore not stored in their expanded form.

It’s also possible to see that the image cache has a limit on the number of images it stores. Try visiting ebay.com and then yahoo.com in the same browser window to load up the image cache. If you then go back to www.httpwatch.com you’ll see that all the images have been flushed out of the image cache and had to be reloaded from the browser cache.

So, to make effective use of the image cache in IE you should:

1. Minimize the number of images that your site uses
2. Avoid single images that might expand to more than approx 200 KB

Of course, you should always try to minimize the number of images to reduce the network round-trips when a browser first loads a page. A popular technique for doing this is to use CSS sprites to merge several images together and there are some great tools to help you create the compound image.

Be careful though, that you don’t run into item 2) by creating a single large image that is not loaded into the image cache. You would get the benefit of less round trips on an initial visit, but the rendering in IE might actually be slower because the image would have to expanded from the browser cache whenever it was re-displayed.

http://www.httpwatch.com/download/versionfeed/

We’ll continue to announce major and minor version updates here (e.g. 5.0, 5.1, etc) but the new feed will also provide notification of fixes (e.g. 5.2.14, 5.2.16, etc).

(Aborted) is one of three pseudo status codes that are used in HttpWatch to display information about HTTP requests that did not receive a status code from the server:

• (Aborted)
• (Cache)
• ERROR_*

The last two values are fairly straight forward. The (Cache) result is displayed when content is read directly from the browser cache with no network round-trip. If there’s no network round-trip, there’s no HTTP status code returned from the server. And the ERROR_* result (e.g.  ERROR_INVALID_URL) is used when a request fails to complete because an error was detected by Internet Explorer.

The (Aborted) value is more complex in its origin. It occurs when IE has started to process the request for a URL (e.g. to download an image), but then decides to cancel the operation. Here are some examples of when this can occur:

1. If you click on a link or bookmark while a page is downloading, or click on IE’s Stop button, you will see that IE cancels any requests which are still active and HttpWatch shows the (Aborted) result.
2. A CSS rollover image on a page will start a request when the mouse pointer is moved into its active area. If the mouse pointer quickly moves away again, IE may abort the request if it has not already completed.
3. Sometimes javascript is used to fire off requests for background tasks or to gather statistics on a page. Often this can lead to aborted results if the javascript does not wait for the response to be received from the server.

A common question is “Will our server receive requests that ended up being aborted?”. The answer is that it depends when the request was aborted. By looking at the timing chart in HttpWatch you can determine how far the request was through its normally processing cycle before it was cancelled.

Here’s an example of a request that was aborted while a connection was being made:

The server would not have received the HTTP request message in this case, because the Send state was not reached.

The request shown below was aborted when IE was awaiting a response and therefore the request would have been delivered to the server:

The presence of an (Aborted) entry in an HttpWatch log file is often just a consequence of the way that the user is interacting with a web site, rather than an indication that something has gone wrong.

However, one of the causes of poor performance that is often overlooked is the transmission time taken to upload data to the server. Although, HTTP request messages are typically smaller than HTTP response messages, the performance cost can be an order of magnitude higher per byte. This is caused by the asymmetric nature of many consumer broadband connections.

For example, the results of a speed test on a UK broadband cable connection are shown here:

The upload speed is only about 6% of the download speed. That means, byte for byte, uploaded data takes about 16 times as long to transmit as the equivalent amount of downloaded data.

To put it another way, if you upload 4 KB of data in an HTTP request message it may take the same length of time as downloading a 64 KB page.

You can easily see the size of the HTTP request message by looking at the Sent column in HttpWatch:

The value shown in the Sent Column is made up of the size of the following items:

• The HTTP GET or POST request line
• HTTP request headers
• Form fields and uploaded files sent with POST requests

Unfortunately, request data is never compressed because there is no server-side equivalent of the Accept-Encoding request header that is used by browsers to indicate that they support compression of downloaded content.

For a typical site, you might be surprised to know that the request data can be up to 50% of the size of the response data. Since many broadband connections are asymmetric, this can have a substantial impact on performance. Here’s an example of a flight search page on Expedia:

The ratio increases as the downloaded content is cached by the browser, often making uploaded data the most significant factor in the performance of a web page.

So what can be done to reduce the amount of uploaded data?

Step 1: Minimize the size of Cookies

Cookies are simply part of the request headers. Expedia uses around 9 cookies which are fortunately quite small but it’s easily possible to end up with a lot of cookie data, particularly if you’re using 3^rd party web frameworks. RFC2109 specifies that browsers should support at least 20 cookies for each domain and at least 4K of data per cookie.

The problem with cookies is that they need to be sent with every single HTTP request where the URL is in the domain and path to which they apply. That includes requests for style-sheets, images and scripts.  So in most cases the amount of cookie data uploaded, is effectively multiplied by the number of requests per page.

One way to reduce the amount of cookie data (apart from making them as small as possible and using them less) is to use different domains or paths for your content. For instance, you probably need cookies in your page processing code but you don’t need them for static content such as images. If you put static content in a different location, cookie data will not be sent because cookies are domain and path specific.

Another way to reduce cookie data is to look at server-side storage, such as using the session state management of a framework like ASP.NET. You can then use a single cookie that just contains a session id and look up any session related data on the server when required. Of course, this may have an impact on server side performance, but it is a useful way of minimizing the amount of cookie data that a site requires.

Step 2: Avoid Excessive use of Hidden Form Fields

There are two sets of data in a typical HTML form:

1. Fields you want the user to fill out with information.
2. Hidden fields.

You can’t really do much about the first type, except reducing the size of your field names. This may be difficult depending on your implementation framework.

Hidden fields are used to maintain page-scoped variables that will be required by the server when the form is submitted, e.g. a user ID. They may also be injected by various web frameworks or server-side controls. One such example is the __VIEWSTATE field used by ASP.NET as shown below:

There are two reasons for doing this. Firstly it’s easier to have the state to hand (so to speak) in your page logic and secondly it often scales better across a web farm by keeping page scoped state within the page rather than fetching it from somewhere else like a database. 

One way to reduce the amount of data in hidden fields is to only use a single key in a hidden form field. The key value is then used on the server to retrieve the data required to process the submitted page. This is exactly like the approach used to reduce the amount of cookie data.  And like with cookies, reducing request transmission time in this way may have an impact on server-side performance and scalability.

Step 3: Avoid Verbose URLs

This is not the most important issue on the list, but it is still worth considering. In practice there are no ubiquitous limits on URL length, but most browsers will struggle with URLs longer than 4 KB - some may struggle at 1 KB or less. Remember that your URL will also end up in the referrer header of images and other embedded resources.

It’s usually the query string parameters that make a URL overly long. Again using Expedia as an example, you can see how many sites use these variables:

http://www.expedia.com/pub/agent.dll?qscr=fexp&flag=q&city1=lon&citd1=bos&date1=1/22/2008&time1=362&
date2=1/22/2008&time2=362&cAdu=1&cSen=&cChi=&cInf=&infs=2&
tktt=&trpt=2&ecrc=&eccn=&qryt=8&load=1&airp1=&dair1=&rdct=1&
rfrr=-429

In this case the URL is used to quickly pinpoint a results page for flights between ‘city1′ London (LON) and ‘city2′ Boston (BOS) on specific dates.

Encoding data like this in URLs does have certain advantages. If you bookmark or share the URL the same results will be displayed when the URL is next used. However, if the URL contains unused or redundant data it may be causing a significant increase in the amount of uploaded data.

1. Don’t cache HTML
2. Cache everything else forever

“Wooah…hang on!”, we hear you say. “Cache all my scripts and images forever?“

Yes, that’s right. You don’t need anything else in between. Caching indefinitely is fine as long as you don’t allow your HTML to be cached.

“But what about if I need to issue code patches to my JavaScript? I can’t allow browsers to hold on to all my images either. I often need to update those as well.”

Simple - just change the URL of the item in your HTML and it will bypass the existing entry in the cache.

In practice, caching ‘forever’ typically means setting an Expires header value of Sun, 17-Jan-2038 19:14:07 GMT since that’s the maximum value supported by the 32 bit Unix time/date format. If you’re using IIS6 you’ll find that the UI won’t allow anything beyond 31-Dec-2035. The advantage of setting long expiry dates is that the content can be read from the local browser cache whenever the user revisits the web page or goes to another page that uses the same images, script or CSS files.

You’ll see long expiry dates like this if you look at a Google web page with HttpWatch. For example, here are the response headers used for the main Google logo on the home page:

If Google needs to change the logo for a special occasion like Halloween they just change the name of the file in the page’s HTML to something like halloween2007.gif.

The diagram below shows how a JavaScript file is loaded into the browser cache on the first visit to a web page:

On any subsequent visits the browser only has to fetch the page’s HTML:

The JavaScript file can be read directly from the browser cache on the user’s hard disk. This avoids a network round trip and is typically 100 to 1000 times faster than downloading the file over a broadband connection.

The key to this caching scheme is to keep tight control over your HTML as it holds the references to everything else on your web site. One way to do this is to ensure that your pages have a Cache-Control: no-cache header. This will prevent any caching of the HTML and will ensure the browser requests the page’s HTML every time.

If you do this, you can update any content on the page just by changing the URL that refers to it in the HTML. The old version will still be in the browser’s cache, but the updated version will be downloaded because of the modified URL.

For instance, if you had a file called topMenu.js and you fixed some bugs in it, you might rename the file topMenu-v2.js to force it to be downloaded:

Now this is all very well, but whenever there’s a discussion of longer expiration times, the marketing people get very twitchy and concerned that they won’t be able to re-brand a site if stylesheets and images are cached for long periods of time.

In fact, choosing an expiration time of anything other than zero or infinite is inherently uncertain. The only way to know exactly when you can release a new version to all users simultaneously is to choose a specific time of day for your cache expiry; say midnight. It’s better to set indefinite caching on all your page-linked items so that you get the maximum amount of caching, and then force updates as required.

Now, by this point, you might have the marketing types on board but you’ll be losing the developers. The developers by now are seeing all the extra work involved in changing the filenames of all their CSS, javascript and images both in their source controlled projects and in their deployment scripts.

So here’s the icing on the cake; you don’t actually need to change the filename, just the URL. A simple way to do this is to append a query string parameter onto the end of the existing URL when the resource has changed.

Here’s the previous example that updated a JavaScript file. The difference this time is that it uses a query string parameter ‘v2′ to bypass the existing cache entry:

The web server will simply ignore the query string parameter unless you have chosen to do anything with it programmatically.

There’s one final optimization you can make. The Cache-Control: no-cache response header works well for dynamic pages as it ensures that pages will always be refreshed from the server; even when pressing the Back button. However, for HTML that changes less frequently it is better to use the Last-Modified header instead. This will avoid a complete download of the page’s HTML, if it has not changed since it was last cached by the browser.

The Last-Modified header is added automatically by IIS for static HTML files and can be added programmatically in dynamic pages (e.g. ASPX and PHP). When this header is present, the browser will revalidate the local, cached copy of an HTML page in each new browser session. If the page is unchanged the web server returns a 304 Not Modified response indicating the browser can use the cached version of the page.

So to summarize:

1. Don’t cache HTML
   • Use Cache-Control: no-cache for dynamic HTML pages
   • Use the Last-Modified header with the current file time for static HTML
2. Cache everything else forever
   • For all other file types set an Expires header to the maximum future date your web server will allow
3. Modify URLs by appending a query string in your HTML to any page element you wish to ‘expire’ immediately.