上周收到在线反馈性能问题：“浙江客户xxx的报告显示超过20秒，小明阅读相关界面并在2秒内回复秒，希望能协助排查，听了这简短的描述，我猜想可能是客户机房的网络问题，为什么这么说呢？从描述中，我提取了几个关键信息，比如“比如不是所有客户”和“后台响应很快”。我的感觉好像是机房出口的带宽满了。当然这只是猜测，还需要具体的证据.初步调查“信任但需要确认”，虽然从研发口中得知后台响应很快，但为了排查问题，还是让相关账号过来点了myse如果。我还检查了后台的访问日志。确实不慢。Network->奇怪发现服务器的定时，有一个提示会停留20s左右“CAUTION:requestisnotfinishedyet!（注意：请求还没有完成）”，然后耗时指标会可以显示，但是耗时不高。这个样子似乎和我猜测的机房出口带宽满了不谋而合。接下来就是破茧成蝶，确认客户的机房网络确实有问题，提供实施的证据反馈给客户，客户再去信息管理部。然后去跟接线员打招呼（跟toG客户打交道一定要谨慎，经常会惊动链条上的一个人）。由于本人不是专业的网络工程师，对于网络问题只能根据自己的两手刀经验进行一些诊断。如果有什么不对的地方，请指正。ping-n50xxx.com我先用ping看看有没有丢包。结论是网络良好，没有丢包。接下来我用Wireshark抓包分析了一下，从发送请求到收到本机响应的时间确实在2秒以内。看来报表显示慢跟网络没有关系，还需要继续深挖原因。强烈推荐大家学习一下Wireshark，真是网络学习和排错的一把利剑。我怀疑之前提出的所有疑惑都在后端领域。现在经过一轮排查，矛头指向了前端，继续挖下去。看了下报表页面的js代码，逻辑很简单，就是ajax查询数据，然后调用前端框架的setData方法。哪些js代码拖慢了整个页面的渲染速度？我什至怀疑是否触发了jquery框架中的错误。为了证实这一点，我将请求数据部分从jquery切换到最原始的XMLHttpRequest，这仍然很慢。如果浏览器能够记录下页面渲染过程中发生的事情，以及每个阶段的耗时分布，那么排查问题就会方便很多。想到了之前用来排查后端性能问题的skywalking、jaegertracing等链接跟踪工具，用起来得心应手。最后借助搜索引擎找到了chrome的性能。请搜索“chrome前端性能优化工具”了解更多。真的好用，不到两分钟就找到了性能瓶颈。开始采集F12-Performance->点击开始录制->刷新页面->等待页面渲染完成->点击停止录制查看调用树点击上图红框部分的CallTree查看调用环节和每个节点的耗时，关注一下耗时占比较大的调用栈，如下图，拖慢整个页面渲染速度的罪魁祸首就是这两个函数在jCommon.js中设置表格样式。这两个函数的触发时机在jCommon.js的$(function(){}中，属于通用逻辑，其他客户不受影响的原因是其他客户没有开启个性化设置form，所以不执行，大致看了一下逻辑，递归+循环调用太多，遇到复杂（行列合并、嵌套）、数据量大的表简直就是噩梦。细节我就不多说了，关键点，解决办法就是“让专业的人做专业的事”，因为我前端不行，所以就把铲除这个问题的任务交给了前端同学。这段代码一定要优化，太耗性能了，同时针对目前的问题，我也给出了建议，我在当前的报表页面暂时去掉了这段逻辑，本意是为了提升用户体验，但是现在看来已经很严重了y影响了可用性。总结一下，通过一个简单的性能问题，说说笔者调查的思路和中间一些工具的使用，最后利用浏览器的性能分析工具找到前端问题代码。对于不熟悉的领域，一个好的工具可以降低考察的门槛，达到事半功倍的效果。
