- From: Nic Jansma <nic@nicj.net>
- Date: Fri, 12 Apr 2013 21:40:51 -0400
- To: James Simonsen <simonjam@google.com>
- CC: public-web-perf <public-web-perf@w3.org>
- Message-ID: <5168B7A3.3040600@nicj.net>
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 Saturday, 13 April 2013 01:39:46 UTC