浏览器工作机制及资源加载

浏览器的工作机制

一句话概括起来就是：web浏览器与web服务器之间通过HTTP协议进行通信的过程。所以，C/S之间握手的协议就是HTTP协议。浏览器接收完毕开始渲染之前大致过程如下：

浏览器加载渲染网页过程解析 - 落枫loven - SEO|网络营销|百度竞价 - 林宗辉

 

从浏览器地址栏的请求链接开始，浏览器通过DNS解析查到域名映射的IP地址，成功之后浏览器端向此IP地址取得连接，成功连接之后，浏览器端将请 求头信息 通过HTTP协议向此IP地址所在服务器发起请求，服务器接受到请求之后等待处理，最后向浏览器端发回响应，此时在HTTP协议下，浏览器从服务器接收到 text/html类型的代码，浏览器开始显示此html，并获取其中内嵌资源地址，然后浏览器再发起请求来获取这些资源，并在浏览器的html中显示。

离我们最近并能直接显示一个完整通信过程的工具就是Firebug了，看下图:

 其中黄色的tips浮层告诉了我们www.baidu.com”的html资源从发起请求到关闭连接整个过程中每个环节的时长（域名解析 -> 建立连接 -> 发起请求 -> 等待响应 -> 接收数据），点击该请求，可以获得HTTP的headers信息，包含响应头信息与请求头信息，如：

了解浏览器加载、解析、渲染这个过程

  • 了解浏览器如何进行加载，我们可以在引用外部样式文件，外部js时，将他们放到合适的位置，使浏览器以最快的速度将文件加载完毕。

  • 了解浏览器如何进行解析，我们可以在构建DOM结构，组织css选择器时，选择最优的写法，提高浏览器的解析速率。

  • 了解浏览器如何进行渲染，明白渲染的过程，我们在设置元素属性，编写js文件时，可以减少”重绘“”重新布局“的消耗。

    这三个过程在实际进行的时候又不是完全独立，而是会有交叉。会造成一边加载，一边解析，一边渲染的工作现象

 

关于加载顺序：当浏览器获得一个html文件时，会”自上而下“加载，并在加载过程中进行解析渲染。

加载

即为获取资源文件的过程，不同浏览器，以及他们的不同版本在实现这一过程时，会有不同的实现效果(资源间互相阻塞)，。（需要学习使用timeline来做测试，我还不太会用，学会了在上文。）

<!DOCTYPE html>
<html>
     <head>
           <meta charset="utf-8">
           <link rel="stylesheet"  href="test.css"  type="text/css" />
           <script src="test.js" type="text/javascript"></script>
     </head>
     <body>    
           <p>阻塞</p>
           <img src="test.jpg" /> 
     </body>
</html>

加载过程中遇到外部css文件，浏览器另外发出一个请求，来获取css文件。
遇到图片资源，浏览器也会另外发出一个请求，来获取图片资源。这是异步请求，并不会影响html文档进行加载，但是当文档加载过程中遇到js文件，html文档会挂起渲染（加载解析渲染同步）的线程，不仅要等待文档中js文件加载完毕，还要等待解析执行完毕，才可以恢复html文档的渲染线程。

原因：JS有可能会修改DOM，最为经典的document.write，这意味着，在JS执行完成前，后续所有资源的下载可能是没有必要的，这是js阻塞后续资源下载的根本原因。
办法：可以将外部引用的js文件放在</body>前。

虽然css文件的加载不影响js文件的加载，但是却影响js文件的执行，即使js文件内只有一行代码，也会造成阻塞。

原因：可能会有 var width = $('#id').width()，这意味着，js代码执行前，浏览器必须保证css文件已下载和解析完成。这也是css阻塞后续js的根本原因。
办法：当js文件不需要依赖css文件时，可以将js文件放在头部css的前面。

当然除了，<link href="" />这种形式，内部<style></style>这种样式定义，在考虑阻塞时也要考虑。
以上对于代码布局对文档加载的影响是比较基础的，随着浏览器的升级，以及js技术的应用，html的发展，web性能也会逐渐提高。
列举一下，以后可以逐一扩充一下：

  • 不要在外部调用的js文件中调用运行时间较长的函数，如果一定要用，可以使用setTimeout函数。

    为什么呢？

    1. 浏览器GUI渲染线程
    2. javascript引擎线程
    3. 浏览器定时器触发线程（setTimeout）
    4. 浏览器事件触发线程
    5. 浏览器http异步请求线程（.jpg <link />这类请求）
      原因：浏览器有以上五个常驻线程
      发现第3个线程，我们便知道，如果在js内使用setTimeout()那么会调用另一个线程。
      注意：这里也涉及到 阻塞 的现象，当js引擎线程（第二个）进行时，会挂起其他一切线程，这个时候3、4、5这三类线线程也会产生不同的异步事件（这句话不懂啊），由于 javascript引擎线程为单线程，所以代码都是先压到队列，采用先进先出的方式运行，事件处理函数，timer函数也会压在队列中，不断的从队头取出事件，这就叫：javascript-event-loop。

  • 现代浏览器存在 prefetch 优化，浏览器会另外开启线程，提前下载js、css文件，需要注意的是，预加载js并不会改变dom结构，他将这个工作留给主加载。

  • 预加载网页，利用空余时间来提前加载该网页的后续网页。 
    <link rel="prefetch" href="http://">
  • 为js脚本添加defer属性，使得浏览器不等js脚本加载执行完，就加载后面的图片。既然图片资源都已经加载出来了，就不要在js内写document.write啦。 
    <script defer="true" src="JavaScript.js" type="text/javascript"/>

     

解析

解析的概念有些多，需要另写一篇文章。于是我就先简单的写一下。

  • html文档解析生成解析树即dom树，是由dom元素及属性节点组成，树的根是document对象。

    DOM:文档对象模型的缩写，是html文档的对象表示，作为html的外部接口供js调用。

    document.getElementById('test').style.display="none";//通过dom接口将id为test的display值设为none。

  • css解析将css文件解析为样式表对象。该对象包含css规则，该规则包含选择器和声明对象。

css解析.png
css解析.png
  • js解析因为文件在加载的同时也进行解析，详看js加载部分。

渲染

即为构建渲染树的过程，他是原来DOM树的可视化表示，构建这棵树是为了以正确的顺序绘制文档内容。
渲染树和DOM树的关系，不可见的dom元素（<head>…</head> display=none）不会被插入渲染树中。还有像一些节点的位置为绝对或浮动定位（需要css知识理解），这些节点会在文本流之外，因此会在两棵树上的不同位置，渲染树标识出真实的位置，并用一个占位结构标识出他们原来的位置。

渲染最大的一个困难就是为每一个dom节点计算符合他的最终样式。
  • 为每一个元素查找到匹配的样式规则，需要遍历整个规则表。关于遍历规则表的方法，我之前理解错啦。 
     #test p{ color:#999999}
    正解：遍历是自右向左，也就是先查询到p元素，再找到上一级id为test的元素。之前的理解正好相反。这样发现，遍历的效率好低。
    为什么：可以去看之前css解析时，生成的样式对象，遍历的顺序，自然是从树的低端向上遍历。

计算样式的一些困难：

  1. 样式数据是非常大的结构，保存这样是的数据是很耗内存的。
  2. 选择器迭代太深，造成太多的无用遍历。
  3. 样式规则涉及非常复杂的级联，定义了规则的层次（理解：<head>里引用的外部样式表，会被局部样式表中同一属性的设置取代。还有例如body内对font的设置本来会应用于孩子元素，但是如果body的孩子元素定义font属性，则会被后者取代）。

解决办法：共享样式数据。（元素可以共享样式数据的条件就是他们的状态是”一致“的。）

JS 和 CSS 的位置对其他资源加载顺序的影响

JS 和 CSS 在页面中的位置，会影响其他资源（指 img 等非 js 和 css 资源）的加载顺序，究其原因，有三个值得注意的点：

  1. JS 有可能会修改 DOM. 典型的，可能会有 document.write. 这意味着，在当前 JS 加载和执行完成前，后续所有资源的下载有可能是没必要的。这是 JS 阻塞后续资源下载的根本原因。
  2. JS 的执行有可能依赖最新样式。比如，可能会有 var width = $('#id').width(). 这意味着，JS 代码在执行前，浏览器必须保证在此 JS 之前的所有 css（无论外链还是内嵌）都已下载和解析完成。这是 CSS 阻塞后续 JS 执行的根本原因。
  3. 现代浏览器很聪明，会进行 prefetch 优化。性能是如此重要，现代浏览器在竞争中，在 UI update 线程之外，还会开启另一个线程，对后续 JS 和 CSS 提前下载（注意，仅提前下载，并不执行）。有了 prefetch 优化，这意味着，在不存在任何阻塞的情况下，理论上 JS 和 CSS 的下载时机都非常优先，和位置无关。

以上三点可简述为三条基本定律：

  • 定律一：资源是否下载依赖 JS 执行结果。
  • 定律二：JS 执行依赖 CSS 最新渲染。
  • 定律三：现代浏览器存在 prefetch 优化。

有了这三条定律，再来看克军的测试，就很清晰了：

a,b – head里出现外联js，无论如何放，css文件都不能和body里的请求并行

根据定律一和定律三，可以知道上面的结论不够正确。比如：

1    <head>
2    <link rel="stylesheet" href="mock.php?css1&sleep=2">
3    <script src="mock.php?js&sleep=3"></script>
4    <link rel="stylesheet" href="mock.php?css2&sleep=4">
5    </head>
6    <body>
7    <link rel="stylesheet" href="mock.php?css3&sleep=5">
8    <img src="test.gif">
9    </body>

在 Chrome 下的瀑布图是：

 

黄色条是 js 的，可以看出 img 的延时下载是由定律一决定的。

定律三则决定了所有 js/css 都是并行开始下载的。在 Firefox 10 下，prefetch 非常强悍，对 img 也会预加载，瀑布图如下：

调整一下 sleep 时间，还可以观察到定律二的威力：

1    <head>
2    <link rel="stylesheet" href="mock.php?css1&sleep=3"> <!-- 修改 sleep 值，使其大于 js 的 -->
3    <script src="mock.php?js&sleep=2"></script>
4    <link rel="stylesheet" href="mock.php?css2&sleep=4">
5    </head>
6    <body>
7    <link rel="stylesheet" href="mock.php?css3&sleep=5">
8    <img src="test.gif">
9    </body>

瀑布图立刻发生了变化：

因为定律一，决定 img 的下载在 js 执行后。又因为定律二，决定 js 的执行在第一个 css 后。于是最后在瀑布图上体现出来，就是 img 的下载在第一个 css 后。

再来看克军的第二个结论：

c – head里的内联js只要在所有外联css前面，css文件可以和body里的请求并行（图2）
d – head里的内联js只要在任一外联css后面，css文件就不能和body里的请求并行（图1）

这个是定律二的威力。结论 c 是正确的，因为没有 css 会影响 js 的执行。结论 d 则不够正确。img 等其他资源，会在 js 前面的 css 下载完成后，以及 js 执行后，立刻开始下载。与头部中，js 位置之后的 css 没关系。

克军的其他结论都是对的，不多说。

注意1：Firefox 10 的 prefetch 有点奇怪，有时会对 img 进行 prefetch，有时则不会。有兴趣的可以进一步寻找规律。
注意2：上面的三个定律，是黑盒猜测，有兴趣的可以去阅读浏览器的源码，应该能找到更深层次的原因。
注意3：本文没有考虑 defer, async 属性的影响，这是另一个故事。

js 程序执行与顺序实现详解 

JavaScript是一种描述型脚本语言，它不同于java或C#等编译性语言,它不需要进行编译成中间语言,而是由浏览器进行动态地解析与执行。如果 你不能理解javaScript语言的运行机制，或者简单地说，你不能掌握javascript的执行顺序，那你就犹如伯乐驾驭不了千里马，让千里马脱缰 而出，四处乱窜。


那么JavaScript是怎么来进行解析的吗？它的执行顺序又是如何的呢？在了解这些之前，我们先来认识几个重要的术语：

1、代码块

　　JavaScript中的代码块是指由<script>标签分割的代码段。例如：

<script type="text/javascript">
      alert("这是代码块一");
</script>
<script type="text/javascript">
      alert("这是代码块二");
</script>

 JS是按照代码块来进行编译和执行的，代码块间相互独立，但变量和方法共享。什么意思呢? 举个例子，你就明白了：

<script type="text/javascript">
      alert(str);//因为没有定义str，所以浏览器会出错，下面的不能运行
      alert("我是代码块一");//没有运行到这里
      var test = "我是代码块一变量";
</script>
<script type="text/javascript">
      alert("我是代码块二"); //这里有运行到
      alert(test); //弹出"我是代码块一变量"
</script>

上面的代码中代码块一中运行报错，但不影响代码块二的执行，这就是代码块间的独立性，而代码块二中能调用到代码一中的变量，则是块间共享性。、

2、声明式函数与赋值式函数

　　JS中的函数定义分为两种：声明式函数与赋值式函数。

<script type="text/javascript">
     function Fn(){ //声明式函数
              
     }
          
     var Fn = function{  //赋值式函数
              
     }
</script>

声明式函数与赋值式函数的区别在于：在JS的预编译期，声明式函数将会先被提取出来，然后才按顺序执行js代码。

　　3、预编译期与执行期

　　事实上，JS的解析过程分为两个阶段：预编译期(预处理)与执行期。

　　预编译期JS会对本代码块中的所有声明的变量和函数进行处理（类似与C语言的编译），但需要注意的是此时处理函数的只是声明式函数，而且变量也只是进行了声明但未进行初始化以及赋值。

<script type="text/javascript">
     Fn();  //执行结果："执行了函数2",同名函数后者会覆盖前者
     function Fn(){ //函数1
        alert("执行了函数1");
     }
          
     function Fn(){  //函数2
        alert("执行了函数2");
     }
</script> 
<script type="text/javascript">
      Fn();  //执行结果："执行了声明式函数",在预编译
//期声明函数及被处理了，所以即使Fn()调用函数
//放在声明函数前也能执行。
      function Fn(){ //声明式函数
         alert("执行了声明式函数");
      }
          
      var Fn = function(){  //赋值式函数
         alert("执行了赋值式函数");
      }
</script>
//代码块一
<script type="text/javascript">
      alert(str);//浏览器报错,但并没有弹出信息窗
</script>
//代码块二
<script type="text/javascript">
      alert(str); //弹窗"undefined"
      var str = "aaa";
</script>
//js在预处理期对变量进行了声明处理,但是并没有进
//行初始化与赋值，所以导致代码块二中的变量是unfiened的
//，而代码一中的变量是完全不存在的，所以浏览器报错。

理解了上面的几个术语，相信大家对JS的运行机制已经有了个大概的印象了，现在我们来看个例子：

<script type="text/javascript">
      Fn();  //浏览器报错:"undefined"
</script>
<script type="text/javascript">
      function Fn(){ //函数1
          alert("执行了函数1");
      }
</script>

为什么运行上面的代码浏览器会报错呢？声明函数不是会在预处理期就会被处理了吗，怎么还会找不到Fn()函数呢？其实这是一个理解误点，我们上面 说了JS引擎是按照代码块来顺序执行的，其实完整的说应该是按照代码块来进行预处理和执行的，也就是说预处理的只是执行到的代码块的声明函数和变量，而对 于还未加载的代码块，是没法进行预处理的，这也是边编译边处理的核心所在。

　　现在，让我们来总结整理下：

　　step 1.  读入第一个代码块。

　　step 2.  做语法分析，有错则报语法错误（比如括号不匹配等），并跳转到step5。

　　step 3.  对var变量和function定义做“预编译处理”（永远不会报错的，因为只解析正确的声明）。

　　step 4.  执行代码段，有错则报错（比如变量未定义）。

　　step 5.  如果还有下一个代码段，则读入下一个代码段，重复step2。

　　step6. 结束。

　　而根据HTML文档流的执行顺序，需要在页面元素渲染前执行的js代码应该放在<body>前面的<script>代码块 中，而需要在页面元素加载完后的js放在</body>元素后面，body标签的onload事件是在最后执行的。

<script type="text/javascript">
    alert("first");
    function Fn(){
        alert("third");
    }
</script>
<body onload="Fn()">
      
</body>
<script type="text/javascript">
    alert("second");
</script>

 

http://blog.163.com/seo_luofeng/blog/static/176575024201242412342680/

http://www.jianshu.com/p/e141d1543143

http://www.51testing.com/html/38/225738-220986.html

http://www.cnblogs.com/dongfengyuxy/p/5850105.html

 

posted on 2017-07-10 17:39  默默地  阅读(2626)  评论(0)  编辑  收藏  举报

导航