IE、chrome、firefox等按F12可以掉出它们自带的页面调试工具，作为测试当然不能非常精通在页面上修改样式，调试页面jsp，js，但是却可以很轻松的使用它来分析网页的性能优化项。
基础篇
现在的网络模式粗糙的理解，就是BS结构（客户/服务端），一个负责请求展现，一个负责响应提供内容。这个过程包括底层网络的三次握手，TCP/IP的通信巴拉巴拉的一些列低级的我们不需要了解过细的活动（大牛除外），这些活动浏览器会有记录。
客户端/服务器传输过程很多内容，可以阅读深入理解HTTP协议、HTTP协议原理分析 ，
网络通信的链接四个基一步骤：
1、浏览器与服务器建立连接；这个建立链接，简单说通信双方需要相互确认对方的存在以及合法身份，所以会有TCP的3次握手 ，
2、浏览器向服务器请求文档；简单理解就是url（统一资源定位符的英文缩写），资源定位符自然请求过去就是在请求文档咯，泪崩吧。
3 、服务器响应浏览器请求；把资源吐出来给浏览器，浏览器接收并显示。
4、 断开连接。
在客户端和服务端通信的过程中，还需要了解：
1、客户端请求方法，最常用的： GET，POST。get简单说，直接拿资源，服务器拿现货提供；post简单说，附带上请求信息去告诉服务器自己要拿的东西，服务器现炒现卖。
2、动态资源和静态资源：简单的说动态资源就是服务器上非现成的资源，如某商品的列表订单信息（有人买卖自然的变化的，需要实时去查）；静态资源就是现成的，如各种csshtmljsjsp文件。
3、缓存。静态资源可以缓存来加快网络二次请求的响应速度。缓存也是可以在服务器上（至少apache可以）控制过期。
4、XHR（XMLHtmlRequest），一种结构化的对象，用于在后台与服务器交换数据。可理解为服务吐出来的动态资源的一种形式。
实践篇
以下，记录一次使用浏览器调试工具分析我们商城后台各类资源加载性能，发现问题，促成问题改善和优化。
发现问题
虽然是主打移动微信电商，但是商户的管理端使用的还是PC电脑，浏览器，每天测试商户后台，我有个习惯，就是使用chrome的第三方插件清理缓存（当然是关闭浏览器自动的清），一次发版前，产品+前端+后端一起把登陆主页给优化了，简单的说界面比上一个版本更好看，内容也更丰富。当然这个是优化项，没有提交给测试这边验证。但是……我发现这页面加载很久，开始因为是网络和测试服务器性能不行也没深究，但是多几次我就觉得不太对劲，F12打开一看，加载10s+了，这性能自然是不行的。然后反馈研发，推动修改。
分析问题
下面以另一个商品管理页面作为实例（写文章的时候还没修改），手动清空浏览器缓存，打开F12，刷新并访问首页。
非常明晰的时间加载曲线展现，如下图（仅示意）：
图中显示了2个时间消耗大户都在800ms以上。
点击开文件的响应内容包含了若干object，都是按商品的productID分类的，这个数据是从后台数据库查询得到的动态数据（xhr），点开一个object的内容如下：
{"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、类似遗留的代码需要清理。有一定工作量，需要和开发任务平衡。