文章主要记录学习web性能优化方面的内容。

性能优化体系概览

完整的性能优化体系分为四部分

性能优化流程

指标设定

指标设定，我们要选择什么样子的指标来进行优化，比如优化白屏时长，首评加载时长？

性能标准

设定性能优化目标，优化到什么程度。比如优化App里面的H5页面加载速度，确定指标是提升秒开率，那么一秒钟可以打开的请求比例就是性能标准，设定一个秒开率为多少的优化指标。

收益评估

收益评估不应该只有前端这里的优化指标，优化过之后要考虑比如页面的转化率是否有提升？用户跳出率是否降低？

诊断清单

将业务代码接入性能监控平台，根据性能标准给出具体的诊断清单

优化手段

结合性能标准和诊断清单，确定优化手段

性能立项

立项获得产品和后端、数据等同事支持

性能实践

优化之后，项目上线，跟踪并且评估效果，将项目成果以文档形式记录沉淀下来。

性能指标的采集和上报

指标分解
指标采集
SDK封装
统计埋点
上报策略
数据预处理

将性能指标以代码形式分解落地，确保可以采集，SDK封装后埋点统计，上报之前，将明显异常数据丢弃，制定上报策略

性能监控预警平台

对采集到的性能数据，再对比性能标准进行监控，超过阈值进行邮件或者短信告警

性能可视化前台

主要是性能展示，性能监控，对核心数据进行可视化展示，对性能数据波动进行监控，超出阈值给出警告

性能数据处理后台

对SDK上报的数据进行预处理，数据清洗，数据计算，然后给到性能可视化前台所需数据

性能专项测试

上线前对性能优化采取的措施和优化预期是否一致。

比如我们某些页面卡顿，那么我们想要优化他，应该怎么做？首先要确定性能指标和标准，但是有FPS，FCP，白屏等等指标，哪一个才是关键？

指标的定义

性能优化，我们首先要定一个标准，即什么是“好”，什么是“差”。以及如何设定性能指标。
值得关注的指标，主要有

可衡量

可以衡量才可以优化

用户为中心的关键结果和真实体验

用户进入某个商品详情页，关注的是商品价格，描述等。要保证用户在任何情况下都可以看到这些信息，以及另外的用户真实体验。

性能优化关键指标设定及标准

加载

进入页面，页面加载过程，加载速度

交互

比如滑动，点击出现动画等交互

视觉稳定

也就是CLS，布局偏移量，视线中不稳定元素的偏移情况。比如点击某个按钮，上面没有加载出来的图片并且没有固定高度突然撑开，要点击的按钮突然变成了图片，导致没有点到。

标准

首屏在1s之内，用户会感觉很快。超过2.5s，就会感觉很慢
但是，平均值并不可靠，会因为考虑2G/3G 弱网环境，或者网络不稳定的环境（如坐火车或乘飞机时），这样会严重影响整体指标，就像普通人和富人加起来计算平均资产，实际上并不会有这么多。

后来又计算中位数，做正态分布，比如P50，P90，P99等。通过对100个用户的首屏排序，得到在第99位的首屏时间就是P99。
不过这样计算也比较麻烦，后来引入了秒开率这个概念，最早来源于阿里巴巴

秒开率

即1s之内打开页面用户的占比
端内：App内webview
端在：普通浏览器

白屏和首屏

白屏

白屏时间，指的是从输入内容回车/打开页面，到页面出现第一个字符的时间。中间包括发起DNS查询，建立TCP链接，发送HTTP请求，返回HTML文档，解析渲染，这个过程标准时间是300ms。

白屏时间过长，如果超过1s，用户注意力会被转移

首屏

指的是页面首屏内容渲染完毕的时间，还可以拆分为数据接口响应时间，图片资源加载时间等。
首屏时间=白屏时间+渲染时间

第一张是白屏时间，第二张是首屏开始加载时间，最后一张是首屏时间。
首屏时间，比白屏时间更加重要

瓶颈点分析

比如，团队对首屏加载时间是1.2s，但是目前有2s，还有不小的差距要求，虽然做了精简首屏内容，合并请求资源，图片替换webp或者压缩等等，但是还是没有降下来？
58同城列表页项目为例，DNS 查询时间大概是 385 ms，TCP 三次握手及 TLS 协商时间 436 ms，数据返回 412 ms。一个请求下来大约是 1233 ms，这是强网（WIFI/4G）情况下。

本地缓存

缓存这里就是常见的请求头的 expires 和 cache-control 判断是否命中客户端缓存，一般是需要配置的。

DNS查询

DNS也会成为性能瓶颈点，每次查询一次，都会经历从手机到移动信号塔，DNS服务器过程。
我们可以让DNS走缓存，浏览器提供了DNS预获取接口，打开web view或者浏览器时候就进行配置,再配合preconnect(预连接)提示配对

<html>
  <head>
     <!-- 开启DNS预解析 -->
    <meta http-equiv="x-dns-prefetch-control" content="on" />
     <!-- 对gstatic域名做解析 -->
    <link rel="dns-prefetch" href="https://fonts.gstatic.com/">
    <link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin>
    <!-- and all other head elements -->
  </head>
  <body>
    <!-- your page content -->
  </body>
</html>

HTTP请求

浏览器会对同一域名下的并发请求做限制，会被阻塞，一般是6个，webview会更少。可以通过域名分片解决，但是如果域名过多，又会涉及无法缓存的问题。

GZIP压缩

开启GZIP会节省1/3左右资源加载大小，资源下载速度会快很多。运维团队可以开启GZIP

数据缓存

借助service worker的数据接口做缓存
借助本地存储接口，冷数据可以存储在本地
CDN，内容分发网络

重定向
重定向是指网站资源请求等被转移。
服务端重定向
META标签实现的重定向
window.location重定向

都会引发新的DNS查询，新的TCP三次握手、TLS协商，新的HTTP请求。

页面解析和渲染

这里也就是常见的解析DOM树，解析CSSOM，经历style、layout、paint、合成，以及重绘重排过程等等。

构建DOM树的瓶颈点

HTML不满足语义化。浏览器需要花更长的时间解析DOM含义。特别是错误的标签比如将
写成了
等
DOM节点数量过多。构建DOM树时间会变长，延长解析时间
script阻塞。会直接导致加载白屏时间变长，如果可以用defer或者async属性就用这个
布局中的瓶颈点
页面中，每次元素位置发生变化，都会触发重新计算重绘重排，渲染流程从头来一遍。
比如一张图片没有给固定宽高，页面加载之后，这张图片会撑开页面高度，导致重新绘制和布局计算，再次渲染页面重排或重绘，导致延长了页面展示时间。

案例分析

比如，你的上级给你提出了一个问题，要优化页面性能，这个问题会很模糊，比如

现在的性能是怎么样子的？怎么样量化？
是不是需要一个性能监控平台？
监控平台怎么搭建？还有和别的部门(数据/后端)合作？性能采集数据做统计分析？
性能立项
为什么首先是性能立项？简单来讲就是成立一个项目组，通过项目化的运作方式来解决，包括确定团队成员，技术调研、项目目标制定、获得业务侧支持、需求范围、优先级确定。
性能优化，是一个探索性的项目需求，有别于日常的业务需求。
项目目标制定
目标制定是一个正推和反推的过程

正推：线索-本质痛点和问题-解决方案-目标
比如，项目首屏时间可以减少10%，对应VPPV可以提升3%。3%收入对公司来说吸引力不够，因为平时波动会有2%，所以需要提高到10%的收入提升。VPPV就是详情页的UV/PV
反推：目标-解决方案-本质痛点和问题-线索
如果要实现10%收入提升(VPPV)，如何实现？至少需要30%的性能提升
最终就是得出目标：通过性能提升30%，实现收入提升10%，这个数据是业务结合转化率+推算得出来的

获得业务侧支持

需要将各个业务线的前端等资源协调过来去做。同时和别的部门比如说，通过性能优化，提升10%收入等方式说服。

立项

先做好技术可行性调研，然后立项。性能优化是横向项目，会涉及多个业务，先试点两个业务，最后立项。
立项信息比如:
投入资源:前端10人，后端4人，UI4人，测试2人
投入价值：20个人，2个月，约花费xxx万元
收获价值：访问量，VPPV收入提升10%，订单提升8%…
之后就寻找性能线索，有针对性的优化。此时就需要性能监控预警平台。

性能优化诊断

弱网环境

如果数据不及预期，对用户网络分布等实际情况做调查，可能弱网络用户占比比较多，所以就需要对弱网环境做了以下优化手段。

一个接口请求需要2s，一个页面需要20多个请求，这个时候就可以做请求合并。
小图标采用Base64 Encoding ，内嵌在页面中，不额外发送网络请求
不自动加载图片，只显示占位图

如果性能优化涉及多条业务线，需要先把一条业务线做好，确定收入数据提升了，再去推广到其他业务。

并且需要注意的是，因为性能优化是探索性项目，有可能因为异常数据不如预期，反而会降低，要做好一定的心理准备。
如果有AB test系统，可以通过AB test系统分流来观测数据效果。
问题:如果我们只是对比线上前后数据，如何排除业务升级带来的影响？

前端性能优化(一)-性能优化方法论