1024节谈谈 “前端性能优化” 背刺面试官_性能指标采集及上报-CSDN博客

本文链接：https://blog.csdn.net/Siebert_Angers/article/details/127457000

一. 前言

性能是前端面试的常考问题，也是系统的一个重要的指标，随着项目日渐庞大，都会涉及到优化的问题这也是为什么我想写这么一篇文章，在工作的过程中,我们也常常遇到这个问题。
假如某天你的老板突然问你，线上首页打开很慢，过一会又好了，你该怎么回答?

70%的同学可能上来就会说减少合并资源，减少数据请求，数据缓存，懒加载这些优化手段
15%的同学可能会提到需要在DevTools下先看看首屏加载时间，围绕首屏来进行优化
10%的同学可能会提到需要接入一个性能平台来看看现状,诊断以下,再根距具体问题调整
5%的同学才可能提到从前端性能体系来系统考虑体统优化

如果你是面试官，你会怎么选？其实面试官真正期待的，是什么场景下，遇到了什么样的问题，需要采取哪些性能优化的手段，需要达到一个什么样的效果,而不是直接去提出要使用哪些优化手段。
站在老板的角度上来看，老板想要的当然是前端和后端一样，可以通过查询日志就可以快速定位平台的问题，而不是去停留在猜测的层面，那有没有这样一个东西可以去做这些事情呢?当然有，那就是性能监控平台，能直接判断出当前性能数据有没有问题，定位问题到底是出现在前端，后端，还是网络层，关于技术层面,在这篇文章就不多聊。

二. 学习难点

有同学就要问了,那么我该怎么去学习这个性能优化呢？在谈怎么去学习前,小编想聊聊学习这个有什么难点和有什么需要注意的地方。
第一:优化成体系的资料稀缺,很难收集到成体系的优化学习资料,大多数零零散散,和一堆拼不起来拼图一样。
第二:性能监控预警平台几乎没有开源,需要自己去开发,性能优化的重中之中在于性能监控预警平台,能够清楚的锁定有问题的指标,可能有些资源网站存在部分不完整的开源项目,但是如何与现有公司的前端性能基建对接,性能平台包含哪些东西,需要对哪些东西做预警,应该设定哪些预警策略,这都是需要去整改的非常的耗时耗力。
第三:性能优化立项沟通,如何从业务的角度去思考性能优化带来的价值,并且说服业务去发起这个项目奖,对于一些小公司而言性能优化可能并不是一个侧重点,所以一些工作很长时间的小伙伴可能也并没有接触过性能监控预警平台。

三. 性能优化方法论

1. 性能优化体系及关键指标设定

想象以下一个场景；一年一度的双十一活动开始了，大家都在祈精交易系统千万别出问题，有个同事突然发现自家的下单页面变得很慢。哪里出了问题？
是网络抽风，卡顿了？还是后端接口出问题了？或者是用户的手机环境问题？
遇到这些问题你有没有想过要是有个性能监控预警平台就好了,可以快速的锁定问题,大大节省时间成本。
前端性能优化一般比较琐碎繁杂那怎么把琐碎的工作系统化呢？
在这里插入图片描述

2. 性能优化流程

我们先来谈谈指标设定说的是我们需要设定什么样的指标,比如页面打开吗吗慢,我们需要优化他,该从哪些地方入手,优化完成后怎么知道已经达到预期的效果，这些都需要指标来衡量。
设定指标之后，接下就是确定性能标准也就是我们性能优化目标是怎样的,优化到什么程度合适?列如我们要优化APP里面的H5打开速度,确定的性能指标是秒开率那么一秒内能够打开的请求比例,就是它的性能标准。
如果仅仅只是判断性能优化指标是否到位还好,但是很多时候，为了让产品同学感觉我们是为产品服务，而不是又在造轮子,我们还需要关联产品目标进行收益评估，比如列表页到详情页的转换率能不能提升,用户跳出率能不能降低。
接下来我们就可以把业务代码接入性能优化平台根据性能标准给出诊断清单
然后就是性能立项了,性能项目立项是你赢得产品经理、后端同事支持让优化顺利执行下去不可或缺的内容。
最后是性能实践,也就是经过优化之后发起项目上线,并跟踪进行效果评估,结合场景把这些项目成果以文档或代码的形式沉淀下来。制订优化实践，确保新人也可以执行,是优化成果得以长期保持的必要保障。

3. 性能指标采集及上报

主要内容是把前面提到的性能指标以代码的形式分解落地,确保可以采集，然后在SDK封装后集合统计埋点,最后根据实际情况，制定上报策略

4. 性能监控预警平台

主要是通过分析上一步采集到的数据再对比性能标准进行监控,当指标超过某一监控阈值时性能监控预警平台会通过邮件或者短信，给我们发送预警信息。在构造上性能监控预警平台包括性能数据处理后台和性能可视化展现前台两部分。
其中性能数据处理后台,主要是在性能采集数据上报到性能平台后，对数据进行预处理、数据清洗和数据计算，然后生成前台可视化所需数据。
性能可视化展现前台,主要是对核心数据指标进行可视化展现,对性能数据波动进行监控，对超出阈值的数据给出短信或邮件报警。
最后值得注意的是在上线前一定要做性能专项测试,检查一下你采取的措施和性能优化预期是否一致
那么假如,出现了一个6.18活动贡加载数据卡顿的性能问题,我门想要优化它，那么该怎么做？
首先要先确定它的性能指标及其标准是什么,只有设定好了性能指标，知道了它的标准，接下来我们才知道该围绕着什么来开展性能优化

5. 如何设定性能关键指标？

我想分为两个点来讲一个是关注什么样的指标?一个是关键指标的设定及标准?
那么什么样的指标值得我们关注？我觉得要满足两点第一是:可衡量，就是可以通过代码来度量
第二是：关注以用户为中心的关键结果和真实体验,关键结果，就是用户真正关心什么。比如当用户进入商品详情页面，他关心的是这个商品怎么样,具体到贡面上就是商品描述、商品头图、商品价格和购买，按钮这些关键信息。
而真实体验，就是用户使用产品的感受,比如当用户进入列表页，在滑动过程中,页面加载突然跳出一个弹窗，他会不会觉得烦？
所以基于这两点在性能指标方面我选定加载,交互性,和视觉稳定性三个方面来了解性能指标以及其设定。
加载就是进入页面时，页面内容的载入过程,比如当你打开一些网站时，你会发现，有的网站首页上的
文字、图片出现很缓慢，而有的则很快，这个内容出现的过程就是加载。加载缓慢会严重消耗用户的耐心,甚至会让用户离开这个页面。
交互就是用户点击网站或App的某个功能页面给出的回应,比如我们点击了一个“点赞”按钮立刻给出了点赞数加一的展示，这就是交互体验好，反之如果很长时间都未给出回应,这就是交互感觉不好。
视觉稳定性指标(CLS Cumulative Layout Shift)也就是布局偏移量，它是指页面从一帧切换到另外一帧时，视线中不稳定元素的偏移情况。比如你正要点击页面链接购买的时候，原来的位置插入了一条9.9元包邮的商品广告,结果会怎样？你点成了那个广告商品。
在性能优化关键撸标方面目前业界主要集中在加载方面特别是白屏时间和首屏时间,它们直接和用户体验感相关,且相关的衡量标准业界已经达成共识,在采集方式上除了手动采集之外，还可以自动化采集。
而交互性和视觉稳定性关键指标，业界还在探索没有统一的衡量标准，且必须手动采集。
比如交互方面,有的公司用FID指标(First Input Delay,首次输入延迟)指标必须尽量小于100ms，过长会给人一种页面卡顿的感觉。
有的公司使用PSI(Perceptual Speed Index,视觉变化率)衡量标准是小于20%
而视觉稳定性指标CLS比较前沿,它的采集方法，除了依赖Google的Lighthouse做本地采集,目前还没有好的方案。
那么聊到白屏时间和首屏时间。
什么叫白屏时间呢？指的是从输入内容回车（包括刷新、跳转等方式）后到页面开始出现第一个字符的时间。这期间包括建立DNS查询，TCP连接，发送首个http请求,返回html文档,它的标准时间是300ms。那么哪些因素会导致白屏时间过长呢？
原因有很多,有可能是DWS查询时间长，建立TCP请求,链接太慢，或者是服务器处理请求速度太馒，
客户端下载、解析、渲染时长过长，没有做Gzp压缩，缺乏本地离线化处理，等等
首屏时间，它是怎么计算的？首屏时间=白屏时间+渲染时间,从浏览器输入地址并回车后，到首屏内容渲染完毕的时间,这期间不需要滚动鼠标或者下拉页面，否则刚无效
从重要性角度看，打开页面后，第一眼看到的内容一般都非常关键，比如电商的头图、商品价格、购买按钮等。这些内容即便在最恶劣的网络环境下，我门也要确保用户能看得到。
从体验完整性角度看，进入页面后先是白屏，随着第一个字符加载，到首屏内容显示结束，我门才会认为加载完毕，用户可以使用了。
首屏时间的标准，最初只是根据这个页面对时间是否敏感来判定,主要以用户平均首屏加载时间来计算
并没有详细区分2G/3G/4G/WiFi这些网络环境。前端工程师在使用过程中越来越觉得用平均值来表示加载时间并不准确可靠,人们又开始采用中位数，做正态分布，看分位值统计，后来由于繁琐引入了秒开率的指标，即1s内打开用户的占比,但是首屏时间毕竟粒度太粗了如果首屏时间长，白屏时间短，到底是哪里的问题？
所以我们可以进一步作出拆分,首屏时间可以拆分为白屏时间、数据接口响应时间、图片加载资源等，白屏时间数据接口响应时间可以直接从后端服务中获取,不需要前端再重复计算。最后的图片资源需要我们单独采集。

四. 性能瓶颈点

假如团队对首屏时间的要求是1200m5,目前首屏时间长达2s,精简了首屏内容，合并了请求资源，对图片尺寸也进行了压缩优化,但最后的首屏时间还是没有降下来为什么？
想要对Wb前端进行性能优化，除了了解性能体系、关键性能指标之外，还需要了解页面加载全过程。
页面加载大致过程是怎样的呢？假设一个人正在上网，当他在浏览器输入URL并回车后,为了把URL解析为IP地址浏览器会向DNS服务器发起DNS查询，获取IP地址，在建立连接后，浏览器就可以发起HTTP请求,而服务端接收到后，对请求进行响应浏览器从响应结果中拿到数据，并进行解析和渲染最后在用户面前就出现了一个网页。
以上过程大概可以分为三个阶段,客户端发起请求阶段,服务端数据处理请求阶段,客户端页面渲染阶段。下面就根据这三个阶段来介绍一下web前端有哪些性能瓶颈点。
客户端请求阶段的瓶颈点,客户端发起请求阶段是指用户在浏览器输入URL,经过本地缓存确认是否已经存在这个网站,如果没有，接着会由DWS查询从域名服务器获取这个P地址。接下来就是客户端通TCP的三次握手,和TLS协商向服务器发起HTTP请求建立连接的过程。

1. 本地缓存

先说本地缓存,为什么说本地缓存会成为前端性能的瓶颈点之一呢？
本地缓存可以让静态资源加载更快，当客户端发起一个请求时，静态资源可以直接从客户端中获取，不需要再向服务器请求。
这会出现一个什么情况呢？假如在客户端请求阶段，一个请求下来大约是1233ms这还是强(WIF1/4G)情况下如果是弱网(3G/2G)情况，一个请求连接都需要2s,使用缓存的话，几乎可以说是几毫秒内完成请求,怎么实现本地缓存呢？一般包括强缓存和协商缓存两种形式。
强缓存是指浏览器在加载资源时，根据请求头的expires和cache-control判断是否命中客户端缓存,命中则直接从客户端读取,没有命中的话则请求服务器。
协商缓存是指浏览器会先发送一个请求到服务器，通过last-modified和etag验证资源是否命中客户端缓存,如果命中会返回这个请求,但是不会返回这个请求的数据,依然是从客户端中读取资源,如果没有命中则从服务器请求资源。

2. DNS查询

DNS之所以会成为前端性能瓶颈点,是因为每进行一次DNS查询都要经历从手机到移动信号塔，再到认证DNS服务器的过程。节省时间的办法就是让DNS查询走缓存,幸好浏览器提供了DNS预获取的接口
我们可以在打开浏览器或者NebView的同时就进行配置。

3. HTTP请求

最大的瓶颈点来源于请求阻塞,请求阻塞就是浏览器为保证访问速度，会默认对同一域下的资源保持一定的连接数,请求过多就会进行阻塞。
那么浏览器同域名的连接数限制是多少个呢,一般是6个如果当前请求书多于6个，只能6个并发其余的得等最先返回的请求后，才能做下一次请求，所以在项目初做一些域名规划很重要,我们可以先看看当前页面需要用到哪些域名，最关键的首屏中需要用到哪些域名,为了解决阻塞问题还可以做域名散列
通过不同的域名，增加请求并行连接数。
比如将静态服务器地址pic.google.com,做成支持pic0-5的6个域名，每次请求时随机选一个域名地址进行请求,因为有6个域名同时可用，最多可以并行36个连接

4. 服务端数据处理阶段的瓶颈点

服务端数据处理阶段是指NebServer接受到请求后从数据存储层取到数据，再返回给前端的过程，服务端程序接收到HTTP请求后,会做一些请求参数处理以及权限校验校验完成后它会将请求参数发送到数据存储服务,再从数据存储服务中获取数据做处理,再返回给前端。
这个过程中的瓶颈点就在于是否做了数据缓存处理,是否做了Gzip压缩之类的。
其中Gzip压缩是一种压缩技术通过Gzip压缩资源的下载速度会快很多能大大提升页面的展示速度