0 reply content: the articles by Yubo and Ke Jun mainly address the question about the resource loading sequence. I will provide some answers to the questions. The order is generally:
1. Some special JavaScript codes, such as basic scripts used for debugging (not necessarily available during deployment) and Performance Logs, must be placed at the very beginning as far as possible.
2. External style sheet (link [rel = stylesheet])
3. style on this page)
4. Basic libraries, such as loader, various shim/polyfill, and jQuery
Note: Some developers tend to add defer or put it at the bottom of the page from the perspective of performance optimization. However, not all scripts can do this. For example, the html5-shim script must be loaded before the body. Another example is the compatibility Implementation of the history api, which should not be defer, because you cannot ensure that the user has no back/forward action before the page ready. Another example is jQuery and defer, but it also means that all the functions that depend on jQuery need defer. Considering that these static files are usually cached, therefore, not defer is not an acceptable compromise.
5. A small number of scripts on this page
Above. Followed by the guidance of @ ou lei, Zhang kejun's blog mentioned another in-depth article: http://lifesinger.wordpress.com/2012/02/03/performance-impact-of-js-css-loading-order/
------------------------ Due to http://wordpress.com
This website does not exist. The following content is fabricated through the Pocket (formerly ReadItLater) service. Please refer to the official self-identification -----------------------
Effect of JS and CSS locations on loading sequence of other resources
Ke Jun did a series of tests: the sequential relationship between js and css, and gave the phenomenon and conclusion, but did not give the reason.
The position of JS and CSS on the page affects the loading sequence of other resources (non-js and css resources such as img). There are three notable reasons:
- Javascript may modify the DOM.Typically, there may be document. write. This means that subsequent download of all resources may be unnecessary before the current JS loading and execution is complete. This is the root cause of JS blocking subsequent resource downloads.
- Javascript execution may depend on the latest style.For example, there may be var width = $ ('# id '). width (). this means that before JavaScript code is executed, the browser must ensure that all css (both external and embedded) before this JS Code has been downloaded and parsed. This is the root cause of CSS blocking subsequent JavaScript Execution.
- Modern browsers are smart and will optimize prefetch.Performance is so important. In the competition of modern browsers, in addition to the UI update thread, another thread will be enabled to download JS and CSS in advance (Note: Only download in advance, not executed ). With prefetch optimization, this means that in the absence of any blocking, theoretically, the download time of JS and CSS is very high and has nothing to do with the location.
The preceding three rules are briefly described as follows:
- Law 1: whether resources are downloaded depends on JS execution results.
- Law 2: javascript execution depends on the latest CSS rendering.
- Law 3: modern browsers have prefetch optimization.
With these three laws, let's take a look at KE Jun's test, which is very clear:
The external js appears in a and B-head. No matter how it is put, the css file cannot be in parallel with the request in the body.
According to Law 1 and Law 3, we can see that the above conclusions are not correct. For example:
