Ajax calls are just like any other HTTP request that might be used to build a web page. However, due to their dynamic nature people often overlook the benefit of caching them.

Rule 14 of High Performance Web Sites states:

Make Ajax Cacheable

Make sure your Ajax requests follow the performance guidelines, especially having a far future Expires header.

The rest of this blog post covers two important facts that will help you understand and effectively apply caching to Ajax requests.

Fact #1 : Ajax Caching Is The Same As HTTP Caching

The HTTP and Cache sub-systems of modern browsers are at a much lower level than Ajax’s XMLHttpRequest object. At this level, the browser doesn’t know or care about Ajax requests. It simply obeys the normal HTTP caching rules based on the response headers returned from the server.

If you know about HTTP caching already, you can apply that knowledge to Ajax caching. The only real difference is that you may need to setup response headers in a different way to static files.

The following response headers are used to make your Ajax cacheable:

• Expires: This should be set to an appropriate time in the future depending on how often the content changes. For example, if it is a stock price you might set an Expires value 10 seconds in the future. For a photograph, you might set a far futures Expires header because you don’t ever expect it to change. The Expires header allows the browser to reuse the cached content for a period of time and avoid any unnecessary round-trips to the server.
• Last-Modified: It’s a good idea to set this so that the browser can use an If-Modified-Since header in a conditional GET request to check its locally cached content. The server would respond with a 304 status code if the data doesn’t require an update.
• Cache-Control: If appropriate, this should be set to ‘Public’ so that intermediate proxies and caches can store and share the content with other users  It will also enable caching of HTTPS requests on Firefox.

Of course, this doesn’t apply if you use the POST method in your Ajax requests, because POST requests are never cached. You should always use the POST method if your Ajax request has side effects, e.g. moving money between bank accounts.

We’ve setup a Ajax caching demo that shows these headers in action. In HttpWatch, you can see that we’ve set all three of these headers in the Ajax response:

If you click on the ‘Ajax Update’ button at regular intervals, the time only changes approximately once a minute because the Expires header is set to one minute in the future. In this HttpWatch screenshot you can see that repeated clicks of the update button cause Ajax requests that read directly from the browser cache and result in no network activity (i.e. the value in the Sent and Received columns is zero bytes) :

The final click at 1:06.531 does result in an Ajax request that requires a network round-trip, because the cached data is now more than one minute old. The 200 response from the server indicates that a fresh copy of the content was downloaded.

Fact #2: IE Doesn’t Refresh Ajax Based Content Before Its Expiration Date

Sometimes Ajax is used at load time to populate sections of a page (e.g. a price list). Instead of being triggered by a user event such as a button click, it is directly called from the Javascript that runs when the page is loaded. This makes the Ajax call behave as if it were a request for an embedded resource.

As you develop a page like this, it is tempting to refresh the page in an attempt to update the embedded Ajax content. With other embedded resources such as CSS or images, the browser automatically sends the following types of requests depending on whether F5 (Refresh) or Ctrl+F5 (Forced Refresh) is used:

1. F5(Refresh) causes the browser to build a conditional update request if the content originally had a Last-Modified response header. It uses the If-Modified-Since request header so that server can avoid unnecessary downloads where possible by returning the HTTP 304 response code.
2. Ctrl+F5 (Forced Refresh) causes the browser to send an unconditional GET request with a Cache-Control request header set to ‘no-cache’. This indicates to all intermediate proxies and caches that the browser needs the latest version of the resource regardless of what has already been cached.

Firefox propagates the type of refresh down to any Ajax request that is made during the loading of the page and will therefore update any Ajax derived content as if it were an embedded resource. This screen shot of the HttpWatch plugin-in for Firefox shows the effect of refreshing our Ajax Caching demo page:

Firefox ensured that the Ajax request was issued as a conditional GET. The server responds with a 304 in our demo if the cached data is less than 10 seconds old or a 200 response with the updated content if it is out of date.

In Internet Explorer, the load-time Ajax request is treated as though it is unrelated to the rest of the page refresh and there is no propagation of the user’s Refresh action. No GET request is sent to the server if the cached Ajax content has not yet expired. It simply reads the content directly from the cache, resulting in the (Cache) result value in HttpWatch. Here’s the effect of F5 in IE before the content has expired:

Even with Ctrl+F5, the Ajax derived content is still read from the cache:

This means that any Ajax derived content in IE is never updated before its expiration date – even if you use a forced refresh (Ctrl+F5). The only way to ensure you get an update is to manually remove the content from the cache. In HttpWatch, you can do this using the Tools menu:

The 64-bit version of Windows Vista is becoming increasing popular due to its ability to access more than 4 GB of physical memory. To an ordinary Windows user, there are few noticeable differences from the 32-bit version because it can run both 32-bit and 64-bit programs.

In this post we wanted to answer some of the questions you may have about Windows Vista 64-bit and the effect it has on the use of Firefox, HttpWatch and Internet Explorer (IE).

How can I tell if a program is running in 32-bit or 64-bit mode?

The Task Manager on Vista 64-bit shows 32-bit tasks with a ‘*32′ after the process name. If there’s no ‘*32′ after the name then it is running in 64-bit mode. This screen shot shows a 32-bit process called page_check running on Vista 64-bit:

Why does IE run in 32-bit mode by default on Vista 64-bit?

Clicking on the launch bar IE icon in Vista 64-bit starts the 32-bit version of IE:

A 64-bit version of IE is available but you have to explicitly select it from the Start menu:

Microsoft has done this because the 64-bit version of IE can only load 64-bit browser extensions and most  extensions, such as the Adobe Flash player, are only available in 32-bit.

Here’s what Adobe says about 64-bit support:

Adobe Flash Player is not supported for playback in a 64-bit browser. However, you can run Flash Player in a 32-bit browser running on a 64-bit operating system.

…

Adobe is working on Flash Player support for 64-bit platforms as part of our ongoing commitment to the cross-platform compatibility of Flash Player. We expect to provide native support for 64-bit platforms in an upcoming release of Flash Player following Flash Player 10.

Without the Flash player, you can’t use sites like YouTube or BBC iPlayer. That’s a non-starter for many web users and the reason why 32-bit IE is the default on Vista 64-bit.

Microsoft is also putting off 64-bit support in Silverlight until other 64-bit extensions are available:

Right now our plan is to run SL in 32-bit mode (and not have a 64-bit native version). This is mostly because other browser plug-ins (and most browsers) don’t support 64-bit yet. We are looking at adding native 64-bit support in the future though.

Can I run Firefox in 64-bit mode on Vista 64?

There’s currently no official build of Firefox for 64-bit Windows as stated in a Mozilla support forum:

There are no releases or nightly builds of 64 bit Firefox for Windows from Mozilla as the earliest release to likely have 64-bit versions is Firefox 4.0. The only option you have is either roll your own or use a third-party build.

There’s little motivation for the browser vendors to go 64-bit because unlike other applications, such as memory hungry video editors or database servers, web browsers will not see significant performance benefits in 64-bit mode and there is also the problem with the lack of 64-bit extensions.

Can I use HttpWatch on Vista 64-bit?

Yes, you can use HttpWatch on Vista 64-bit but it is currently only available in 32-bit. This means that the HttpWatch plug-in can only be used in the 32-bit edition of IE. We will provide 64-bit plug-ins when Adobe, Microsoft and Mozilla provide significant 64-bit support.

The automation interface can be used from 64-bit programs without making any changes so as long as you have HttpWatch version 6.1.32 or later.

In some cases, such as accessing a .hwl file opened with the OpenLog method, you may see reduced performance in a 64-bit program. This is because the 64-bit API support in HttpWatch uses a separate WIN32 process rather than directly loading the API. To avoid this issue make sure that your client program runs 32-bit (see below).

Can I use the HttpWatch version 5.x automation on Vista 64-bit?

This will work, but you will need to ensure that your program runs in 32-bit mode. Otherwise, you will see this error when you attempt to create an instance of the HttpWatch controller object:

Unhandled Exception: System.Runtime.InteropServices.COMException (0x80040154): Retrieving
the COM class factory for component with CLSID {C4CEDB78-2B64-4703-99BE-A037A849D703}
failed due to the following error: 80040154.

If you’re seeing this error with HttpWatch version 6 make sure that you’ve installed version 6.1.32 or later.

How can I get my HttpWatch automation program to run 32-bit?

As mentioned above, you will need to ensure that a program using the HttpWatch automation API runs in 32-bit mode if:

• You are using HttpWatch version 5.x
• You want to improve data access performance on log files that are opened using the OpenLog method.

.Net projects (e.g. C# or VB.Net) have a default configuration setting of ‘Any CPU’. This causes them to automatically run as a  64-bit process on Vista 64-bit. To force them to always run 32-bit you’ll need to change this setting to ‘x86′ in Visual Studio:

Script based programs, such as Javascript or VBScript, that use the Windows Scripting Host will normally run in 64-bit on Vista 64-bit because cscript.exe and wscript.exe are  64-bit programs. You can force the use of 32-bit by using the script programs that are installed in the Windows\SysWow64 directory:

The sample automation code that is installed with HttpWatch version 6.1.32 or later, uses the ‘x86’ setting  in C# projects and includes instructions on how to run the Javascript samples in 32-bit mode.

In a previous blog post, we talked about the problem of using HTTP based resources, such as images, on a secure HTTPS page. Internet Explorer interrupts the download and displays a confirmation dialog whenever it detects the use of mixed content on a secure page.

In IE 7 and ealier, this dialog would cause annoyance to users but generally didn’t cause any other significant problems. This was because it was worded in such a way that most users would click on the Yes button and allow non-secure content to be downloaded.

However, the wording in the IE 8 version of this dialog has changed:

To download the content a user would now have to click on the No button. As we know, most people using the web only scan text and avoid reading it if at all possible! They will usually go for the Yes button if there is not an OK button.

Some sites are going to find that their secure pages in IE 8 have the following problems:

• Any non-secure HTTP image beacons used for analytics data gathering will often be ignored
• The page may not display or even work correctly if it relies on non-secure images, CSS or Javascript

Therefore, avoiding mixed content on HTTPS pages is even more important now that IE 8 has been released. It often becomes an issue when using third party services such as analytics or Content Delivery Networks (CDN). For example, we avoided the use of Google hosted Ajax libraries on our site until Google added HTTPS support.

As mention in the previous blog post, an IE user you can disable this warning by:

1. Going  to Tools->Internet Options->Security
2. Select the Security tab
3. Click on the Internet zone icon at the top of the tab page
4. Click the Custom Level button
5. In the Miscellaneous section change Display mixed content to Enable
6. Repeat steps 1 – 5 for the Local intranet and Trusted sites zones

However, if you are developing a web site you can’t expect your visitors to do this. It is better to fix the cause of the problem so that the warning is not displayed by default in IE 8. The only way to do this warning is to ensure that your HTTPS pages only access embedded resources using the HTTPS protocol. You can do this by following these steps:

1. Use a sniffer like HttpWatch that supports HTTPS and shows files being read from the browser cache. The free Basic Edition is sufficient for this because you only need to see the URLs being accessed.
2. Access the page causing the problem and click No when you see the security warning dialog.
3. Any HTTP resources shown  in the HttpWatch window are the source of the problem; even if they loaded directly from the browser cache and didn’t cause a network round trip:
4. If you don’t initially see any HTTP based resources, try refreshing the page because a non-secure image may have been retrieved from the IE or Firefox image cache

EDIT #1: If you are a web developer trying to track down why your page causes this warning please also take a look  at http://blog.httpwatch.com/2009/09/17/even-more-problems-with-the-ie-8-mixed-content-warning/ where we cover some javascript snippets that can also trigger this warning. The comments section of both of these posts also contain useful information where people have found and solved related issues.

EDIT #2: Updated instructions to apply the change to all network zones