- From: Ilya Grigorik <igrigorik@gmail.com>
- Date: Tue, 14 Jul 2015 15:33:11 -0700
- To: Ben Maurer <ben.maurer@gmail.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAKRe7JFKEsUMaG40=yt5p=3hdXUBf-dVGaUV6fcA2N1wBwGkfw@mail.gmail.com>
On Tue, Jul 14, 2015 at 3:03 AM, Ben Maurer <ben.maurer@gmail.com> wrote: > That said, this doesn't feel like a great thing for us to promote as a web > performance best practice. "If you use long cache lifetimes for your static > content, the dont-revalidate cache control header will reduce the cost of > client reloads" seems like a piece of advice folks might take, as would > "Use the <meta> tag 'dont-reload-non-expired-resources' to avoid browsers > revalidating your content when the user presses reload". On the other hand > "you should find every image, script, stylesheet, etc and set the fetch > option on each to say force-cached" feels more tedious and unlikely to be > used. > To this point, the HTTP mechanism is something that FEO / optimization proxies can do on your behalf - e.g. rewrite and/or bundle resources, add version fingerprint, append the HTTP header we're discussing here. By comparison, rewriting markup (HTML, CSS, JS) is significantly harder and very expensive. Which is to say.. +1 for HTTP directive over markup. On Tue, Jul 14, 2015 at 5:36 AM, Ben Maurer <ben.maurer@gmail.com> wrote: > > > On Tue, Jul 14, 2015 at 1:01 PM, Mark Nottingham <mnot@mnot.net> wrote: > >> From time to time, we've had people ask for "Cache-Control: >> Infinity-I-really-will-never-change-this." I suspect that often they don't >> understand how caches work, and that assigning a one-year lifetime is more >> than adequate for this purpose, but nevertheless, we could define that so >> that it worked and gave you the semantics you want too. >> >> To keep it backwards compatible, you'd need something like: >> >> Cache-Control: max-age=31536000, static >> >> (or whatever we call it) >> > > Static is a fairly reasonable name. Static does imply that the resource > will *never* be revalidated (ever) vs the dont-reload which implies no > revalidations prior to expiration. I don't have any preferences between the > two but wanted to call that out. > > What's the next step here? >
Received on Tuesday, 14 July 2015 22:34:18 UTC