Re: dont-revalidate Cache-Control header

On Tue, Jul 14, 2015 at 5:19 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> On Jul 14, 2015, at 3:33 PM, Ilya Grigorik <igrigorik@gmail.com> wrote:
>
> 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.
>
>
> No, it would be managed in the CMS along with all of the other decisions
> that led to a static version. Sane folks don't manage their content in an
> optimization proxy.


Most every CDN has an FEO product that performs resource optimization
(minification, obfuscation, bundling, fingerprinting + cache extension, and
more). PageSpeed modules [1] alone, which I'm most familiar with myself,
power many hundreds of thousands of sites. Which is to say, "sane folks" do
deploy such tools and with great success.

[1] https://developers.google.com/speed/pagespeed/module/