Issue link: https://read.uberflip.com/i/1146286
100 | Chapter 14: Rule 14: Make Ajax Cacheable When the user starts the Ajax version of Yahoo! Mail, it downloads the body of the user's first three email messages. This is a smart passive Ajax request. There's a good chance the user will click on one or more of these email messages, so having them already downloaded in the client means that the user sees her email messages with- out having to wait for any Ajax responses. If the user wants to view an email message that's not in the first three, an active Ajax request is made. The user is waiting for this response so she can read the email mes- sage. Let's look at the HTTP headers. GET /ws/mail/v1/formrpc?m=GetMessage[snip...] HTTP/1.1 Host: us.mg0.mail.yahoo.com Accept-Encoding: gzip,deflate HTTP/1.1 200 OK Date: Mon, 23 Apr 2007 23:22:57 GMT Cache-Control: no-store, private Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Type: text/xml; charset=UTF-8 Content-Encoding: gzip Connection: keep-alive Now imagine that the user leaves Yahoo! Mail to visit another web site. Later, she returns to Yahoo! Mail and again clicks on the fourth email message. Not surpris- ingly, the exact same request is sent again because the previous Ajax response was not saved in the browser's cache. It wasn't cached because the response contains a Cache-Control header with the value no-store, and an Expires header with a date in the past. Both of these tell the browser not to cache the response. And yet, if her inbox hasn't changed, the content is identical in both responses. If these headers were replaced with a far future Expires header (see Chapter 3) the response would be cached and read off disk, resulting in a faster user experience. This might seem counterintuitive to some developers—after all, this is a dynamically generated response that contains information relevant to only one user in the world. It doesn't seem to make sense to cache this data. The critical thing to remember is that this one user might make that request multiple times in a day or week. If you can make the response cacheable for her, it may make the difference between a slow user experience and a fast one. Making this Ajax response cacheable requires more work than simply changing the HTTP headers. The personalized and dynamic nature of the response has to be reflected in what's cached. The best way to do this is with query string parameters. For example, this response is valid only for the current user. This can be addressed by putting the username in the query string: /ws/mail/v1/formrpc?m=GetMessage&yid=steve_souders It's also important that the exact message is reflected. We wouldn't want to say &msg=4, because what's "fourth" in the inbox is constantly changing. Instead, a mes- sage ID that is unique across all messages for this user would solve the problem: