Resource timings API sometimes includes JavaScript eval of previous scripts for cached assets
Reported by
sam.saff...@gmail.com,
Oct 6 2016
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 Steps to reproduce the problem: Visit https://meta.discourse.org twice Look in network tab application js is correctly cached yet "Content Download" is 380ms What is the expected behavior? Cached assets should have "content download" of 0 or whatever the time is to fetch the data from the browser cache. What went wrong? It potentially includes eval time of previous scripts Did this work before? N/A Chrome version: 53.0.2785.116 Channel: n/a OS Version: OS X 10.12.0 Flash Version: Shockwave Flash 23.0 r0 script evaluation time is an important metric, but resource timings does not provide a clean way of digging at it, Firefox cleanly eliminates this from the equation. Current behaviour makes it very hard to interpret results of resource timings.
,
Oct 6 2016
This actually runs quite deep into the resource timings api... When resource is cached locally and served from local cache: connectEnd : 0 connectStart : 0 domainLookupEnd : 0 domainLookupStart : 0 duration : 102.95000000000002 entryType : "resource" fetchStart : 193.24500000000003 initiatorType : "script" name : "https://cdn-enterprise.discourse.org/docker/assets/application-e9fbecdbabe02bc165f936440a81e71ebc335c16ecb9f430d856760cdcbe5863.js" redirectEnd : 0 redirectStart : 0 requestStart : 0 responseEnd : 296.19500000000005 responseStart : 0 secureConnectionStart : 0 startTime : 193.24500000000003 workerStart : 0 When resource is uncached and fetched from network: connectEnd : 0 connectStart : 0 domainLookupEnd : 0 domainLookupStart : 0 duration : 1380.585 entryType : "resource" fetchStart : 842.705 initiatorType : "script" name : "https://cdn-enterprise.discourse.org/docker/assets/application-e9fbecdbabe02bc165f936440a81e71ebc335c16ecb9f430d856760cdcbe5863.js" redirectEnd : 0 redirectStart : 0 requestStart : 0 responseEnd : 2223.29 responseStart : 0 secureConnectionStart : 0 startTime : 842.705 workerStart : 0 So when implementing resource timing metrics we are stuck with no way of telling if a resource was cached locally or not, neither is there any way of properly deciphering network cost.
,
Oct 6 2016
I guess some of this will be much more workable once https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/transferSize is implemented :(
,
Oct 6 2016
> So when implementing resource timing metrics we are stuck with no way of telling if a resource was cached locally or not, neither is there any way of properly deciphering network cost. This seems orthogonal to the original bug...? That said, RT size attributes are shipping in M54: https://www.chromestatus.com/feature/6549060404117504
,
Oct 10 2016
,
Dec 1 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by igrigo...@chromium.org
, Oct 6 2016