Issue link: https://read.uberflip.com/i/1146286
102 | Chapter 14: Rule 14: Make Ajax Cacheable If the user closes the spreadsheet and reopens it, 10 requests are made again. That's because none of the requests is cacheable. Most of the requests are fairly small, but one of the HTML requests is 47K (before compression). Let's look at the HTTP headers for that request. GET /ar?id=[snip...]&srow=0&erow=100 HTTP/1.1 Host: spreadsheets.google.com Accept-Encoding: gzip,deflate HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Cache-Control: private Content-Encoding: gzip Date: Tue, 24 Apr 2007 23:37:13 GMT Again, it's no surprise that the Ajax request is made every time the user opens the spreadsheet. The response does not have a header telling the browser to cache it. In my test, I wasn't modifying the spreadsheet, so this response was identical every time I opened my spreadsheet. In fact, 8 of the 10 requests were identical, so it raises the question of whether they could have been cached. Just as in the Yahoo! Mail example, caching the spreadsheet is not as easy as adding a far future Expires header. If the user modifies the spreadsheet, we need to ensure that cached requests affected by the changes aren't reused. Again, a simple solution is to use the query string. The Google Spreadsheets backend could save a timestamp representing when the last modifications were made, and embed this in the query string of the Ajax requests: /ar?id=[snip...]&srow=0&erow=100&t=1177458941 Although the Ajax requests aren't cacheable, other performance guidelines are imple- mented successfully. The response is gzipped (Rule 4). As with most Google sites, domain lookups are minimized (Rule 9). The scripts are minified (Rule 10). It doesn't use redirects (Rule 11). And the ETags are removed (Rule 13). Make sure your Ajax requests follow the performance guidelines, especially having a far future Expires header.