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