We will want to be able to preload non-cacheable objects, so it might be
clearer to explicitly have a used flag.
David
On Tue, Aug 26, 2014 at 3:29 PM, Ilya Grigorik <igrigorik@google.com> wrote:
>
> On Sun, Aug 24, 2014 at 9:06 PM, Nottingham, Mark <mnotting@akamai.com>
> wrote:
>
>> FWIW - I've brought this up a number of times, IIRC on-list as well as
>> privately with various folks.
>>
>> AIUI implementers remain unconvinced of the value here -- at least enough
>> to overcome the privacy concerns (which IMO are fairly minimal, but if you
>> don't see the value in something, why take the risk?).
>>
>> Maybe it's time to have the conversation again. I have a proposal that I
>> can dust off...
>>
>
> We're exposing resource "age" via Resource-Freshness [1]... It seems
> reasonable to make same data available on the client via Resource/Nav
> Timing. In fact, wondering if "age" attribute could do the trick:
>
> r = performance.getEntriesByName('https://www.example.com/resource');
> r.age # nil = resource is not cacheable by HTTP cache (e.g. no-cache,
> no-store, etc)
> r.age # 0 = resource was just placed in HTTP cache
> r.age # 1+ = resource was fetched from HTTP cache, and its age is...
>
> For {nil, 0}, you'd know that a request was made, whereas 1+ indicates
> that request was served from local HTTP cache.
>
> The one complication I can see here is interaction with ServiceWorker..
> since SW could have intercepted the request and synthesized the response on
> its own, or served it from own cache. It's not clear to me how and if that
> should be communicated via Resource/NavTiming.
>
> ig
>
> [1]
> https://github.com/KenjiBaheux/resource-freshness/blob/master/specification.txt#L53
>
Received on Tuesday, 26 August 2014 19:59:09 UTC