web前端性能优化

1．理所当然我们是这样想的

关于减少http请求数,是前端开发性能优化的一个非常重要方面,所以在基本所有的优化原则里,都有这一条原则:减少http请求数.

先不考虑其他的,我们先考虑为什么减少http请求可以优化性能.

减少http请求有这样几个优点:

(1)减少DNS请求所耗费的时间.

且不说对错,因为从基本来说,减少http请求数的确可以减少DNS请求和解析耗费的时间.

(2)减少服务器压力.

这个通常是被考虑最多的,也是我用来讲解给别人听的最大理由,因为每个http请求都会耗费服务器资源,特别是一些需要计算合并等操作的服务器,耗费服务器的cpu资源可不是开玩笑的事情,硬盘可以用钱买来,cpu资源可就没那么廉价了.

(3)减少http请求头.

当我们对服务器发起一个请求的时候,我们会携带着这个域名下的cookie和一些其他的信息在http头部里,然后服务器响应请求的时候也会带回一些cookie之类的头部信息.这些信息有的时候会很大,在这种请求和响应的时候会影响带宽性能.

2．让我们来一一道来

(1)什么是DNS请求和解析呢?

简单来说,例如:www.taobao.com这样一个url,其中www部分被称为主机名(hostname),taobao这部分则是二级域,com则是一级域,如果是这样一个网址:www.ali.taobao.com.那么ali就是三级域.

当我们去请求一个url的时候,首先会到本地服务器里去寻找缓存中是否有解析结果,如果没有解析结果,就去根域名服务器请求,根域名服务器返回给本地域名服务器一个所查询的域的主域名服务器的ip地址,然后我们再去请求刚才返回的ip地址的域名服务器,然后返回下一级域名的ip地址,直到我们找到域名中所指的服务器ip,然后将结果缓存起来供下次使用,并返回此结果.

一个第一次请求的url的DNS解析过程可能耗费是很高的.但是解析一次之后,结果就会被缓存起来,之后再请求的时候就不用走上面这一套复杂的解析过程了.

关于一个正常的DNS请求到底会耗费多少时间,这个没有定论,要看网速状况和地域,但是考虑一个dns解析解析过后会被缓存起来,像淘宝这样的大网站,来的都是回头客,我们是否可以忽略DNS解析花费的时间呢?

在前端优化里还有一个优化方法,那就是增加hostname,例如,淘宝图片服务器,分为img01，img02，img03等主机名,这样做是因为考虑到浏览器对同一个域名下同时进行的http连接数的限制,具体可以见下表:.然后我们在一个页面里的图片放在不同的hostname下,这样就可以同时下载多个图片了,浏览器http连接数的限制可以被缓解一下,但是这样做的后果就是yslow评分会下降,因为yslow将DNS请求看的比较重要.

BrowserHTTP/1.1HTTP/1.0 IE 6,724 IE 866 Firefox 228 Firefox 366 Safari 3,444 Opera 9.6182

在此,就要引出我们想讨论的东西,为什么yslow评分在合理的情况下分数反而会低,因为yslow只是一个机器程序,它并不知道我们的网站是什么类型的,是何种规模的,是内容型还是应用型,所以我们可以用异步加载的方式来欺骗yslow对于dom节点的评分,但是异步加载真的适合我们的网站么?同样,别人写了一篇文章,出了一个原则,一个最佳实践,但是你确定他说的情况适合你的情况么?网站有大有小,大小不同,需要考虑的东西也就不同.

为什么对于淘宝的图片来说,使用不同的hostname是个更优的方案呢?

首先,因为淘宝网的特殊性,淘宝网大多数访问者都是回头客,他们电脑里大多缓存着dns记录.这种情况,如果是小网站或者新兴网站可能要考虑,因为新用户比较多,可能dns请求的消耗更大一些,而且第一印象对于这些网站来说更为重要.

再者,淘宝里的图片很多,一个页面里通常会用到几十张甚至上百张图片,在这种情况下,我们更需要突破浏览器的http连接数的限制,以便加快加载速度,这时候加载速度的考虑优先级远远高于DNS的影响,而yslow中对于DNS的着重考虑可能更偏向中小网站,图片比较少的网站.

对于DNS请求或者tcp(tcp握手之类的也会消耗请求时间)请求之类的分配和解析的消耗,还有一个办法是keeplive,让你的链接保持keeplive,这样可以只建立一次链接,然后传输多个文件,可以有效减少建立连接的时间.

(2)减少服务器压力

过多的http请求对于服务器来说是很危险的,如果你的服务器不是很强,请把这一条考虑放在第一位,其他的优化策略都只是优化,而这里涉及到的是服务器,你要保证你的服务器能正常运转.

当然如果你是在淘宝的话,你就可以安心坐下来跟一群牛人谈论为什么要忽略http对服务器的影响,因为我们要记住:我们是前端开发工程师,我们是在做前端优化,后台和我们无关,因为我们有足够强大的技术支持和硬件支持,当网站的技术发展到一定程度的时候,我们的关注点应该向用户那里偏重,因为用户看到的才是我们最终要展示的,用户感受到的体验和速度才是我们要达到的速度,后台我们做的再快,前台呈现慢了,我们的服务器消耗少了,省钱了,但是用户却因此抛弃了我们,一切都是白费.所以,当后台足够支撑你不用你去考虑后台压力的时候,那就安心考虑如何做好前台的工作吧.

Yslow真的是一个误导人的工具,只要我们按照它的原则对网站进行优化,肯定最后可以拿到高分来欺骗老板,但是对于有些场景,这些优化往往是一种对性能的破坏,例如淘宝网的商城首页,为了提高Yslow评分,所有的图片都采用了一个hostname,分数提高了,但是并行加载少了,不过商城首页都是异步渲染和异步加载的,所以这种影响看起来并不明显.

商城首页有很多针对yslow的优化点,当然大多数优化是正确的,例如:导航那里,本来是全部写在页面里的,不要小看那个导航,里面有N个链接节点,以至于从浏览器里复制源代码的时候浏览器会卡死,因为字节数太多了,这里yslow肯定不会饶过的,后来我们把导航做成了异步加载的,评分理所当然上去了.但是这是淘宝网,我们有足够的速度来提供足够的用户体验.如果你的服务器提供不了这种速度,也承受不了这种频繁的异步请求的话,这种优化就要慎重了,延迟可能造成导航不可用.这也是针对场景来协调的.

淘宝现在在广泛部署CDN,CDN可以给我们提供足够的后台资源保障,在CDN和后台环境不断万善的情况下,考虑重点应该更加专注于前台传输速度和展现解析速度的提升.

(3)合并脚本和样式?

其实在前一篇文章里的那段讨论也是对于不同应用场景的不同考虑,

减少http请求数的一个方法,对于前端来说,那就是合并脚本和样式文件,称为combo,通过将多个文件合并成一个文件,然后一次性传输到客户端,这样可以减少http请求,的确是个有效的方法,甚至对于一些特殊的页面,例如首页,我们把样式和脚本都写在了页面里,根本没有分离出来,他们不会产生http请求,当然,也不会被缓存,这是被牺牲的代价.

为什么我们要这么做,因为首页的访问量很大?这样可以有效减少http请求数?恩,这只是一部分原因,的确这样做有这样的好处,而且对于assets服务器不够强大的网站来说,在并发量大的首页上实行这一套是很有效的.

但是,淘宝访问量最大的页面并不是首页,而是detail页面,也就是商品详情页!

这才是我们讨论的重点,为什么首页采用combo甚至写在页面里,而detail则按照正常的样式和脚本来引用.首页是类似静态的页面,detail则是应用型的.首页没有脚本,依然可以起到导向的作用,但是detail页脚本没有运行起来的话,甚至无法购买商品.

其实在这里这样讨论并不能明显看出问题所在,因为淘宝在这些方面也不是很成熟,detail页引用了大量脚本和样式,很多内容是多余的过期的.

这从本质上来说代表两种网页类型,一种是内容型,一种则是应用型.对于内容型的网站,脚本并不是很重要(甚至样式),因为没有脚本,用户仍然可以浏览页面,只是可能有些效果看不到而已,所以我们可以把脚本合并起来,一起放在body底部,在页面内容都加载完后,再一次性加载进来.而对于应用型的网页,让应用跑起来才是最重要的,因为没有应用这个网页就变得没有意义了,这时候,按需加载脚本是一种趋势,我们需要先把应用的基本框架和功能按需加载进来,让它们分别运行起来,而不是一起等脚本加载完再一起初始化,我们需要应用能够快速响应用户,

而且还是说到CDN,当CDN变得足够强的时候,连接数已经不是瓶颈,我们应该更多考虑怎么让网页更快的展现给用户,对于无需脚本也可以提供服务的内容型的网页,将脚本放在页面底部,合并起来(减少连接数,我们仍然需要减少连接数,在不需要太快的使用脚本的情况下),而对于应用型的网页,我们需要尽快让功能运转,甚至让他们一部分一部分按优先级初始化,这时候就要将脚本分开,按需加载.

(4)减少http请求头

http头是个庞大的家伙,你打开taobao.com的首页,alert一下document.cookie,会发现淘宝网的cookie是如此庞大,甚至比小型网页都大,每次你请求淘宝的服务器都会往返一次这些数据,还有一些其他的头部信息,占用的空间也不小,可想而知这种消耗有多大.

然后其实自从用了CDN,这一切都无需考虑太多,因为CDN和淘宝主站不在一个域名下,cookie不会互相污染,而CDN的域名下基本是没有cookie和头部信息的,所以每次请求静态资源的时候,不会带着主站的cookie到处跑,而只是传输资源的主题内容,所以这对于性能的影响在使用cdn之后会变得很小.但是如果你的静态资源服务器和主服务器在一个域名下,那就要控制好cookie和其他头部信息的大小了,因为每次传送都会传送他们.

最后

总之,优化原则不是绝对的,对于不同的场景应该考虑不同的侧重点,别人的解决方案对于你来说不一定是最优的,应该针对自己的网站规模和类型进行适度的优化,不能盲目追求标准和最佳实践.