整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

前端性能优化(四)-网页加载更快的N种方式

前端性能优化(四)-网页加载更快的N种方式

站前端的用户体验,决定了用户是否想要继续使用网站以及网站的其他功能,网站的用户体验佳,可留住更多的用户。除此之外,前端优化得好,还可以为企业节约成本。那么我们应该如何对我们前端的页面进行性能优化呢?

前端性能优化可以分为三个方面:接口访问优化、静态资源优化和页面渲染速度优化。

一、接口访问优化

1.1、减少http请求,合理设置 HTTP缓存

http协议是无状态的应用层协议,每次发送http请求时,都需要建立连接、通信、断开连接,在服务器端每个http都需要开启独立的线程去处理。所以尽量减少http请求,尽可能地提高访问性能。

减少http请求的方法:

  1. 合并 js、css、图片等文件,合并成一个文件,浏览器就只需请求一次就可以了。图片合并要适当,不能想着优化呢,盲目地都合并成一张图片。
  2. 借用浏览器缓存。恰当的缓存设置可以大大减少http请求。不懂浏览器缓存的可参考《浏览器九大缓存方法》。
  3. 接口合并。前端交互,经常需要请求多个并行或串行接口,此时可以通过接口合并方式,提高接口访问速度。
  4. 能使用css的尽量不使用js,能使用js的尽量不用三方插件,避免三方插件大量的库。

1.2、减少cookie传输

cookie 存在于 http 头,在客户端与服务器之间交换,尽可能地控制 cookie 的大小,cookie越小,响应速度越快,减少 cookie 传输,响应速度更快。

1.3、使用CDN提供静态文件

使用 CDN 可以更快地在全球范围内获取到你的静态文件,加快网页加载。

1.4、启用 GZIP 压缩

http 协议上 GZIP 编码,是一种用来改进 web 应用程序的。开启 GZIP 后,服务器会把网页内容压缩后传输,一般能压缩到原大小40%,这样网页传输速度就更快了。GZIP 有两大好处:一是减少存储空间,二是通过网络传输文件时,可以减少传输时间。

1.5、分域存放资源

HTTP 客户端一般对同一个服务器的并发连接个数都是有限制的,通常最大并行连接为四了,剩下的会进入等待队列,等前边的执行完毕,等待的才会执行。所以利用多域名主机存放资源,增加并行连接量,缩短资源加载时间。

1.6、减少页面重定向

开启 https 可以有效防范攻击,保证用户始终访问到网站的加密连接,保护数据安全,同时省去 301/302 跳转的时间,大大提升网站的安全系数和用户体验。

如果在网站设置当用户访问域名的时候强制 https 进行 301 或者 302 跳转,但是这个过程中,用到 HTTP 因此容易发生劫持,受到第三方的攻击。所以尽可能使用https安全。

1.7、避免使用iframe

iframe 相当于本页面又嵌套了一个页面,消耗性能,还要加载嵌套页面的资源,所以更消耗时间。

1.8、借用浏览器缓存

ajax 请求到的数据,可以缓存到浏览器,下次使用的时候无需再次获取,直接取缓存数据就可以。这个会根据具体的项目来做,比如常用的角色类型就会缓存,获取到的普通数据为了保证实时性,不能使用缓存。

二、静态资源优化

2.1、压缩 html、css、js 等文件

删除不必要的空格、注释和中行,减少文件大小,显著减少用户下载时间,加快网页加载速度。可以直接使用压缩工具,可以自动删除所有不必要内容。

2.2、在 js 之前引用 css

这是一个小细节,js 执行的时候会进入阻塞,如果放入 js 之后加载,会等待 js 执行完成之后才能加载 css,渲染页面,此时就会出现布局错乱。所以 css 文件需要非阻塞引入,以防DOM 花费更多时间才能渲染。

2.3、非阻塞 js

js 会阻止 html 文档的正常解析,当解析器到达 script 标记时,它会停止解析并执行脚本。所以我们经常把 script 引入的 js,放到 html 中最底下。如果需要让脚本位于页面顶部,建议添加非阻塞属性。经常使用 defer 和 async 来异步加载js文件。

<!--  使用defer  -->
<script defer src="foo.js" ></script>
<!--   使用async  -->
<script async src="foo.js"></script>

2.4、图片压缩

最常见的就是 css 雪碧,就是将很多很多的小图标放在一张图片上,就称为雪碧图。雪碧图最大优点就是可以减少http请求,除此也能压缩图片文件大小。使用的时候,通过设置 background-position ,移动图片的位置。除此之外,网站用到的大图,也需要在保证图片质量前提下优化到最小。

2.5、矢量图替代位图

矢量图(SVG)往往比图像小很多,缩放的时候不失真,这些图像还可以通过 css 进行动画和修改,比位图方便控制。可以的话,尽量用矢量图多点。

2.6、js代码相关优化

  1. 尽量减少使用闭包,因为闭包所在的上下文不会被释放。
  2. js避免嵌套循环和死循环,一旦遇到死循环,浏览器会卡死。
  3. 在js封装过程中,尽量做到低耦合高内聚。减少页面的冗余代码。
  4. 尽量减少递归,避免死递归。
  5. 尽量使用window.requestAnimationFrame替代传统的定时器。

三、页面渲染速度

3.1、懒加载

素材类的网站,页面一屏展示很多图片,而且图片还不能失真,图片加载太多,网页加载慢得很,所以就引用懒加载,只加载可视区的图片,避免加载可以能不需要或不必要的图像。改善页面的响应时间。

3.2、避免响应式布局

响应式网站虽然能够兼容所有终端设备,但是会出现隐藏部分无用内容,浪费带宽,加载时间还长,页面的渲染时间也长。想更多了解响应式布局,请点击《前端响应式布局为什么是个坑?》。

3.3、设置大小,避免重绘

遇到 img 标签,会立马发送一个 http 请求,下载图片,页面继续向下渲染,等图片加载成功了,发现图片的宽高大小发生变化,影响后边排版,所以页面会重新再绘制一次这部分。所以尽可能设置图片的大小。

3.4、减少DOM元素

解析 html 内容,将标签转化为DOM节点,之后再解析其他文件,DOM元素越少,也就是标签越少,文件转化得越快,加载速度也就快了。

3.5、减少 Flash 的使用

flash 文件比较大,加载起来耗时。除此,flash 插件还需要运行才能运行,最主要有些浏览器flash插件马上要下线了,建议尽量不用 flash。

3.6、文件顺序

css文件放在最顶部,优先渲染。js放在最底部,避免阻塞。

让网页如何加载更快,有好多的细节,还是要好好提升自己的技能~~~~~~~~~


点个关注!更多分享内容。


SS in JS

CSS in JS是一种解决css问题想法的集合,而不是一个指定的库。从CSS in JS的字面意思可以看出,它是将css样式写在JavaScript文件中,而不需要独立出.css.less之类的文件。将css放在js中使我们更方便的使用js的变量模块化tree-shaking。还解决了css中的一些问题,譬如:更方便解决基于状态的样式更容易追溯依赖关系生成唯一的选择器来锁定作用域。尽管CSS in JS不是一个很新的技术,但国内的普及程度并不高。由于Vue和Angular都有属于他们自己的一套定义样式的方案,React本身也没有管用户怎样定义组件的样式[1],所以CSS in JS在React社区的热度比较高。

目前为止实现CSS in JS的第三方库有很多:(http://michelebertoli.github.io/css-in-js/)。像JSS[2]styled-components[3]等。在这里我们就不展开赘述了(相关链接已放在下方),这篇文章的重点是JS in CSS

JS in CSS又是什么

在上面我们提到CSS in JS就是把CSS写在JavaScript中,那么JS in CSS我们可以推断出就是可以在CSS中使用JavaScript脚本,如下所示。可以在CSS中编写Paint API的功能。还可以访问:ctx,geom。甚至我们还可以编写自己的css自定义属性等。这些功能的实现都基于CSS Houdini[4]

.el {
  --color: cyan;
  --multiplier: 0.24;
  --pad: 30;
  --slant: 20;
  --background-canvas: (ctx, geom) => {
    let multiplier = var(--multiplier);
    let c = `var(--color)`;
    let pad = var(--pad);
    let slant = var(--slant);

    ctx.moveTo(0, 0);
    ctx.lineTo(pad + (geom.width - slant - pad) * multiplier, 0);
    ctx.lineTo(pad + (geom.width - slant - pad) * multiplier + slant, geom.height);
    ctx.lineTo(0, geom.height);
    ctx.fillStyle = c;
    ctx.fill();
  };
  background: paint(background-canvas);
  transition: --multiplier .4s;
}
.el:hover {
  --multiplier: 1;
}

Houdini 解决了什么问题

CSS 与 JS的标准制定流程对比

在如今的Web开发中,JavaScript几乎占据了项目代码的大部分。我们可以在项目开发中使用ES 2020、ES2021、甚至提案中的新特性(如:Decorator[5]),即使浏览器尚未支持,也可以编写Polyfill或使用Babel之类的工具进行转译,让我们可以将最新的特性应用到生产环境中(如下图所示)。

JavaScript标准制定流程.png

而CSS就不同了,除了制定CSS标准规范所需的时间外,各家浏览器的版本、实战进度差异更是旷日持久(如下图所示),最多利用PostCSS、Sass等工具來帮我们转译出浏览器能接受的CSS。开发者们能操作的就是通过JS去控制DOMCSSOM来影响页面的变化,但是对于接下來的LayoutPaintComposite就几乎没有控制权了。为了解决上述问题,为了让CSS的魔力不在受到浏览器的限制,Houdini就此诞生。

CSS 标准制定流程.png

CSS Polyfill

我们上文中提到JavaScript中进入提案中的特性我们可以编写Polyfill,只需要很短的时间就可以讲新特性投入到生产环境中。这时,脑海中闪现出的第一个想法就是CSS Polyfill,只要CSS的Polyfill 足够强大,CSS或许也能有JavaScript一样的发展速度,令人可悲的是编写CSS Polyfill异常的困难,并且大多数情况下无法在不破坏性能的情况下进行。这是因为JavaScript是一门动态脚本语言[6]。它带来了极强的扩展性,正是因为这样,我们可以很轻松使用JavaScript做出JavaScript的Polyfill。但是CSS不是动态的,在某些场景下,我们可以在编译时将一种形式的CSS的转换成另一种(如PostCSS[7])。如果你的Polyfill依赖于DOM结构或者某一个元素的布局、定位等,那么我们的Polyfill就无法编译时执行,而需要在浏览器中运行了。不幸的是,在浏览器中实现这种方案非常不容易。

页面渲染流程.png

如上图所示,是从浏览器获取到HTML到渲染在屏幕上的全过程,我们可以看到只有带颜色(粉色、蓝色)的部分是JavaScript可以控制的环节。首先我们根本无法控制浏览器解析HTML与CSS并将其转化为DOMCSSOM的过程,以及Cascade,Layout,Paint,Composite我们也无能为力。整个过程中我们唯一完全可控制的就是DOM,另外CSSOM部分可控。

CSS Houdini草案中提到,这种程度的暴露是不确定的、兼容性不稳定的以及缺乏对关键特性的支持的。比如,在浏览器中的 CSSOM 是不会告诉我们它是如何处理跨域的样式表,而且对于浏览器无法解析的 CSS 语句它的处理方式就是不解析了,也就是说——如果我们要用 CSS polyfill让浏览器去支持它尚且不支持的属性,那就不能在 CSSOM 这个环节做,我们只能遍历一遍DOM,找到 <style><link rel="stylesheet"> 标签,获取其中的 CSS 样式、解析、重写,最后再加回 DOM 树中。令人尴尬的是,这样DOM树全部刷新了,会导致页面的重新渲染(如下如所示)。

即便如此,有的人可能会说:“除了这种方法,我们也别无选择,更何况对网站的性能也不会造成很大的影响”。那么对于部分网站是这样的。但如果我们的Polyfill是需要对可交互的页面呢?例如scrollresizemousemovekeyup等等,这些事件随时会被触发,那么意味着随时都会导致页面的重新渲染,交互不会像原本那样丝滑,甚至导致页面崩溃,对用户的体验也极其不好。

综上所述,如果我们想让浏览器解析它不认识的样式(低版本浏览器使用grid布局),然而渲染流程我们无法介入,我们也只能通过手动更新DOM的方式,这样会带来很多问题,Houdini的出现正是致力于解决他们。

Houdini API

Houdini是一组底层API,它公开了CSS引擎的各个部分,如下图所示展示了每个环节对应的新API(灰色部分各大浏览器还未实现),从而使开发人员能够通过加入浏览器渲染引擎的样式和布局过程来扩展CSS。Houdini是一群来自Mozilla,Apple,Opera,Microsoft,HP,Intel和Google的工程师组成的工作小组设计而成的。它们使开发者可以直接访问CSS对象模型(CSSOM),使开发人员可以编写浏览器可以解析为CSS的代码,从而创建新的CSS功能,而无需等待它们在浏览器中本地实现。

CSS Houdini-API

Properties & Values API

尽管当前已经有了CSS变量,可以让开发者控制属性值,但是无法约束类型或者更严格的定义,CSS Houdini新的API,我们可以扩展css的变量,我们可以定义CSS变量的类型,初始值,继承。它是css变量更强大灵活。

CSS变量现状:

.dom {
  --my-color: green;
  --my-color: url('not-a-color'); // 它并不知道当前的变量类型
  color: var(--my-color);
}

Houdini提供了两种自定义属性的注册方式,分别是在js和css中。

CSS.registerProperty({
  name: '--my-prop', // String 自定义属性名
  syntax: '<color>', // String 如何去解析当前的属性,即属性类型,默认 *
  inherits: false, // Boolean 如果是true,子节点将会继承
  initialValue: '#c0ffee', // String 属性点初始值
});

我们还可以在css中注册,也可以达到上面的效果

@property --my-prop {
  syntax: '<color>';
  inherits: false;
  initial-value: #c0ffee;
}

这个API中最令人振奋人心的功能是自定义属性上添加动画,像这样:transition: --multiplier 0.4s;,这个功能我们在前面介绍什么是js in css那个demo[8]用使用过。我们还可以使用+使syntax属性支持一个或多个类型,也可以使用|来分割。更多syntax属性值:

属性值描述<length>长度值<number>数字<percentage>百分比<length-percentage>长度或百分比,calc将长度和百分比组成的表达式<color>颜色<image>图像<url>网址<integer>整数<angle>角度<time>时间<resolution>分辨率<transform-list>转换函数<custom-ident>ident

Worklets

Worklets是渲染引擎的扩展,从概念上来讲它类似于Web Workers[9],但有几个重要的区别:

  1. 设计为并行,每个Worklets必须始终有两个或更多的实例,它们中的任何一个都可以在被调用时运行
  2. 作用域较小,限制不能访问全局作用域的API(Worklet的函数除外)
  3. 渲染引擎会在需要的时候调用他们,而不是我们手动调用

Worklet是一个JavaScript模块,通过调用worklet的addModule方法(它是个Promise)来添加。比如registerLayout,registerPaint, registerAnimator 我们都需要放在Worklet中

//加载单个
await demoWorklet.addModule('path/to/script.js');

// 一次性加载多个worklet
Promise.all([
  demoWorklet1.addModule('script1.js'),
  demoWorklet2.addModule('script2.js'),
]).then(results => {});

registerDemoWorklet('name', class {

  // 每个Worklet可以定义要使用的不同函数
  // 他们将由渲染引擎在需要时调用
  process(arg) {
    return !arg;
  }
});

Worklets的生命周期

Worklets lifecycle

  1. Worklet的生命周期从渲染引擎内开始
  2. 对于JavaScript,渲染引擎启动JavaScript主线程
  3. 然后他将启动多个worklet进程,并且可以运行。这些进程理想情况下是独立于主线程的线程,这样就不会阻塞主线程(但它们也不需要阻塞)
  4. 然后在主线程中加载我们浏览器的JavaScript
  5. 该JavaScript调用 worklet.addModule 并异步加载一个worklet
  6. 加载后,将worklet加载到两个或多个可用的worklet流程中
  7. 当需要时,渲染引擎将通过从加载的Worklet中调用适当的处理函数来执行Worklet。该调用可以针对任何并行的Worklet实例。

Typed OM

Typed OM是对现有的CSSOM的扩展,并实现 Parsing APIProperties & Values API相关的特性。它将css值转化为有意义类型的JavaScript的对象,而不是像现在的字符串。如果我们尝试将字符串类型的值转化为有意义的类型并返回可能会有很大的性能开销,因此这个API可以让我们更高效的使用CSS的值。

现在读取CSS值增加了新的基类CSSStyleValue,他有许多的子类可以更加精准的描述css值的类型:

子类描述CSSKeywordValueCSS关键字和其他标识符(如inherit或grid)CSSPositionValue位置信息 (x,y)CSSImageValue表示图像的值属性的对象CSSUnitValue表示为具有单个单位的单个值(例如50px),也可以表示为没有单位的单个值或百分比CSSMathValue比较复杂的数值,比如有calc,min和max。这包括子类 CSSMathSum, CSSMathProduct, CSSMathMin,CSSMathMax, CSSMathNegate 和 CSSMathInvertCSSTransformValue由CSS transforms组成的CSSTransformComponent列表,其中包括CSSTranslate, CSSRotate, CSSScale, CSSSkew, CSSSkewX, CSSSkewY, CSSPerspective 和 CSSMatrixComponent

使用Typed OM主要有两种方法:

  1. 通过attributeStyleMap设置和获取有类型的行间样式
  2. 通过computedStyleMap获取元素完整的Typed OM样式

使用attributeStyleMap设置并获取

myElement.attributeStyleMap.set('font-size', CSS.em(2));
myElement.attributeStyleMap.get('font-size'); // CSSUnitValue { value: 2, unit: 'em' }

myElement.attributeStyleMap.set('opacity', CSS.number(.5));
myElement.attributeStyleMap.get('opacity'); // CSSUnitValue { value: 0.5, unit: 'number' };

在线demo[10]

使用computedStyleMap

.foo {
  transform: translateX(1em) rotate(50deg) skewX(10deg);
  vertical-align: baseline;
  width: calc(100% - 3em);
}
const cs = document.querySelector('.foo').computedStyleMap();

cs.get('vertical-align');
// CSSKeywordValue {
//  value: 'baseline',
// }

cs.get('width');
// CSSMathSum {
//   operator: 'sum',
//   length: 2,
//   values: CSSNumericArray {
//     0: CSSUnitValue { value: -90, unit: 'px' },
//     1: CSSUnitValue { value: 100, unit: 'percent' },
//   },
// }

cs.get('transform');
// CSSTransformValue {
//   is2d: true,
//   length: 3,
//   0: CSSTranslate {
//     is2d: true,
//     x: CSSUnitValue { value: 20, unit: 'px' },
//     y: CSSUnitValue { value: 0, unit: 'px' },
//     z: CSSUnitValue { value: 0, unit: 'px' },
//   },
//   1: CSSRotate {...},
//   2: CSSSkewX {...},
// }

Layout API

开发者可以通过这个API实现自己的布局算法,我们可以像原生css一样使用我们自定义的布局(像display:flex, display:table)。在Masonry layout library[11] 上我们可以看到开发者们是有多想实现各种各样的复杂布局,其中一些布局光靠 CSS 是不行的。虽然这些布局会让人耳目一新印象深刻,但是它们的页面性能往往都很差,在一些低端设备上性能问题犹为明显。

CSS Layout API 暴露了一个registerLayout方法给开发者,接收一个布局名(layout name)作为后面在 CSS中使用的属性值,还有一个包含有这个布局逻辑的JavaScript类。

my-div {
  display: layout(my-layout);
}
// layout-worklet.js
registerLayout('my-layout', class {
  static get inputProperties() { return ['--foo']; }
  
  static get childrenInputProperties() { return ['--bar']; }
  
  async intrinsicSizes(children, edges, styleMap) {}

  async layout(children, edges, constraints, styleMap) {}
});
await CSS.layoutWorklet.addModule('layout-worklet.js');

目前浏览器大部分还不支持

Painting API

我们可以在CSS background-image中使用它,我们可以使用Canvas 2d上下文,根据元素的大小控制图像,还可以使用自定义属性。

await CSS.paintWorklet.addModule('paint-worklet.js');
registerPaint('sample-paint', class {
  static get inputProperties() { return ['--foo']; }

  static get inputArguments() { return ['<color>']; }

  static get contextOptions() { return {alpha: true}; }

  paint(ctx, size, props, args) { }
});

Animation API

这个API让我们可以控制基于用户输入的关键帧动画,并且以非阻塞的方式。还能更改一个 DOM 元素的属性,不过是不会引起渲染引擎重新计算布局或者样式的属性,比如 transform、opacity 或者滚动条位置(scroll offset)。Animation API的使用方式与 Paint APILayout API略有不同我们还需要通过new一个WorkletAnimation来注册worklet。

// animation-worklet.js
registerAnimator('sample-animator', class {
  constructor(options) {
  }
  animate(currentTime, effect) {
    effect.localTime = currentTime;
  }
});
await CSS.animationWorklet.addModule('animation-worklet.js');

// 需要添加动画的元素
const elem = document.querySelector('#my-elem');
const scrollSource = document.scrollingElement;
const timeRange = 1000;
const scrollTimeline = new ScrollTimeline({
  scrollSource,
  timeRange,
});

const effectKeyframes = new KeyframeEffect(
  elem,
  // 动画需要绑定的关键帧
  [
    {transform: 'scale(1)'},
    {transform: 'scale(.25)'},
    {transform: 'scale(1)'}
  ],
  {
    duration: timeRange,
  },
);
new WorkletAnimation(
  'sample-animator',
  effectKeyframes,
  scrollTimeline,
  {},
).play();

关于此API的更多内容:(https://github.com/w3c/css-houdini-drafts/tree/main/css-animation-worklet-1)

Parser API

允许开发者自由扩展 CSS 词法分析器。

解析规则:

const background = window.cssParse.rule("background: green");
console.log(background.styleMap.get("background").value) // "green"

const styles = window.cssParse.ruleSet(".foo { background: green; margin: 5px; }");
console.log(styles.length) // 5
console.log(styles[0].styleMap.get("margin-top").value) // 5
console.log(styles[0].styleMap.get("margin-top").type) // "px"

解析CSS:

const style = fetch("style.css")
        .then(response => CSS.parseStylesheet(response.body));
style.then(console.log);

Font Metrics API

它将提供一些方法来测量在屏幕上呈现的文本元素的尺寸,将允许开发者控制文本元素在屏幕上呈现的方式。使用当前功能很难或无法测量这些值,因此该API将使开发者可以更轻松地创建与文本和字体相关的CSS特性。例如:

  • flex布局: align-items baseline特性。需要知道每一个flex盒子中第一个元素的基线位置。
  • 首字母: 需要知道每个字母的基线高度和字母最大的高度,以及换行内容的基线长度。
  • 单个字形的前进和后退。
  • 换行: 需要访问字体数据,文本的所有样式输入以及布局信息(可用的段落长度等)。
  • 元素中的每一个line boxes都需要一个基线。(line boxes代表包含众多inline boxes的这行)

Houdini 目前进展

Is Houdini ready yet

(https://ishoudinireadyyet.com/)

Houdini 的蓝图

了解到这里,部分开发者可能会说:“我不需要这些花里胡哨的技术,并不能带收益。我只想简简单单的写几个页面,做做普通的Web App,并不想试图干预浏览器的渲染过程从而实现一些实验性或炫酷的功能。”如果这样想的话,我们不妨退一步再去思考。回忆下最近做过的项目,用于实现页面效果所使用到的技术,grid布局方式在考虑兼容老版本浏览器时也不得不放弃。我们想控制浏览器渲染页面的过程并不是仅仅为了炫技,更多的是为了帮助开发者们解决以下两个问题:

  1. 统一各大浏览器的行为
  2. JavaScript一样,在推出新的特性时,我们可以通过Polyfill的形式快速的投入生产环境中。

几年过后再回眸,当主流浏览器完全支持Houdini的时候。我们可以在浏览器上随心所欲的使用任何CSS属性,并且他们都能完美支持。像今天的grid布局在旧版本浏览器支持的并不友好的这类问题,那时我们只需要安装对应的Polyfill就能解决类似的问题。

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

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

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

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

//响应头信息 HTTP/1.1 304

Server: Apache/2.2.4 (Win32) PHP/5.2.1 Connection: Keep-Alive Keep-Alive: timeout=5, max=100 Etag: "1e483-1324-a86f5621"

//请求头信息 GET /Docs/eva/api/colorBox.html HTTP/1.1 Host: ued.com User-Agent: Mozilla/5.0

Firefox/3.6.13 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-cn,zh;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Referer: http://ued.com/Docs/ If-Modified-Since: Thu, 17 Feb 2011 10:14:07 GMT If-None-Match: "1e483-1324-a86f5621" Cache-Control: max-age=0

另外,ajax异步请求同样遵循HTTP协议,原理大同小异。

浏览器加载显示html页面内容的顺序

我们经常看到浏览器在加载某个页面时,部分内容先显示出来,又有些内容后显示。那么浏览器加载显示html究竟是按什么顺序进行的呢?

其实浏览器加载显示html的顺序是按下面的顺序进行的:

1、IE下载的顺序是从上到下,渲染的顺序也是从上到下,下载和渲染是同时进行的。

2、在渲染到页面的某一部分时,其上面的所有部分都已经下载完成(并不是说所有相关联的元素都已经下载完)。

3、如果遇到语义解释性的标签嵌入文件(JS脚本,CSS 剑 敲创耸盜E的下载过程会启用单独连接进行下载。

4、并且在下载后进行解析,解析过程中,停止页面所有往下元素的下载。

5、样式表在下载完成后,将和以前下载的所有样式表一起进行解析,解析完成后,将对此前所有元素(含以前已经渲染的)重新进行渲染。

6、JS、CSS中如有重定义,后定义函数将覆盖前定义函数。

Firefox处理下载和渲染顺序大体相同,只是在细微之处有些差别,例如:iframe的渲染

如果你的网页比较大,希望部分内容先显示出来,粘住浏览者,那么你可以按照上面的规则合理的布局你的网页,达到预期的目的。

JS的加载

不能并行下载和解析(阻塞下载)

当 引用了JS的时候,浏览器发送1个jsrequest就会一直等待该request的返回。因为浏览器需要1个稳定的DOM树结构,而JS中很有可能有代 码直接改变了DOM树结构,比如使用 document.write 或 appendChild,甚至是直接使用的location.href进行跳转,浏览器为了防止出现JS修改DOM树,需要重新构建DOM树的情况,所以 就会阻塞其他的下载和呈现.

为了更清楚的显示页面元素的加载顺序,动手写了一个程序,程序对页面中的每个元素都延迟10秒。

程序的位置在见附件。

首先查看TestHtmlOrder.aspx这个页面,使用HttpWatcher来检测页面元素的加载。

从下面的图中可以看到加载顺序。

IE首先加载了主页面TestHtmlOrder.aspx,

下载了主页面后,页面首先显示的是“红色剑灵”、“蓝色剑灵”几个字,但此时显示的是只是黑色字体,没有样式,因为样式还没有下载下来。

接下来页面中的标签是JS标签,属于嵌入文件,因此IE需要将其下载下来。这有两个文件,虽然IE同时能够和WebServer建立两个链接,但是此时并没有使用两个连接,而是使用一个连接,在下载完成后,接下来才下载另外一个文件。

究其原因,是因为JS包含了语法定义,在第二个文件里面的函数可能用到了第一个文件里面的变量和函数,IE没有办法判断,或者需要很耗时的判断,才 能判断文件下载的先后顺序。而在解释方面,IE对JS文件是下载一个,解释一个(可以执行文件TestJsOrder2.aspx)。如果先下载的是第二 个文件,此时就会发生解释错误。因此需要开发者自己在放置JS文件位置时,按先后顺序放好,IE依次下载进行解释。后面的函数覆盖前面的函数定义

在下载完成后,我们看到helloWorld,helloworld2,开始顺序执行。而此时字体的样式表和图片仍然没有下载下来。

在helloWorld,helloWorld2执行过程时,此时页面停留在函数执行的中断点(alert部分)。此时IE并没有去下载CSS的文件。由此说明JS函数的执行会阻塞IE的下载。

接下来我们看到CSS文件的下载也是使用了一个连接,也是串行下载。其串行下载的原因和JS串行下载原因是一样的。

在两个CSS文件下载过程中,我们看到“红色剑灵”,“蓝色剑灵”依次变为红色和蓝色,两者颜色的转换时间相差在10秒,说明样式文件和JS文件一样是下载完一个解析一个的。

现在转到TestCssOrder.aspx看一下,可以看到 开始时“红色剑灵”,“红色强壮剑灵”,显示为红色,过了10秒“蓝色剑灵”显示为蓝色,再过10秒,“红色强壮剑灵”字体变粗了,同时“红色强壮剑灵 2”开始出现。在刚开始“红色剑灵”,“红色强壮剑灵”显示红色时,第三个样式还没有下载下来,此时IE使用已经下载到样式对上面的元素渲染了一遍,此时 虽然“红色剑灵”,“红色强壮剑灵”样式定义不同,但是显示效果一样。第三个文件下载后,此时IE又重新对“红色强壮剑灵”渲染了一遍,此时其变为加粗, 以上所有的文件加载并且渲染完成后,开始渲染下面的标签“红色强壮剑灵2”

有一点需要证明:在IE使用样式对标签进行渲染时,是不是停止了其他页面元素的下载?原来我想通过加长渲染时间(利用滤镜,将标签元素数目增大)来检测,不过没有验证成功。只是从JS函数的执行推断CSS的渲染也是如此。

接下来看到的是图片文件下载,此时看到的是两个图片同时开始下载,而且是下载完成后,立即在页面上开始显示,直到所有的图片下载完成。

注:一个测试文件在网络传输上所花费时间的办法。

首先需要明白检测中w ait值的意义:wait=服务器所花时间 + 网络时间

服务器所花时间我们可以用Thread.Sleep(10000);来让其休息10s,

比如这个:

由此大概可以计算出 10.002-10=0.002秒,这就是大概在网络上所花的时间。