请教一个关于无阻塞加载的问题

[nteternal]

最近看了一些关于浏览器阻塞加载的的资料，有一个地方一直疑惑不解。
首先是介绍阻塞机制的时候，提到：

“为什么浏览器不能把javascript代码的加载过程拆分为下载和执行两个并行的过程，这样就可以充分利用时间完成http请求，这样不是就能提升页面的加载效率了吗？这个问题的答案当然是否定的，javascript是一个编程语言，js代码是有智力的，它除了可以完成逻辑性的工作，还可以通过操作页面元素来改变页面UI效果，如果我们忽略javascript对UI的影响，让它延迟执行，结果会造成页面展示的混乱。”

但是后面介绍无阻塞机制的时候，采用dom方法添加js元素。并提到“无阻塞脚本的好处就是不会阻塞UI的执行，也不会影响其他同步js代码的执行”。可是这样的话，不也会面对阻塞机制的问题，即如果js的加载重构了DOM树，或者是对UI效果发生了变化，那么不也造成页面展示的混乱了吗？

不太理解。。看的好几份资料都没有搞清楚这个dom添加js元素的方法为什么可以规避js对UI的影响。求指教

[liusaint1992]

这个文章可能我也看过。 我的理解是： 在浏览器 加载页面的时候，遇到 引用的js.就会停下来，把js执行一下，然后才继续渲染。 这个执行是要一点点时间的。是阻塞加载。如果js引用是放在网页头部，可能会出现 打开网页的时候网页短暂空白的情况。 如果把js放在页面底部，这个情况会好一些。 但是有些会对页面结构有影响的js如果延迟加载就会对页面造成肉眼可见的混乱。比如自适应宽度的js，加载得太 晚的话就会让页面 等待js的加载运行才能把页面变正常。这样的就不宜延迟加载，要尽可能快地运行。 直接 使用js生成dom来加载新的js文件。是把js的加载一定程度上可控了。 使用dom加载的js文件最好是不会对页面结构有影响的。 像我最近有个项目，里面的某地图js的加载,非常慢。 最开始是我们是把它的引用放在头部的。 结果页面会空白很久的时间。直到那个js加载出来或加载不出来，页面才可以显示。 然后我们把它放到了底部。 这样页面可以立刻显示出来了。 但是我们ajax加载到的数据并没有显示到页面上来。 估计是因为ajax异步加载的时候，就执行到那个js了。所以卡在那里，直到那个js加载出来或加不出来页面上的数据内容才 显示出来。而且这个阶段页面上的各种事件都是不能用的。那些$(document).ready()里面的东西。 最后我们使用的时，在我们页面数据返回到页面之后，再获取那个地图的js。 一定程度上解决了问题。 仅仅是个人思考 ，给楼主参考。 可能有不对，希望高手批评。。。

[以专业开发人员为伍]

这就好比说你设计一个以并发操作为主的、渲染很酷的UI的平台，你肯定要各部分都尽量并发。可是你发现当第一次加载整个脚本时，写成顺序的瀑布流方式比较好，大家已经全都接受了，那么你一定是专门为第一次加载时专门去牺牲性能而支持顺序加载。这个规范经过20年，已经习惯成自然。 但是你还没有来得及在其它某些方面也变为顺序的。因为那是最近3、4年才越来越多起来，才有这么多人希望傻瓜化地同步加载，牺牲性能也在所不惜。以前都是感觉用异步方式、学习曲线复杂一些的方式也可以。 对这种情况，不需要复杂地瞎编原因，那是解释不了为什么不傻瓜化的。

[以专业开发人员为伍]

脚本的加载跟什么对dom的操作根本没有直接关系。它原本是简单的概念，被你引用的这个文章的作者给编得繁琐诡异了。 html 页面的传统风格本身就是顺序的，例如先是 <script src=....> 然后是 <script> 使用下载的代码。这个代码风格是顺序的，已经成为“习惯成自然”，因此必须在第二部分代码执行之前保证第一部分代码完毕，才能确保顺序实现它。 而用代码加载任何dom时，按照规范的设计（以前可能很少考虑动态加载脚本的需求），javascript引擎都是直接抛给后台dom引擎一个指令就完事儿了，因此天然就是异步。规范就是如此，还没有来得及在新的规范中在第二种操作中加入同步加载的指令。 这里根本顾不上什么”对dom的影响“。 至于你引用的文章，正是应了那句俗话”一个谎言要用十个谎言来圆“。它在前边胡乱编了一个理由，后边没有圆住！