Before we discuss this topic, let's look at another problem with scripting optimizations, which is "optimization difficulty." What I call "optimization difficulty" here refers to the difficulty of modifying a page when it is optimized. For example, in the previous article, using document.write to introduce the script, its "optimization difficulty" would be very low-no side effects, no need to modify any other code. But its effect does not seem to be ideal, because only to optimize the experience of IE, in Firefox but no effect.
Unfortunately, I recall almost all of the optimization methods, no longer find the optimization of such a low degree of practice. For other ways, we have to make changes elsewhere in the page, the better the optimization effect, the greater the amount of modification. For these optimizations, we have to write the appropriate components and encapsulate some of the logic. This can be to a certain extent convenient to use, reduce the difficulty of optimization.
Comparison of Document.Write and defer
So what does document.write or defer have to do with it? And listen to me slowly.
The defer attribute of the <script/> is defined in the standard as follows:
When set, this boolean provides a hint to the user agent that's the script is not going to generate any document C Ontent (e.g., no "document.write" in JavaScript) and thus, the user agent can continue parsing and rendering.
The reason we encountered JS could not be downloaded in parallel was that the browser thought that HTML content might be exported in the script. The function of the defer property is to tell the browser that no information will be printed in the script. Sure enough, when we use the defer attribute in IE, the script is not blocked, and the effect is the same as document.write. But still not in Firefox, such a realization is really confusing.
All say the Firefox standard, it seems not in detail.
So why did we use the document.write instead of the defer attribute before? The two effects are the same, but obviously using the defer property is more intuitive.
Defer properties are intuitive and convenient to use. But is the effect really the same? We can try the following examples.
document.write
<title> Untitled Page</title>
<script type= "Text/javascript" language= "JavaScript"
document.write (
' <script type= ' text/javascript ' language= ' javascript ' +
' src= ' scripts.ashx?a ' >< ' + '/script> ;');
document.write (
' <script type= ' text/javascript ' language= ' javascript ' +
' src= ' scripts.as Hx?b ">< ' + '/script> ');
document.write (
' <script type= ' text/javascript ' language= ' javascript ' +
' src= ' scripts.as Hx?c ">< ' + '/script> ');
</script>
<body>
<input type= "button" value= "click"/>
<scri PT type= "Text/javascript" language= "JavaScript" src= "Scripts.ashx?a"
Alert (' Hello world ');
</script>
</body>
Then use the <script defer= "defer" method to introduce the ></script>. Opening two pages to compare will find that if you use document.write, the button will not appear before the script is loaded, and no prompt will appear, and if you use the Defer property, the button appears immediately and prompts immediately.
That's a problem. If the elements on the page appear prematurely, does the user have a problem with the script before it finishes loading? If there is a script that executes directly on the page (such as the alert call in the previous example), can it be executed before the script file is loaded? If any of the answers to the above two questions is positive, then congratulations, using the defer attribute can cause errors. And the solution to this problem is not easy to find, which greatly increases the "difficulty of optimization."
And even more crucially, Firefox does not support the defer attribute's effect. This leads directly to the defer attribute's overall lag behind the use of document.write optimization method. In that case, why should we use it? In fact, the defer attribute is not much used, this is a very typical "chicken" characteristics.
So, where is the use of the defer attribute application? I think it should be, although I do not know.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
