用YSlow分析我们页面(完整版)

YSlow是yahoo美国开发的一个页面评分插件,非常的棒,从中我们可以看出我们页面上的很多不足,并且可以知道我们改怎么却改进和优化。

仔细研究了下YSlow跌评分规则。

主要有12条:

1. Make fewer HTTP requests 尽可能少的http请求。。我们有141个请求(其中15个JS请求,3个CSS请求,47个CSS background images请求),多的可怕。思考了下,为什么把这个三种请求过多列为对页面加载的重要不利因素呢,而过多的IMG请求并没有列为不利因素呢?

发现原来这些请求都是可以避免的。

继续阅读“用YSlow分析我们页面(完整版)”

浏览器的重绘[repaints]与重排[reflows]

在项目的交互或视觉评审中,前端同学常常会对一些交互效果质疑,提出这样做不好那样做不好。主要原因是这些效果通常会产生一系列的浏览器重绘和重排,需要付出高昂的性能代价。那么,什么是浏览器的重绘和重排呢?二者何时发生以及如何权衡?如何在具体的开发过程中将重绘和重排引发的性能问题考虑进去?本文期待可以部分解释以上三个问题。

浏览器从下载文档到显示页面的过程是个复杂的过程,这里包含了重绘和重排。各家浏览器引擎的工作原理略有差别,但也有一定规则。简单讲,通常在文档初次加载时,浏览器引擎会解析HTML文档来构建DOM树,之后根据DOM元素的几何属性构建一棵用于渲染的树。渲染树的每个节点都有大小和边距等属性,类似于盒子模型(由于隐藏元素不需要显示,渲染树中并不包含DOM树中隐藏的元素)。当渲染树构建完成后,浏览器就可以将元素放置到正确的位置了,再根据渲染树节点的样式属性绘制出页面。由于浏览器的流布局,对渲染树的计算通常只需要遍历一次就可以完成。但table及其内部元素除外,它可能需要多次计算才能确定好其在渲染树中节点的属性,通常要花3倍于同等元素的时间。这也是为什么我们要避免使用table做布局的一个原因。

继续阅读“浏览器的重绘[repaints]与重排[reflows]”