Re: [Resource Timing] Definition of "network layer cache"

I've updated the spec to remove references to "networking layer cache" and
specify the behavior listed by James.

Arvind


On Mon, Apr 15, 2013 at 10:13 AM, Jatinder Mann <jmann@microsoft.com> wrote:

>  Seeing that the “fetch” concept is well defined, I rather we not try to
> define the various internal browser caches in an attempt to define the
> “networking layer”. I like the idea of updating the processing model to our
> expected behavior. I’ll update the spec.****
>
> ** **
>
> Thanks,****
>
> Jatinder****
>
> ** **
>
> *From:* Nic Jansma [mailto:nic@nicj.net]
> *Sent:* Friday, April 12, 2013 6:41 PM
> *To:* James Simonsen
> *Cc:* public-web-perf
> *Subject:* Re: [Resource Timing] Definition of "network layer cache"****
>
> ** **
>
> Awesome, that's a great simplification -- it describes what we were
> originally intending.  i.e. what one would see in Firebug/F12/DevTools.
>
> ****
>
> - Nic****
>
> http://nicj.net/****
>
> @NicJ****
>
> On 4/12/2013 8:20 PM, James Simonsen wrote:****
>
>  I agree that seems like the desired behavior and that we need to say
> that more clearly. ****
>
> ** **
>
> Should we totally change the processing model? For instance:****
>
> ** **
>
> 1. If the resource is fetched from the network, log it.****
>
> ** **
>
> 2. If it's fetched from a local cache, and the resource hasn't been seen
> before, log it and record it in a "set of seen resources."****
>
> ** **
>
> 3. If it's fetched from a local cache, and the resource is already in the
> "set of seen resources," abort these steps.****
>
> ** **
>
> Obviously, I wouldn't expect anyone to actually implement that set, but it
> at least makes the processing model convey what we want.****
>
> ** **
>
> James****
>
> ** **
>
> On Fri, Apr 12, 2013 at 4:53 PM, Nic Jansma <nic@nicj.net> wrote:****
>
>  I seem to remember "networking layer cache" being somewhat intentionally
> left vague, as we figured different UAs would have various caches and we
> didn't want to pigeon hole what it meant.
>
> Outside of what the phrase "networking layer cache" means, the intent was
> to include all resources included in the page, regardless of whether a
> request went out over the network to get them.  In this case, site.js is
> included statically in webpagetest.org's HTML:
>
> <script type="text/javascript" src="
> http://cdn.webpagetest.org/js/site.js?v=28"></script>
>
> I would expect/hope site.js would be included as a PerformanceEntry in the
> PerformanceTimeline, even if it was "cached" from the previous page load.
> It's load time would be near 0, since it was loaded from whatever caches
> the UA has.
>
> The wording around "networking layer cache" could certainly be better
> explained, but I'm not sure how...
>
> ****
>
> - Nic****
>
> http://nicj.net/****
>
> @NicJ****
>
>  On 4/12/2013 6:54 PM, William Chan (陈智昌) wrote:****
>
>  I think "network layer cache" should be redefined in such a way to make
> Blink's behavior incompliant. The Blink memory cache is just another cache
> in the cache hierarchy.****
>
> ** **
>
> On Fri, Apr 12, 2013 at 3:40 PM, James Simonsen <simonjam@google.com>
> wrote:****
>
>  The Resource Timing spec says: ****
>
> ** **
>
> "Resources that are retrieved from the user agent's networking layer cache
> must be included as PerformanceResourceTiming objects in the Performance
> Timeline."****
>
> ** **
>
> What exactly constitutes a "networking layer cache?" Blink's memory cache
> seems to behave differently than IE10's. When navigating pages on the same
> site, Blink uses the "in-memory cache" and reuses subresources without
> fetching. That means we don't report Resource Timing for these resources.
> IE10 seems to always report resources in the same circumstances.****
>
> ** **
>
> To try it out, visit webpagetest.org. Note the "site.js loaded in x
> milliseconds" at the bottom of the page. Browse to the "About" page on
> webpagetest.org. That message disappears on Chrome, it shows a new value
> on IE10.****
>
> ** **
>
> Are we both compliant in our own ways? Or do we need to better define
> "network layer cache?"****
>
> ** **
>
> James****
>
>  ** **
>
> ** **
>
>  ** **
>
> ** **
>