WebPagetest Forums

Full Version: JavaScript Blocking
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi,

I am just testing some JavaScript blocking stuff and in the case I understand the theory about JavaScript blocking the right way, I am a little bit confused about the following Waterfall view:

[Image: waterfall1.png]

In my opinion the request for the JavaScript file (number 3, no defer, no async) should be placed as request number 5 because of:
  • The JavaScript file is blocking parallel downloads and the Waterfall View give the impression that this is not the case because it shows request number 4+5 after the request for the JavaScript file (number 3)
  • Request number 4 and 5 are originally placed first in the HTML file and then comes the script (number 3).

Do I understand this view in a wrong way and can anyone explain me this behaviour?
Ok, I found the underlying problem: I had old information about the JavaScript blocking. New browsers are able to download also scripts in parallel. This doesn't solve the blocking problem but improves the page load time. All the other elements (request 6-7) still have to wait until all the scripts are downloaded and executed.

But what about the request 4? Why isn't the request blocked by the javascript requests?
What browser? Usually they wait until after the onload event before downloading the favicon but it's possible that one of them doesn't.
(06-20-2014 10:32 PM)pmeenan Wrote: [ -> ]What browser? Usually they wait until after the onload event before downloading the favicon but it's possible that one of them doesn't.

It's Firefox on Falkenstein, Germany test location. Can you also give me a short explanation why the order in the waterfall view is different from the order in the html file?
All of the browsers have a preload scanner that scans ahead in the document for resources that they are going to need and then it's up to the browser to figure out what order it wants to download them in.

Chrome for example:
- Loads all non-async JS and external CSS that it can find before anything else
- Prioritizes images that are laid out and visible in the viewport (once the main thread gets to layout)

IE 7 was the last browser that actually requested resources as they were processed - it was a HUGE performance win for the browsers to fetch the resources with the preload scanner. It still executes script and does layout in the order defined in the HTML as it is parsed, it's just the network fetching that they try to optimize to have the resources ready when they are going to be needed.
Awesome answer! Thanks Pat!
Reference URL's