欢迎各位兄弟 发布技术文章

这里的技术是共享的

You are here

十秒钟内识别十种网站性能问题

shiping1 的头像

用户使用网站,就像一个女神好不容易来了兴致和一个屌丝约会,如果屌丝迟到让女神等上半天,那么这个屌丝就只好一辈子屌丝了。毫无疑问,在互联 网上,网站是屌丝,用户们是女神,如何让网页迅速呈现在用户面前是众屌丝们必须要注意的问题。假设某屌丝跟女神约会迟到了,这个时候需要迅速找到原因定位 问题,然后才能解决问题向下一个女神进攻。
如何识别站点的性能问题呢,事实上不是太难,你只需要一个可视化页面加载过程的工具就行了,这个工具呈现出来的内容叫做瀑布图。如果你有firefox, 那么装上一个叫做firebug的工具就OK,如果你用Chrome,直接按F12即可。当然还有一些网站性能分析站点也会提供这些工具,例如 webpagetest.org。好了,下面一个个介绍十种性能问题的模式:

 

1、后端性能太差


后端是啥?后端就是你网站的Web服务端,包括Web服务器(apache,nginx)、动态脚本(php,jsp,cgi)和数据库等。上图中第一行 明显比其他行要长的多,这种情况一般是后端问题影响的性能。正常情况下,第一行要非常的短。瀑布图中,第一行往往代表整个网页的基础页请求,也就是页面的 骨架,大多数情况下基础页是由后端动态生成的。其他行代表页面元素请求,也就是图片、JS、CSS等,通常这些请求是静态的,所以第一行远远长于其他行证 明动态请求慢于静态请求,也就是后端性能太差造成的。

 

2、请求数太多


瀑布图中,一行代表一个http请求,如果一个瀑布图有太多太多行,滚动了好几屏都看不完,那么,这个站点的请求数就太多了。极端一点说,一个站点的请求 数越少越好,毕竟http请求是很耗时的一件事情,看看各大搜索引擎的首页就知道了。但是并不是所有页面都需要像搜索引擎那样简洁的,个位数的请求不大可 能,那最好也别超过百位数,尽量五十以下吧。可以使用诸如JS合并、CSS合并、CSS精灵图片、数据URI等技术来降低请求数。

 

3、单一坏请求


看一下上图箭头所指的请求,它比所有其他请求都长,而且还长出至少一个数量级,和其他请求相比,这个请求就显得有点“坏”。单一坏请求可能是一个图片、 JS、CSS,或者是指向第三方网站的任何请求,虽然这只是一个请求,但是它足以拖慢你整个页面的加载速度。导致这个问题的原因有很多种,可能是网络问 题、可能是请求本身过大,总之,找到原因,干掉它。

 

4、网络层问题(DNS或者连接问题)


仔细看一下一个单独的http请求,他们会分为好几段,分别是域名解析、建立连接、发送请求、等待响应和接收数据几个阶段。理论上域名解析和建立连接应该 占用的时间很小才对,主要的时间应该用在后面几个阶段上。上图中,蓝色和绿色分别代表域名解析和建立连接,可以看出几个请求中花费在网络层上的时间太长 了,超过总时间的一半还要多。网络层时间过长除了可能和底层网络有关之外,还可能和你站点的服务端性能有关。当然,如果这种情况发生在向第三方站点发送的 请求上(实际上也经常发生),估计你就需要考虑是不是要取消或者更换某些站点功能从而避免这样的请求了。

 

5、接收数据时间过长


第四点中提到,http请求的大部分时间应该花在后面几个阶段,比如等待响应和接收数据。但是,如果接收数据的时间太长了,长到数百毫秒甚至以秒计算的时 候,那也是有问题的。这种情况一般是因为下载的内容太重了,例如大图片、大脚本等。这类问题可以使用GZIP压缩、图片压缩或者JS/CSS的 minify等手段来解决。

 

6、JS阻塞请求


理想中,瀑布图应该是平滑的一路排下来,相邻请求之间的时间差不应该太大。但是经常会出现上图红框中的情况,两个请求之间开了一个很大的口子。这种情况通 常是JS造成的,因为JS具有阻塞加载的特性,所以应该尽量想办法让js无阻塞异步的加载。本站的JS可以使用例如require.js之类的AMD的类 库,第三方JS也应尽量将引用放到页面最后,或者使用其他办法强制异步加载。

 

7、错误请求


每一个http请求都是很耗时间的,当你的站点中出现错误的请求就意味着这个请求对于页面展现和用户体验没有任何帮助,所以尽量不要出现错误请求。查看一 个请求是不是有错误可以从http状态码上查看,状态码为4xx的请求表示浏览器端犯了一些错误导致服务器不能正常处理,最常见的就是404 not found。状态码为5xx的请求表示服务器端在处理请求的过程中发生了一些错误,最常见的就是500错误,服务端程序发生故障。

 

8、顺序问题

默认情况下,瀑布图从上到下的请求顺序也表示了请求的先后顺序,在上面的请求是先发起的。对于一个页面而言,应该让重要的请求先发起,不重要的留在 后面。比如,企业网站的公司logo应该先发起请求,而页面上的一些“分享到微博”之类的按钮和站点访问统计代码应该后发起请求,尽量保证用户看得到的重 要的内容先发起请求。

 

9、“吵闹”的第三方请求


为了让用户分享你的网站内容,所以你给自己的网站装了一个分享插件,可以一键将你的内容分享到微博、空间、人人等等各个社交网站,但是该插件发起了数十个 请求,在你的网站加载瀑布图中,这些第三方请求显得很“吵闹”。这些请求大大增加了你页面加载的请求数,降低了用户体验,所以想办法换一个“不吵”的插件 也许是个好办法。

 

10、开始渲染时间太长

这个问题从瀑布图里看不出来,但是你可以直观的感受到。从你在地址栏里输入网址敲回车开始,到你看到屏幕上出现第一部分网页内容,这中间空白屏幕持 续的时间大致可以理解为开始渲染时间。哪怕用户第一眼只看到了一个logo,他也知道页面加载时OK的,他会继续等下去。如果开始渲染时间太长,用户一直 看着空白屏幕,他很有可能会关掉这个标签页然后打开竞争对手的网站了。开始渲染时间同样是越短越好,瞬间呈现才会让你的女神感觉很爽。

 

(本文主要参考国外著名性能优化网站yottaa的官方博客中的一篇文章,原本打算直接翻译,无奈本人英语太差,就参考着写一下大意再加上自己的一 些理解,文中图片也来自原文,英文好的同学就直接移步英文原文好了:http://www.yottaa.com/blog/bid/248349 /How-To-Identify-10-Performance-Patterns-in-10-Seconds)

来自 http://www.zhujianfeng.info/?p=180

普通分类: