浏览器调试工具网页性能分析中的使用

IE、chrome、firefox等按F12可以掉出它们自带的页面调试工具,作为测试当然不能非常精通在页面上修改样式,调试页面jsp,js,但是却可以很轻松的使用它来分析网页的性能优化项。

基础篇

现在的网络模式粗糙的理解,就是BS结构(客户/服务端),一个负责请求展现,一个负责响应提供内容。这个过程包括底层网络的三次握手,TCP/IP的通信巴拉巴拉的一些列低级的我们不需要了解过细的活动(大牛除外),这些活动浏览器会有记录。

客户端/服务器传输过程很多内容,可以阅读深入理解HTTP协议、HTTP协议原理分析

网络通信的链接四个基一步骤:
1、浏览器与服务器建立连接;这个建立链接,简单说通信双方需要相互确认对方的存在以及合法身份,所以会有TCP的3次握手
2、浏览器向服务器请求文档;简单理解就是url(统一资源定位符的英文缩写),资源定位符自然请求过去就是在请求文档咯,泪崩吧。
3 、服务器响应浏览器请求;把资源吐出来给浏览器,浏览器接收并显示。
4、 断开连接。

在客户端和服务端通信的过程中,还需要了解:
1、客户端请求方法,最常用的: GET,POST。get简单说,直接拿资源,服务器拿现货提供;post简单说,附带上请求信息去告诉服务器自己要拿的东西,服务器现炒现卖。
2、动态资源和静态资源:简单的说动态资源就是服务器上非现成的资源,如某商品的列表订单信息(有人买卖自然的变化的,需要实时去查);静态资源就是现成的,如各种css\html\js\jsp文件。
3、缓存。静态资源可以缓存来加快网络二次请求的响应速度。缓存也是可以在服务器上(至少apache可以)控制过期。
4、XHR(XMLHtmlRequest),一种结构化的对象,用于在后台与服务器交换数据。可理解为服务吐出来的动态资源的一种形式。

实践篇

以下,记录一次使用浏览器调试工具分析我们商城后台各类资源加载性能,发现问题,促成问题改善和优化。

发现问题

虽然是主打移动微信电商,但是商户的管理端使用的还是PC电脑,浏览器,每天测试商户后台,我有个习惯,就是使用chrome的第三方插件清理缓存(当然是关闭浏览器自动的清),一次发版前,产品+前端+后端一起把登陆主页给优化了,简单的说界面比上一个版本更好看,内容也更丰富。当然这个是优化项,没有提交给测试这边验证。但是……我发现这页面加载很久,开始因为是网络和测试服务器性能不行也没深究,但是多几次我就觉得不太对劲,F12打开一看,加载10s+了,这性能自然是不行的。然后反馈研发,推动修改。

分析问题

下面以另一个商品管理页面作为实例(写文章的时候还没修改),手动清空浏览器缓存,打开F12,刷新并访问首页。
非常明晰的时间加载曲线展现,如下图(仅示意):
这里写图片描述
图中显示了2个时间消耗大户都在800ms以上。
点击开文件的响应内容包含了若干object,都是按商品的productID分类的,这个数据是从后台数据库查询得到的动态数据(xhr),点开一个object的内容如下:

1
{"pId":5989,"name":"聚实惠测试商品01","status":"shelve_on","imgUrl":"http://×××××××××××.aliyuncs.com/sgc/200015/image/145c1974fdaa4a9f81d20614a4af1327.jpg","shopId":null,"inventory":1464,"maxPrice":1.11,"minPrice":1.11,"createdWhen":"2016-12-01 11:10:55","modifyWhen":null,"salesNum":0,"pv":2,"uv":2,"itemCatId":null,"shortDesc":"聚实惠测试商品01","salesLimited":null,"saleStartTime":null,"saleStartSeconds":null,"stockReduceType":null,"freightType":null,"shippingFee":null,"shippingTemplateId":null,"displayInventory":false,"displaySoldQty":false,"shareImg":null,"shareTitle":null,"shareContent":null,"imgs":null,"delSkuIds":null,"productCode":null,"modifyWhenDate":null,"productSizeTemplateId":null,"taxRate":null,"toInactive":false,"spec":null,"maxquto":121.00,"minquto":121.00,"onStatus":null,"offStatus":null,"selectedIds":null,"defaultImg":null,"indexCode":null,"selIds":null,"groupId":null,"sortNo":null,"skus":null,"querySelInType":null,"commissionRate":0.2000,"commissionTemplateId":null,"notQueryPids":null,"imgShape":null,"orderStatus":null,"oldStockType":null,"shelveOnWhen":null,"shelveOffWhen":null,"minFrontPrice":null,"minBackPrice":null,"maxFrontPrice":null,"maxBackPrice":null,"qrCodeUrl":"http://XXXXXXXX200015/product/productDetailPage?pId=","groupIds":null,"statusComments":"上架","rectImgUrl":"1abc808b34884fcbb78b187e533bfaa1.jpg","activityId":null,"activityUniqueId":null,"activityName":null,"fansQuantity":null,"fansCount":null,"activityStartTime":null,"activityEndSeconds":null,"activityLabel":null,"activityLabelStyle":null,"activityMinPrice":null,"activitySalesLimited":0,"activityRemark":null,"noticeActivityId":null,"noticeActivityUniqueId":null,"noticeActivityName":null,"noticeActivityStartTime":null,"noticeActivityEndSeconds":null,"noticeActivityLabel":null,"noticeActivityMinPrice":null,"noticeActivitySalesLimited":0,"groupActivityId":null,"groupActivityUniqueId":null,"groupActivityName":null,"groupActivityStartTime":null,"groupActivityEndSeconds":null,"groupActivityLabel":null,"groupActivityLabelStyle":null,"groupActivitySalesLimited":null,"groupActivityRemark":null,"fulfilActivityLadders":null,"fulfilActivityDiscountList":null,"fulfilActivityPointsList":null,"fulfilActivityCouponList":null,"crowdActivityLadders":null,"quantityLimited":0,"productGivePoints":null,"productSizeRowString":null,"productSizeRowData":[],"pids":null,"packageDiscountAmout":null,"imprestPrice":null,"imprestFrontPrice":null,"imprestBackPrice":null,"currentPrice":null,"crowdCurrentPersons":null,"crowdMaxPersons":null,"returnImprest":null,"payLimitHours":null,"showCartFlag":true}

商品列表中展现的内容最多不会超过20个属性(商品名称及ID 价格 访问量 总库存 总销量 创建时间),反回来的object里面怎么会有那么多内容呢?然后大概一看,查了一大堆null的空数据出来。说明在执行查询操作的时候多查了不需要的内容。然后,作为一个测试,这个模块是谁开发的,找到他询问,得知他原来的方法已经被很多人修改过……于是不禁想到,研发都很懒,有现成的他是不会自己去搞的,复用人家的方法(一个方法只做一件事的原则被彻底放弃或者遗忘),改改……经过多轮功能和版本的迭代,一个曾经单纯的干净十足的方法,变成了一个拖泥带水的方法……

解决问题

首页加载慢的问题是如何被解决的?
1、我发现问题,向对应研发提出性能慢的问题;研发表示没有办法,是某某地方查询数据库慢导致的,现在有点忙。我告诉他我的想法,作为首页,性能不能太低,否则会被用户觉得产品low。他同意但是事情太多,没有说要马上解决。基于发现的这个性能问题,我把后台快速的清理一遍,看是否还有类似的情况,清理完毕,问题提交到了bug管理系统,作为一个重要但不紧急的事项。
2、在我反馈后大概2小时,产品经理发觉有点慢,过来找我问情况,我告诉他原因,和我对这个问题的处理方式,又说了我的想法。产品经理应该是认同的,迅速口头把问题反馈给老大,咨询意见(这就是优秀的产品经理和蹩脚测试的区别——发版也不是理由),老大的想法和我一样。然后我继续准备发版的各项工作,研发-老大碰了一会得到解决方案。发版完成后,这个问题的修复作为hotfix被发到生产环境。性能提升到加载5s+。

商品查询sql性能问题应该如何被解决?
1、首先是代码编写原则问题,说白了是研发管理问题。没有普及科学规范的编码规范。所以这个问题要在源头上解决的话需要上升到管理层,督促开发遵守基本的代码编码规范。——开会,宣贯,清查,批评,通报批评,惩罚。。。
2、修复该问题。
3、类似遗留的代码需要清理。有一定工作量,需要和开发任务平衡。