浏览器的多线程中，有的线程负责加载资源，有的线程负责执行脚本，有的线程负责渲染界面，有的线程负责轮询、监听用户事件。
成都创新互联公司始终坚持【策划先行，效果至上】的经营理念，通过多达十多年累计超上千家客户的网站建设总结了一套系统有效的全网推广解决方案，现已广泛运用于各行各业的客户，其中包括：宣传片制作等企业，备受客户表扬。
这些线程，根据浏览器自身特点以及web标准等等，有的会被浏览器特意的阻塞。两个很明显的阻塞就是：脚本执行时对其他线程的阻塞和脚本加载时对其他线程的阻塞。
这两个阻塞发生在HTML页面初次解析时，它们对性能的影响较大，原因是：
document对象绑定了一个事件：DOMContentLoaded。这个事件会在DOM解析完成之后触发。这个事件触发之后（而不是window.load事件），会进入异步事件驱动阶段（另一个线程控制）。也就是说，DOM解析工作不完成，用户与页面的很多（并不是所有）事件交互就无法进行。这时候浏览器的忙指示（那个页面上方的烦人的旋转的圆圈）不会消失。
DOMContentLoaded事件本身不会等待CSS文件、图片、iframe加载完成。
DOMContentLoaded的触发时机是：加载完页面，解析完所有标签（不包括执行CSS和JS），但是JS的执行，需要等待位于它前面的CSS加载（如果是外联的话）、执行完成，因为JS可能会依赖位于它前面的CSS计算出来的样式。所以：
如果页面中没有script标签，DOMContentLoaded事件并没有等待CSS文件、图片加载完成。
如果页面中静态的写有script标签，DOMContentLoaded事件需要等待JS执行完才触发。而且script标签中的JS需要等待位于其前面的CSS的加载完成。
注：现代浏览器会并发的预加载CSS、JS、IMG（例如：当 HTML 解析器（HTML Parser）被脚本阻塞时，解析器虽然会停止构建 DOM，但仍会识别该脚本后面的资源，并进行预加载）。但是，执行CSS和JS的顺序还是按原来的依赖顺序（JS的执行要等待位于其前面的CSS和JS加载、执行完）——先加载完成的资源，如果其依赖还没加载、执行完，就只能等着。
所以就造成外部资源阻塞渲染，如CSS 与 JavaScript
默认情况下，CSS 被视为阻塞渲染的资源，这意味着浏览器将不会渲染任何已处理的内容，直至 CSSOM 构建完毕。
JavaScript 不仅可以读取和修改 DOM 属性，还可以读取和修改 CSSOM 属性。
默认情况下，CSS 被视为阻塞渲染的资源，存在阻塞的 CSS 资源时，浏览器会延迟 JavaScript 的执行和 DOM 构建，这意味着浏览器将不会渲染任何已处理的内容，直至 CSSOM 构建完毕。
总结如下：
css加载不会阻塞DOM树的解析
css加载会阻塞DOM树的渲染
css加载会阻塞后面js语句的执行
css会阻塞js，同理，css也会阻塞img解码、paint（浏览器认为你的CSS没有加载完毕，不确定图片的样式到底如何，牵扯到重绘资源问题）,js不会阻塞img的解码、paint（估计chrome做了优化，具体本人还不知，希望客官补充）。
还可以用媒体类型（media type）和媒体查询（media query）来解除对渲染的阻塞。
media=“print",会加载，但不会阻塞；media="(min-width:320px)",会在符合查询条件下阻塞（适配css会执行）
大css文件拆分成多个小css文件，并发加载
因为渲染线程和js线程与资源进行加载的线程并不互斥，不会互斥意味着：资源的加载可以和UI渲染、重排，事件响应，或者JavaScript代码的执行的并发进行。
所以资源加载器线程会一直进行并发加载。
这里还有一个知识点：下载的最大并行数指的是从一个主机上下载的最大并行数，如果从多个主机下载资源，这个数量会翻倍，但是由于对DNS的解析也是一个性能优化的点，故而一般策略是：不应设置超过4个主机，最好只设置2个主机。
但是操蛋的就是，如果浏览器解析DOM时需要下载脚本资源，那么下载这个资源的线程就是阻塞其他下载线程以及渲染线程，导致渲染速度变慢。
但是假设该脚本下载的速度较慢，而且多个脚本非并发下载，并且假如多个
