Hmmm, now I'm really confused. When I look at the response headers for the files I don't see any expiration dates, e.g. *static/base.css* has only the following
Date: Thu, 16 Sep 2010 13:06:46 GMT ETag: "Eme4QA" Server: Google Frontend Whereas *jquery.min.js*, which is served from the Google CDN has Date: Thu, 16 Sep 2010 13:05:28 GMT Expires: Fri, 16 Sep 2011 13:05:28 GMT Server: GFE/2.0 http://code.google.com/speed/page-speed/docs/caching.html says: """ *HTTP/1.1 provides the following caching response headers : Expires and Cache-Control: max-age. These specify the “freshness lifetime” of a resource, that is, the time period during which the browser can use the cached resource without checking to see if a new version is available from the web server. They are "strong caching headers" that apply unconditionally; that is, once they're set and the resource is downloaded, the browser will not issue any GET requests for the resource until the expiry date or maximum age is reached. Last-Modified and ETag. These specify some characteristic about the resource that the browser checks to determine if the files are the same. In the Last-Modified header, this is always a date. In the ETag header, this can be any value that uniquely identifies a resource (file versions or content hashes are typical). Last-Modified is a "weak" caching header in that the browser applies a heuristic to determine whether to fetch the item from cache or not. (The heuristics are different among different browsers.) However, these headers allow the browser to efficiently update its cached resources by issuing conditional GET requests when the user explicitly reloads the page. Conditional GETs don't return the full response unless the resource has changed at the server, and thus have lower latency than full GETs. It is important to specify one of Expires or Cache-Control max-age, and one of Last-Modified or ETag, for all cacheable resources. It is redundant to specify both Expires and Cache-Control: max-age, or to specify both Last-Modified and ETag. * """ I read this as saying the ETag may be doing some good, but it would be very desirable to also set an explicit expiration date on my static files. If that's the case, do I need to add something else to app.yaml or is there a directive I need to set in my views or what? Or am I totally misunderstanding the issue (always a possibility)? On Wed, Sep 15, 2010 at 11:58 PM, Chris S <sanders.ch...@gmail.com> wrote: > > I'm sorry I just re-read your post. > > If the three files I listed as no-cached are not in static they are > not being cached as expected. The app.yaml by default tells the GAE > server to server from the /static folder directly with a 90-day cache. > > On Sep 15, 10:56 pm, Chris S <sanders.ch...@gmail.com> wrote: > > I checked and noticed the following files as having no expiration > > date. > > jquery-ui.css > > groups_logo_sm.gif > > rpx.js > > > > These files have a date and are set to 90-days, chrome is suggesting a > > year. > > base.css > > calendar.css > > ptjq.pkg.js > > peertool.js > > background.gif > > header.gif > > menu.gif > > question32.png > > agplv3-88x31.png > > If you want to change the date on these to a year just change "90d" to > > "1y" or any other time period you would like. > > > > The missing expiration date on the first three files is interesting > > though. > > I checked with firebug and indeed they have no expiration date, though > > reloading the page in firefox is not downloading any of those files > > that might not be true for all browsers. > > Are you possibly serving some of those files as URL references from > > the style sheet? > > Are any of those files *not* served from the /static folder? > > > > On Sep 14, 3:43 pm, Michael Ellis <michael.f.el...@gmail.com> wrote: > > > > > > > > > When I analyze the network performance of my GAE hosted application, http://peertool.appspot.com with Chrome Dev Tools Audit, the top > > > listed suggestion for improvement is "Leverage browser caching", viz. > > > > > """ > > > The following resources are missing a cache expiration. Resources that > > > do not specify an expiration may not be cached by browsers: > > > jquery-ui.css > > > base.css > > > calendar.css > > > ptjq.pkg.js > > > peertool.js > > > background.gif > > > groups_logo_sm.gif > > > rpx.js > > > header.gif > > > menu.gif > > > question32.png > > > agplv3-88x31.png > > > """ > > > > > Most, but not all, of these are served from the static/ directory. > > > > > I checked app.yaml and found that it has the settings recommended in > > > an earlier thread on this group: > > > > > """ > > > - url: /(?P<a>.+?)/static/(?P<b>.+) > > > static_files: applications/\1/static/\2 > > > upload: applications/(.+?)/static/(.+) > > > secure: optional > > > expiration: "90d" > > > """ > > > > > I'm using web2py version 1.84.0 (2010-08-28 09:58:51) > > > > > Is there something more I need to do? > > > > > Thanks, > > > Mike
