Google是否使用“推迟”错误的方法？ [英] Is Google using "defer" the wrong way?

问题描述

请参阅： https://developers.google.com/maps/documentation/javascript / b>

  < script src =https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMapasync defer>< / script> 
< / body> 
< / html> 
  

我的问题是谷歌为什么使用延期的原因，因为在我看来，它并没有做任何事情

让我们来比较一下（1）：

 < script src =script.jsdefer>< / script> 
< / body> 
< / html> 
  

有了这个（2）：

 < script src =script.js>< / script> 
< / body> 
< / html> 
  

唯一的区别是，在执行script.js的情况下：（1）请确保body标签的结尾和html标签的结尾尚未在DOM中。在（1）这些标签已经在DOM中的情况下，执行script.js时。
但body / html标签的结尾不会改变屏幕上的任何内容（渲染），因此这些标签实际上对渲染没有影响。所以理论上这两个例子之间有一点点区别，但实际上没有任何区别。

那么使用defer的原因是什么？让我们回顾历史。如果您在旧版浏览器中使用：

 < script src =script.js>< / script> 
< / body> 
< / html> 
  

问题在于您没有预加载扫描仪。他们可以扫描文档（并行），搜索下载以开始。一个旧的浏览器会首次看到script.js，这时HTML解析器将会到达文档的那一部分。开始下载和浪费时间已经很晚了。这就是为什么他们想出了延迟的原因，所以你可以把脚本标签放在文档的开头，但是当html解析器和整个文档一起完成时执行就会发生（所以它不会阻塞html解析器）。对于较新的浏览器，延迟无论如何都不合理，因为您可以在页面结束前使用同步脚本标记。 预加载扫描仪几乎立即开始下载。因为你把它放在文档的末尾，脚本的执行不会阻塞html解析器（exext end body / html，但这些标签无论如何都不会影响渲染）。

b
$ b

因此，延期只是为旧版浏览器增加了一些功能，因为在较新的浏览器中，您可以在文档末尾使用同步脚本标签。

但是，如果您将脚本标签放置在文档的开头而不是文档的末尾，旧版浏览器中的延迟才有意义。如果您在文档的末尾放置推迟，那么无论如何，浏览器必须等待很长时间才能开始下载。

所以我在说什么是：延迟在实践中没有什么区别，只要在文档结束之前将它放在脚本标记上即可。如果你将它放在文档开始处的脚本标签上，这只会是有意义的。

因此，Google对我的看法并不了解其含义推迟，因为他们为什么要加上它？它没有做任何事情。或者这是对我的错误想法？

这是我的一些更多的问题/帖子，无论如何，我仍然怀疑Google对渲染和使用延迟/异步等等：

Google错了推迟？

外部阻止脚本强制浏览器等待，然后可以呈现页面？

后果javascript可以ve document.write in the code？

动态创建的脚本不会阻止呈现？

通过异步脚本标记在网页末尾加载外部javascript a>

这就是为什么我想检查Google如何制作自己的脚本，并且在一次Google搜索之后，我发现这个例子，对于我来说看起来奇怪的使用推迟。

无论如何，可能有一个使用它的理由，但谷歌并不清楚给出正确的理由。在文档中，Google正在讲述这个故事，我在这个帖子/问题中告诉你。但是，这是没有理由使用推迟这样的。

我知道不同的浏览器对待延迟的方式不同，所以也许这就是Google使用它的原因。但是他们的文件并没有给出正确的理由。然后我的问题是，究竟是什么原因？

所以谁知道更多关于这个？或推迟真的没有在谷歌的脚本？

解决方案

我一直在想它，我会给它一个回答我自己的问题;）。可能谷歌认为人们会复制/粘贴此代码：

 < script src =https：//maps.googleapis .com / maps / api / js？key = YOUR_API_KEY& callback = initMapasync defer>< / script> 
  

...只需将其添加到页面的某个位置即可。所以在这种情况下，推迟是有道理的。

实际上，如果您在文档的末尾有1个脚本标记，并且您使用的是异步在它上面，这也没有意义。但是，如果脚本标签不在文档的末尾，这是有道理的。

但是，如果我是谷歌，我会反正添加一些关于它的注释，因为如果你是一家大公司，人们正在检查例子并重视它。我自己知道网站管理员，他们只是在文档的末尾添加异步/推迟到脚本标记，而它是唯一的。你可以这样想：但它没有做任何事，所以它有什么问题？例如，异步可以在执行JavaScipt之前添加一些额外的延迟（与同步相比）。所以在这种情况下，使用页面速度同步而不是脚本标签上的异步会更好。

See: https://developers.google.com/maps/documentation/javascript/tutorial

Google is using here:

<script src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMap" async defer></script>
</body>
</html>

My question is why Google is using "defer", because in my opinion it does not do anything in the script of them above?

Let's compare this (1):

<script src="script.js" defer></script>
</body>
</html>

With this (2):

<script src="script.js"></script>
</body>
</html>

The only difference is that when executing "script.js" in case: (1), you will be sure that the "end of the body tag" and "end of the html tag" are not yet in the DOM. In case (1) those tags are already in the DOM, when executing "script.js". But the end of the body / html tag will not change anything on your screen (rendering), so those tags are having actually no influence on "rendering". So theoretically there is a small difference between those 2 examples, but in practise there is no difference at all.

So what could be the reason to use defer? Let's go back in history. If you would use in old browsers:

<script src="script.js"></script>
</body>
</html>

The problems was that you did not have "preload scanners". They can scan the document (in parallel), searching for downloads to start already. An old browser would see "script.js" for the first time, when the "HTML parser" would reach that part of the document. That's pretty late to start the download and a waste of time. That's why they came up with "defer", so you could place the script tag at the beginning of the document, but the execution would take place when the html parser would be done with the whole document (so it would not block the html parser).

For newer browsers "defer" would not make sense anyway, because you could just use a "sync script tag", just before the end of the page. The "preload scanner" will start the download almost immediately. And because you are placing it at the end of the document, the execution of the script, will not block the html parser (execept end body / html, but those tags, will anyway have no influence on rendering).

So "defer" is only adding some functionality to older browsers, because in newer browsers you could just use the "sync script tag" at the end of the document.

But defer in older browsers would only make sense if you place the script tag at the beginning of the document and not at the end of the document. If you place "defer" at the end of the document, then anyway the browser has to wait a long time before it can start downloading.

So what i'm saying is: "defer" makes no difference in practise when you will put it on a script tag just before the end of the document. It would only make sense if you would put it on a script tag at the beginning of the document.

So it looks like to me that Google does not really understand the meaning of "defer", because why they would add it? It's not doing anything. Or is that wrong thinking of me?

This are some more questions / posts of me where i have my doubts anyway about what Google is saying about rendering and using defer / async et cetera:

Google is wrong about defer?

Why a browser is not always finishing rendering of the preceding HTML, before executing javascript?

External blocking scripts force the browser to wait, before the page can be rendered?

Consequences javascript can have document.write in the code?

Scripts that are dynamically created don't block rendering?

Loading external javascript via async script tag at the end of a webpage

That's why i wanted to check how Google is making their own scripts and after one Google search i found already this example, with for me strange looking use of "defer".

Anyway there could be a reason to use it, but Google is not clear with giving the right reason. In documentation, Google is telling the story, i was telling you in this post / question. But that's no reason to use "defer" like that.

I know that different browsers treating "defer" differently, so maybe that's why Google is using it. But then their documentation is not giving the right reasons. And then my question is what that reason exactly is?

So who knows more about this? Or "defer" is really there for nothing in the script of Google?

解决方案

I've been thinking about it and i will give it a shot to answer my own question ;). Probably Google is thinking that people will copy / paste this code:

<script src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMap" async defer></script>

... and just add it somewhere on the page. So in a case like that, "defer" would make sense.

Actually if you have 1 script tag at the end of the document, and you are using "async" on it, it also makes no sense. But it makes sense if the script tag is not at the end of the document.

But if i would be Google, i would anyway add some note about it, because if you are a big company, people are checking examples and value it. I know webmasters by myself who are just adding async / defer to a script tag, at the end of the document, while it's the only one. You could think: but it's not doing anything, so what's the problem about it? For example async can just add a little extra delay before executing JavaScipt (compared with sync). So in a case like that, it can be better to use sync in terms of page speed, instead of async on your script tag.

这篇关于Google是否使用“推迟”错误的方法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！