dont-revalidate Cache-Control header

It is considered a best practice for websites to use "long caching" for
serving images, javascript and CSS. In long cacing if a website has a
resource X.js which might change from time to time, rather than referencing
X.js and giving the endpoint a short expiration date, they reference
X-v1.js with a nearly infinite expiration date. When X.js changes, the
website uploads X-v2.js and changes any references to use the new version.
This has the benefit that the browser never needs to revalidate resources
and that it sees changes instantly. [1]

At Facebook, we use this method to serve our static resources. However
we've noticed that despite our nearly infinite expiration dates we see
10-20% of requests (depending on browser) for static resource being
conditional revalidation. We believe this happens because UAs perform
revalidation of requests if a user refreshes the page. Our statistics show
that about 2% of navigations to FB are reloads -- however these requests
cause a disproportionate amount of traffic to our static resources because
they are never served by the user's cache.

A user who refreshes their Facebook page isn't looking for new versions of
our Javascript. Really they want updated content from our site. However UAs
refresh all subresoruces of a page when the user refreshes a web page. This
is designed to serve cases such as a weather site that says <img
src="/weather.php?zip=94025">. If that site had a 10 minute expiration on
the image, the user might be able to refresh the page and get more up to
date weather.

10-20% additional requests is a huge impact for a site's performance. When
a user presses refresh, they want to quickly see the latest updates on the
site they are on. Revalidating all resources on the site is a substantial
drain. In discussing this with Ilya Grigorik from the Chrome team, one
suggestion that came up was an explicit cache control option to tell UAs
not to revalidate. The proposed header would be Cache-Control:
dont-revalidate

This header would tell a UA that the resource in question is unquestionably
valid until it's expiration time. A UA MUST NOT send a conditional request
for a resource with a dont-revalidate header prior to the resource's
expiration. In most cases the UA SHOULD simply treat the resource as valid.
If the UA is not willing to treat the resource as valid, it should send a
full request with no revalidation. The UA MAY do this in cases where the
user has explicitly requested to use a clean cache -- for example a refresh
via ctrl+shift+r, or using developer tooling. Such functionality SHOULD be
targeted at advanced users rather than the average user.

Without an additional header, web sites are unable to control UA's behavior
when the user uses the refresh button. UA's are rightfully hesitant in any
solution that alters the long standing semantics of the refresh button (for
example, not refreshing subresources).

[1]
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#invalidating-and-updating-cached-responses