Using WebPageTest: Web Performance Testing for Novices and Power Users mentions “Network Silence” antipattern charaterized by an inverse relationship between CPU and bandwidth caused by a blocking process.
Found two examples of such scenarios - attached.
Does this mean that download of a resource (indicated by high bandwidth) can also cause blocking (although this does not seem to be the case always)? Is the browser thread busy downloading the resource and it cannot issue further request.
I thought that only (a) JS parse and execute resulted in parser blocking (b) JS parse and execute was dependent on CSSOM being ready?
Hi, I wrote that section and I’d be happy to elaborate.
For example, consider a search result page in which items are listed with some info and a picture. All result data is rendered client-side, meaning that the search results are embedded in a format like JSON with the initial HTML response. The JS execution of iterating over the JSON results could be computationally expensive for a number of reasons. Let’s say that there are hundreds of results to be rendered. Very bad idea, but not unheard of. The item pictures can’t start downloading until they’re added to the page. So maybe this fictional page builds up a document fragment off-DOM and finally adds all several hundred results in a massive appendChild statement. The browser doesn’t know about the images in that fragment until it’s in the DOM, so the loading is blocked by the JS. One of many ways to unblock it would be to append smaller fragments so images can download sooner.
So the network silence in this case is a result of bad application code hiding resources from the browser. This inefficiency manifests itself in the WPT results with the CPU being very highly utilized (100%) and the network underutilized (0%) – this is the inverse relationship you cited.
More broadly speaking, if you have resources in the critical path (things that need to download in order to render a usable page), then you should be making sure that everything starts and completes as soon as possible. Client-side rendering is one thing to be aware of that can impede the start of resource downloading.
Thanks a lot Rick for your response.
The book is very useful and contains important insights.
There appears to be two reasons for the high CPU utilization and low bandwidth use in WPT results - a) non availability of resources to request (as they are still being added) b) the complex processing.
Your book also gives a second scenario i.e. high network utilization but low cpu use. Does the downloading of any content (request 20 in the example) also lead to blocking at any stage of the download (request 71)?
I thought only the first JS/CSS request leads to blocking of the parser (during this time the nw use can be high). After that the parser may be blocked only if it has no work. Does this mean that in the example the silence may be due to no work for parser (as the resources are still hidden)? However the already requested content is being downloaded resulting in high nw use.
Sorry which example are you referring to?
pmeenan would also be a good person to answer specific questions about resource loading behavior.
My query referred to to Fig 2-19.