Internet Explorer handles AJAX responses different than other browsers. It will cache the response. The tendency on most articles I’ve read is: Caching is bad and you need disable caching!. No!!! Although Microsoft didn’t program Internet Explorer to respond according to RFC IE should do, that’s not an excuse to totally disable Cache. When visitors click on a link they expect something happens. Although AJAX makes the response time shrink, you don’t have any guarantee about the novelty of the content.

Sending the right headers

No, I am not talking about soccer. WordPress sends headers to prevent caching. I changed that because caching is not that bad. It’s all about sending the right headers and extending the intelligence in WordPress. The WordPress database keeps track of all date and times when the content changed. This is great, because now you can incorporate that date and time into the header. The second time the user asks for the content, the client send a If-modified-since in the request header with the date and time of the first response of the same content. If the content isn’t changed since, the response will be a HTTP 304 Not Modified (nothing more), the client will than get it out of the memory or the temporary Internet files.

Typically this saves a lot of bandwidth and latency.

Prefetching

The JavaScript on the client side tries to guess if you go to click on a link or not, just by measuring the time your mouse cursor is on the link, if it’s more than 0.2 seconds, it evaluates that chances are that you are eventually clicking on the link are big. So JavaScript starts fetching the page into memory.

In combination with the paragraph above, this gives a great performance boost. If the user doesn’t click on the link for now, it doesn’t matter because the next time the user might click on it, and on that point the JavaScript only have to collect a HTTP 304 Not Modified header (which is lesser than 300 bytes).

I really start wondering how to improve the response time after I concluded that it would be allot of work to convert this theme to a lightpress theme (I had to make a lot of plugins to get it to work).

So I started to think about other possibilities. The nice thing about lightpress was, it would only query the data in the database that was actually needed. So I tried to make an intelligent PHP frontend that only parses parts of the page that needs to change when you switch from page to page and gives it, wrapped in XML (because more than one part of the site need to change) to the JavaScript on the Client. The JavaScript on the client then parses the XML response and renders it in the DIVs on the website.

Needles to say, it saves a lot of bandwidth. My average page size did go from 15kb to 5kb (uncompressed, with ZLib compression, often not more than 1kb!). This has a lot of advantages, because it uses less processing and parsing time on the server and less download and render time on the client, and it looks nicer towards the user because the page doesn’t get refreshed. I The only overhead is the 4kb JavaScript, which is nothing compared to some other ajax JavaScript libraries.

Backwards compatible

Backwards compatibility was a key requirement for me. Since Google, MSN search, yahoo and other search spider bots don’t understand the the first thing about JavaScript or cookies. And, of course, the security nutheads (people that read security bulletins and don’t mitigate) that disables JavaScript because they think they are safer off. Ok I am going off topic, but think of it for a second. You are much, much, much better off (security and compatibility wise) by running Firefox of Opera as a limited user (right-click on the shortcut, run as), instead of disabling JavaScript in Internet Explorer!

JavaScript is responsible for turning the normal A HREF links to an ajax request in the background. This way it’s fully backwards compatible… Even if JavaScript works and even if the ajax request fails, It will switch to the old A HREF link.