2023-07-05
2023-06-18
2023-07-05
2023-06-29
2023-03-19
更新时间：2024-04-14 09:17:40 发布时间：24小时内 作者：文/会员上传 下载docx
2023-07-05
2023-06-18
2023-07-05
2023-06-29
2023-03-19
（下文以20_年2月A频道页面为例，均为dummy仿造后数据，也不代表整体情况）
.如何衡量性能问题严重性
衡量性能问题严重性，是为了让大家意识到优化的必要性，以及急迫性
.进入性能黑榜前几名
同.性能黑榜，不赘述
.看完全加载时长分布
见下图“可交互时长分布图”，一个记录代表一个用户。
即使不去统计，我们都能很明显的看出来，这个A频道页面：
.看时长分布比例
和开发说明问题严重性时，这个会很有代入感，比如见下图，10%的Android用户在以上，是不是可以认为他们大部分都跳失了？
.看和总体数据的对比
下图不用算都能明显发现，秒开率和 整体数据差异实在太大
.分析性能瓶颈-分析思路
首先要明确，性能分析主要是给相关页面的前端、开发同学看，给关心问题的测试同学看，所以我们可以拆分的更细节、更专业。可以先分前端、后端2个大类：
.分析性能瓶颈-前端环节
.分终端分析
业务因素（具体不表），分终端是重点。
从可交互时长、秒开率、3秒+率、5秒+率，分别分析，都能论证--支付宝端问题更明显。
.分阶段分析
下图将t1~t9 每个阶段打点情况可视化，并分析重点环节的差值（打点逻辑由前端定义）
见图2可以明显观察到：
1、接口耗时太久，且后变差明显（可以去追溯下发生了什么）； 2、LBS获取耗时很久，高于平均1倍以上，而取lbs是A频道页的关键逻辑
.分高中低端机分析
我们根据手淘的高中低端机评判标准，埋点获得数据。平均时长，高中低各自占比，以及低端时长分布（也可选中高端）。下图可发现，低端机比例很低（需要思考是否有必要重点优化），但低端机超过3秒以上的比例远高于其他的（和总体的完全时间分布对比） 。
.其他分析
包括：机型、系统等，可做参考
.分析性能瓶颈-后端环节
.后端接口分析
主要从后端维度来分析
这里可见，下图尽管是开始发起请求-》收到请求的全过程，但也严重超标（几乎是标准值的2倍）
通过线上用户的真实采集，并制定能反应用户体感的指标，进行性能黑榜和全局趋势分析。
从重点单点角度，我们通过性能黑榜；从整体视角，我们通过整体趋势分析。
.性能数据的采集
.几个名词解释
ARMS前端监控专注于对Web场景、小程序场景的监控，从页面打开速度（测速）、页面稳定性（JS诊断错误）和外部服务调用成功率（API）这三个方面监测Web和小程序页面的健康度。
SLS日志服务为Log、Metric、Trace等数据提供大规模、低成本、实时的平台化服务。日志服务一站式提供数据采集、加工、查询与分析、可视化、告警、消费与投递等功能。
ODPS即MaxCompute，是适用于数据分析场景的企业级SaaS模式云数据仓库。
FBI是阿里内的智能大数据分析和可视化平台，下面的所有截图都是在FBI平台配置图表而成，还未对外开放。
.全过程
arms-sdk结合前端的自定义埋点，在海量用户访问的同时，就会自动上报数据到sls日志库，整体过程如下图：
.性能指标的确定
.统计范围--用户视角
所有前台页面，每个用户每次浏览的有效数据（完全加载<15s 内有效）
指标的影响因子：从用户视角，页面流量越大，则对整体数据的影响越大（也就是权重越大）
这样做的好处：流量越大数值越严重的，优化的效果（正反馈）越明显，确定了治理性能问题的优先级。
.三个指标
结合淘系、以及集团其他部门的
.性能黑榜
为何要用性能黑榜来作为主要发现手段？我们通常可推理得：
（可根据各自业务，加个样本量的筛选，如我们看每日pv 10w以上的）
.整体性能趋势分析
整体趋势分析，即是为在整体角度，看我们的页面性能趋势，它是重要的度量指标。 这里我们把所有的流量都纳入，没有页面的区分，为的是基于用户维度，流量大的页面权重自然会更大。
从上图看，1月初到2月中旬的数据正在持续恶化，必须要采取措施治理！
如果我们想自己采集页面的各项原始指标数据，该怎么做呢？浏览器为我们提供了原生的 Timing API，并且现在有两个标准，下面来分别介绍一下这两个标准。
上面的脚本计算了 head 中的第一个 js脚本执行后加载页面所需的时间，但它没有给出任何关于从服务器获取页面所需的时间，或是页面初始化生命周期的信息。
由此我们可以计算旧文档的卸载、重定向、应用缓存、DNS lookup、TCP 握手、HTTP 请求处理、HTTP 响应处理、DOM 处理、document加载完成等页面性能打点。具体可以参考navigation-timing W3C的规范 和 几个页面关键指标是如何计算的
从上图中我们可以看出Document Processing是 Navigation Timing 独有的，后面我们也会介绍Resource Timing。整体而言 Level 2 标准更加的全面，把Web Performance Timing分成了各个 Performance Metric，看起来一目了然，然而各个主流浏览器还存在兼容性问题。
介绍完这两个Performance Navigation Timing API，我们顺便再来看一下其余几个主要的Performance Timing API：Resource Timing API 、 Paint Timing API 和 Long Task Timing API，以及如何使用PerformanceObserver异步获取性能数据。
PerformanceObserver 可以被动地订阅与性能相关的事件，也就是说这个 API 通常不会干扰页面主线程的性能，因为它的回调通常在空闲期间触发。默认情况下，PerformanceObserver 对象只能在条目出现时观察它们。如果想延迟加载性能分析代码（不阻止更高优先级的资源），我们需要这么做：
设置buffered 为true，浏览器将在第一次调用 PerformanceObserver 回调时返回其性能条目 缓冲区中的历史条目。
1、静态资源的压缩合并（JS 代码压缩合并、CSS 代码压缩合并、雪碧图）
2、静态资源缓存（资源名称加 MD5 戳）
可以通过链接名称控制缓存：通过前端构建工具为打包的文件添加md5后缀，这样当打包上线时请求的链接发生改变，这样可以防止由于缓导致静态资源更新失效；
3、 使用 CDN 让资源加载更快
二.优化页面渲染
1、CSS 放前面，JS 放后面
2、懒加载（图片懒加载、下拉加载更多）
先将src赋值成一个通用的预览图，下拉时候再动态赋值成正式的图片。如下，是预览图片，比较小，加载很快，而且很多图片都共用这个，加载一次即可。待页面下拉，图片显示出来时，再去替换src为data-src的值。（data-开头的属性浏览器渲染的时候会忽略掉，提高渲染性能）
3、减少DOM 查询，对 DOM 查询做缓存
4、减少DOM 操作，多个操作尽量合并在一起执行（DocumentFragment）
DOM 操作是非常耗费性能的，因此插入多个标签时，先插入 Fragment 然后再统一插入 DOM。因为Fragment文档片段存在于内存中，并不在DOM树中，所以将子元素插入到文档片段时不会引起页面回流。
5、事件节流
在开发过程中会遇到页面一些频繁触发的事件，比如mouseover、scroll、resize等事件。一秒可以执行很多次，这样会造成严重的页面性能问题，导致页面c出现卡顿甚至浏览器崩溃。因此我们需要对事件进行节流，简单的说就是控制其执行的次数。这里就涉及到了常用到的js的节流和防抖功能实现。 1.防抖（debounce）：在事件被触发n秒后再执行回调，如果在这n秒内又被触发，则重新计时。
2、节流（throttle）：规定一个单位时间，在这个单位时间内，只能有一次触发事件的回调函数执行，如果在同一个单位时间内某事件被触发多次，只有一次能生效。
6、尽早执行操作（DOMContentLoaded）
现在浏览器可以理解CSS样式表的结构了，再经过CSS属性值的标准化操作和加上CSS 的继承规则和层叠规则，我们就可以计算出 DOM 树中每个节点的具体样式。
渲染流水线中最重要的一点是，在每一步都使用前一操作的结果来创建新数据。 例如，如果布局树中的某些内容发生了变化，则需要为文档的受影响部分重新生成绘制顺序。这就牵扯到了重绘和重排的概念，我们后续会说到。
合成线程可以对不同的光栅线程进行优先级排序，以便可以首先对视口内（或附近）的事物进行光栅化
自此我们从HTML，JS和CSS解析到页面帧的合成了解了一个页面的渲染流水线。那我们如何从这个过程中得到页面渲染的性能优化呢?
上面一小节介绍了几个预加载的技术，接下来我们要说一下懒加载。懒加载就是延迟加载，它可以极大的减少无效资源的加载，从而提高页面的性能。懒加载的核心适用场景就是在当前视口（viewport）外的资源（或者是非关键渲染路径下的资源）不需要加载。代码层面的懒加载最为常见的是我们使用的第三方库的懒加载（Dynamic Import）或者组件懒加载（React的），其本质就是动态 import() 语法。下面我们来介绍一下其他资源懒加载的实现方式：
上面的代码可以实现浏览器原生的图片懒加载（基于Chromium 的浏览器和 Firefox，不支持loading属性的浏览器会忽略它的存在）。这样我们就不用使用其他js库来实现图片的懒加载。 loading属性有三种取值：
如何理解loading=lazy时的与视口距离的阀值？Chromium 的延迟加载实现试图确保屏幕外图像足够早地加载，以便在用户滚动到它们附近时它们已经完成加载。 通过在它们在视口中可见之前获取图片资源，最大限度地提高了它们在变得可见时已经加载的机会。那么如何尽早的加载图片？也就是说不可见的图片在和当前视口的距离为多少时浏览器才会去加载后面的图片呢？答案是Chromium的这个距离阈值不是固定的，取决于以下几个因素：
根据上面三个因素，Chromium在不断改进这个距离阀值的算法，在节省图片下载的同时，也能保证在用户滚动到图片时图片已加载。
很多人都以为，前端性能优化，重点在“前端”优化，“测试”很难起到主导作用。试着换个角度，从整个研发团队视角看，前端做运动员专项治理，测试做裁判员专项评测，这套机制，是否更能切实做到优化，达成的数据也更让大家信赖？再者，测试不止局限于此，还可做队医、分析师。。。。
.可持续优化闭环
以下持续优化闭环，是我们摸索着实行了一年多，有效且高效的解法。
从上图看，整个过程为：
step0、前端事先进行埋点，（一般前端做了sdk，直接引入即可）
step1、测试通过性能黑榜，发现最为突出的重点性能问题页面（首屏平均时长&秒开率，PV&业务意义， 多项结合度量）
step2、协助前端一起专业分析问题页面，找出性能瓶颈点
step3、前端更有策略地针对性治理
step4、查看性能趋势变化，验证优化效果
step5、假设已达到优化预期，或者有更糟糕的页面把之前页面挤下去，继续关注黑榜前列的页面（即跳到step1，继续轮转）
我们可以发现，测试通过发现、分析、验证 三板斧，驱动推进页面性能优化。
.效果明显
从20_年10月份开始迭代以来，共发现了8类严重性能问题。
包括：端外（支付宝）性能问题，外投&跨端性能问题，pha架构性能问题，运营不规范配置导致、其他业务原因导致的性能问题等。
并且快速有效，在业务方或其他同学提过来之前，我们都已经发现并有了分析，在优化节奏上更具有主动性。
HTTP应用层的优化和TCP传输层的优化是前端性能优化的必经之路。我们都知道合并（减少）静态资源的HTTP请求（比如前端雪碧图）是一条前端优化准则，那它背后的原理是什么呢？真的要严格做到减少HTTP请求吗？下面我们从原理上探下究竟。
preconnect可以用在请求资源前，预先完成 DNS lookup + TCP handshake + TLS handshake（如果是https），当客户端需要请求目标资源的时候，下一个 TCP 首包就可以直接发送 HTTP 请求。虽然非常简单，但它仍然会占用宝贵的 CPU 时间，尤其是在安全连接上。 如果在 10 秒内没有使用连接，浏览器会关闭它，这样就浪费所有早期的连接工作。目前Safari 版本以上的浏览器都支持，但是较新的几个Firefox浏览器版本都不支持。dns-prefetch的浏览器兼容性比较好，但是它只处理了DNS查询。
元素的 rel 属性的 preload 值允许在 HTML 的
使用preload后，我们就可以提高字体资源的优先级，这样浏览器就可以尽早的预加载。有案例表明，使用preload进行字体加载后，可以将整体页面的加载时间缩短一半。
prefetch是W3C Resource Hints 标准的其中一个指令。prefetch的用法是和preload相同的，但是功能却和preload大不一样。它主要是告诉浏览器获取下一次导航可能需要的资源。 这主要意味着资源将以极低的优先级获取（因为浏览器知道当前页面中需要的所有内容都比我们猜测下一个页面中可能需要的资源更重要）。 这意味着预取的资源主要是用于加速下一个导航而不是当前导航。在浏览器的兼容性上，prefetch可以支持到IE11。同时也要说明的是，prefetch和preload的资源如果可以被缓存（例如，有一个有效的cache-control ）那么缓存是被存储在 HTTP 缓存中的，并放入浏览器的内存缓存；如果资源不可缓存，则不会存储在 HTTP 缓存中。 相反，它上升到内存缓存并停留在那里直到它被使用。
这会生成 并追加到页面头部，指示着浏览器在闲置时间预取 文件。并且只要父 chunk 完成加载，webpack 就会添加 prefetch hint(预取提示)。
preload chunk 会在父 chunk 加载时，以并行方式开始加载。而prefetch chunk 会在父 chunk 加载结束后才开始加载。
quicklink提供的一个demo显示使用quicklink可以将页面加载性能提高4秒
将本文的Word文档下载到电脑
推荐度：