网站性能优化

因为某个页面实在加载的太慢了，所以就想好好的定位下慢的原因。 这里我使用了 Chrome DevTools 的 Performane 面板来进行网页性能分析，它可以记录和分析应用在运行时的所有活动，是发现应用中可觉察性能问题的最佳位置。 Command+Shift+N 打开 Chrome 隐身浏览器，隐身浏览器可排除扩展程序对 Performane 分析的干扰。Command+Opiton+I 打开控制台，切换到 Performance 选项卡。 如何记录？ 按 record 键开始记录，操作完或页面加载完后按暂停停止记录。按 reload 键重新载入页面并记录，会在载入完成后自动停止记录。停止记录后Performance面板会自动载入分析结果，如下所示： 每个区域的作用： FPS（frames per second）: 每秒帧数。这个是用来分析动画的一个主要性能指标。绿色竖线越高，FPS越高。FPS图表上的红色块表示长时间帧，长时间帧的位置很可能会出现卡顿。能保持在60的FPS的话，那么用户体验就是不错的。下面有个Frame区域，鼠标划上去可以看到FPS的具体数值。CPU：CPU资源。此区域图表指示哪些类型的事件消耗CPU资源，不同颜色块表示的含义跟Summary是一样的。Network：显示了网络请求的顺序及耗时，每一个彩色条代表一个资源请求，彩条越宽，请求的时间越长。Main：展示了主线程运行状况。X轴代表着时间。每个长条代表着一个event。长条越长就代表这个event花费的时间越长。Y轴代表了调用栈（call stack）。在栈里，上面的event调用了下面的event。Summary：每种类型事件的执行时间。FPS：看FPS这里绿条的高度很低，并且出现了红条，Frame这里的帧数显示红条部分几乎为0，可以说相当卡顿了。CPU：脚本执行的时间占了大头，有10s之长，这个在后面需要着重分析下。 Network: 所有资源请求都会显示在这里，一开始有两个资源并行请求，点击彩色条，下面会显示详细的资源信息。 这两个灰条，根据资源大小可以在 Network选项卡下找到对应的请求资源 绿条的请求时间就很长，点击后看到这张图片的大小有1M，压缩的空间很大。 Main：这里显示捕捉到的 JavaScript 堆栈信息。 可以直接在页面拖拽选择指定时间段，观察这段时间里的详细数据。 切换到Call Tree选项卡，也能看到详细的执行步骤及执行时间： 把执行时间比较长的部分展开，右侧有对应的代码执行位置，展开到足够细力度后就容易定位到代码的位置。我这里展开后耗时长的部分都是G2里的代码，说明我的G2图表渲染时js执行的时间是整个js里的大头，也是优化的重点。 通过上面的分析，能得到两个优化点：1、压缩图片资源，减少请求时间2、优化G2图表渲染代码，减少js执行时间 如何使用 Timeline 工具Chrome Devtool Performance使用指南

开发的原因，需要对吞吐量（TPS）、QPS、并发数、响应时间（RT）几个概念做下了解，查自百度百科，记录如下：响应时间(RT)　响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。　对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。吞吐量（TPS）　吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。　对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是nt，而往往比nt小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。QPS每秒查询率(Query Per Second)　每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。（看来是类似于TPS，只是应用于特定场景的吞吐量）。原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间公式：( 总PV数 80% ) / ( 每天秒数 20% ) = 峰值时间每秒请求数(QPS)机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器问：每天300w PV 的在单台机器上，这台机器需要多少QPS？答：( 3000000 0.8 ) / (86400 0.2 ) = 139 (QPS)问：如果一台机器的QPS是58，需要几台机器来支持？答：139 / 58 = 3并发用户数　并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。