W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2013

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

From: Jatinder Mann <jmann@microsoft.com>
Date: Mon, 15 Apr 2013 17:13:05 +0000
To: Nic Jansma <nic@nicj.net>, James Simonsen <simonjam@google.com>
CC: public-web-perf <public-web-perf@w3.org>
Message-ID: <2095865be36a433cbd097ec8e26d5580@BLUPR03MB065.namprd03.prod.outlook.com>
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<mailto: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<http://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<mailto: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<http://webpagetest.org>. Note the "site.js loaded in x milliseconds" at the bottom of the page. Browse to the "About" page on webpagetest.org<http://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




Received on Monday, 15 April 2013 17:14:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:35 UTC