uses-long-cache is too strict

The audit uses-long-cache is too restrictive as it basically requires a cache set to a value larger than 96.5 days to pass.

See https://github.com/GoogleChrome/lighthouse/blob/master/lighthouse-core/audits/byte-efficiency/uses-long-cache-ttl.js#L35

If instead the threshold was decreased to >= 90%. Then an asset cached for a week would be ok.

[paulirish]

1. lets see if we have any recent data on cache entry ages. it’s possible our 1yr guidance is wild and 1week is just find
2. docs should def mention suggested cache time. (also should link to stale-while-revalidate)
3. audit should give requests a pass if they use SWR

[patrickhulce]

Would you in that case consider having two thresholds, one for those assets with hash or version-id, and another lower threshold for the remaining assets.

That sounds reasonable though I’m not sure what we would ask of the remaining assets. Our thinking was "hey if this thing actually changes, you probably want to keep it up to a year but throw must-revalidate on there or something instead."The best retort I think we’ve heard so far to that was “we would ideally want must-revalidate but we’re OK with very slightly stale responses without a revalidation to save requests so we use 4 hours instead” The problem is there’s no real way for us to differentiate that case from the case of poorly chosen cache lifetimes. Hence, why I’m back to narrowing the scope of the audit instead.

Also, it’d be great if the page https://web.dev/uses-long-cache-ttl/ would be explicit about the suggested cache time.

Yeah docs should be updated either way no matter what we do here.