DevTools>Network visualises time until downloaded CSS file is applied to document as "Content Download"
Reported by
m.beutlb...@sap.com,
Oct 24 2017
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36 Steps to reproduce the problem: 1. New tab 2. Inspect 3. Switch to Network, check Disable cache 4. Navigate to http://jsbin.com/jutihetuyu/1 5. Observe how the file "library.css" has a total time of about one second and a Content Download time of about 990ms 6. Redo steps 1. to 3. 7. Navigate to http://jsbin.com/xomajoyobu/1 6. Observe how the file "library.css" now has a total time of 10-20ms and a Content Download time of about 1ms Editor for "Slow" example: http://jsbin.com/jutihetuyu/1/edit?html,js (this example starts loading the CSS file and then blocks the main thread for one second) Editor for "Fast" example: http://jsbin.com/xomajoyobu/1/edit?html,js (this example starts loading the CSS file, waits for it to finish (hopefully doesn't take longer than 100ms) and then blocks the main thread for one second) Tested on: Windows 10, Chrome 62.0.3202.62 (32-bit, stable) OS X 10.12.6, Chrome 62.0.3202.62 (64-bit, beta) What is the expected behavior? As an application developer, I expect the Content Download time to reflect the time it took to download a files content. Not the time it took to apply it to the document (which it appears to be in this case). Otherwise a developer might think that loading a particular file is having a tremendous impact on an applications startup time. Even though it does not. From the documentation: The "Time" column is decribed as "The total duration, from the start of the request to the receipt of the final byte in the response": https://developers.google.com/web/tools/chrome-devtools/network-performance/reference#requests The "Content Download" phase is described as "The browser is receiving the response": https://developers.google.com/web/tools/chrome-devtools/network-performance/reference#timing-explanation What went wrong? What we observed: It looks like the Content Download time increases if synchronous (i.e. blocking) tasks are running in the main JS thread at the time the CSS file finishes downloading. In the scenario where we observed this first, there are multiple synchronous requests and tasks blocking the main thread for several seconds. Note that because of this, you can also see an increased Content Download time when loading the CSS file from *disk* cache while blocking the main thread (see attachment "From cache", I did not observe that when loading from memory cache). Also, in the scenario above, the "Finished" time in the summary pane at the bottom of the network panel is increasing by the same amount (see attachments "Fast" and "Slow"). When changing the view to "Use large request rows". The second row seems to display the overall time, minus the Content Download time. I could not find documentation about this number. Did this work before? N/A Chrome version: 62.0.3202.62 Channel: stable OS Version: 10.0 Flash Version:
,
Oct 25 2017
Unable to reproduce this issue on reported version 62.0.3202.62 and on latest canary 64.0.3248.0 using Windows 10 with steps mentioned below. Attaching screenshots for reference. 1.Opened New tab >> Opened Devtools Network Tab >> checked Disable cache 2.Navigated to Slow JSfiddle and observed Total time of 891 ms and content download time of 3.61 ms 3.Navigated to Fast JSfiddle and observed Total time of 43 ms and content download time of 0.97 ms @Reporter: Please check the above steps/screenshots and let us know whether we are missing any steps as we are seeing deviation from given screenshots. Your Inputs helps in further triaging of the issue Thanks!
,
Oct 25 2017
Apparently my anonymous JS Bin links expired and redirected to the editor where the issue can not be reproduced. I was not aware of that JS Bin restriction, sorry for the inconvenience. Please try again with the following links: Slow: http://jsfiddle.net/RandomByte/br8m3wx2/ Fast: http://jsfiddle.net/RandomByte/h2omfyzp/ Thanks!
,
Oct 25 2017
Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 25 2017
Seems to be the same issue as https://bugs.chromium.org/p/chromium/issues/detail?id=778102
,
Oct 25 2017
,
Oct 25 2017
Issue 778103 has been merged into this issue.
,
Oct 25 2017
Issue 778102 has been merged into this issue.
,
Oct 26 2017
We have retried the scenario as per the URL provided in C#3, unable to reproduce this issue on reported version 62.0.3202.62 and on latest canary 64.0.3248.0 using Win 10 @Reporter: we are still seeing deviation from given screenshots, could you please let us know if we have missed any steps in reproducing the issue from TE-end Attaching screenshot for your perusal
,
Oct 26 2017
The issue is already visible in your attachment "Library_CSS_Slow.PNG". The "Content Download" time is displayed as "952.13ms". Which is ~900ms more than in your second screenshot. The high number leads developers to think that something's wrong with the connection or the server causing the file to "download" for so long. While actually the difference is in the application code (see my initial "What went wrong?" description).
,
Oct 26 2017
Thank you for providing more feedback. Adding requester "divya.padigela@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 30 2017
,
Oct 30 2017
,
Dec 13 2017
,
Oct 12
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by manoranj...@chromium.org
, Oct 24 2017