主要文本
责任编辑是后端操控性Listary的真实事例，首发于提前布局，定量分析而非认定的传授，尤其是对于分拆天然资源后的数目与操控性的关系，得出一点儿路子，为准，同时variations也得出了一些后端建模的图象类型，也将竭尽全力会在接下来的文章竭尽全力详细介绍。
写在前面的话
责任编辑约4.5全卷，（删掉了实验据估计3三千多字符串的图象标识符，如须要请上列），念完须要大约5分钟，或是只看标题即可了解主要文本。责任编辑不为聊著，而已个人结晶，对统计数据建模，以及操控性优化提以下几点路子，其中图象均使用R210统计数据，聊著文本实为不合逻辑，责任编辑不针对，不辱骂，旨在Hardoi，流水不腐。
节录
《AOL赵雄》中有一条是增加天然资源允诺数分拆天然资源，但增加http允诺数目应该到什么数目级呢？定量分析在这儿是一个大难题。
这儿他们已经能根据经验得出：天然资源允诺数目和读取时间存在相关性，这而已叙尔热雷县，他们不能不管怎样停留在发现这个角度。
尽管通常，两者之间并不是简单的单对单，网站操控性统计数据都是多因素共同促进作用的结论。比如说很多分项都能影响网页的读取情形，比如说网络情形、标识符量、比如二进制数据传输，所以在现实中很难找到100%的两者之间。
但从对，他们能独立掌握一类方法，或是说是一类路子，在一定程度上“解释”或是“理解”某个统计数据分项的促进作用，有的是时候甚至是得出定量分析的结论，这种情形越是具体，可能定量分析的情形就越明显，这大概也是可观测激励性倡导的一类理念。
先聊著再上大招，习于聊著者可略去这一千字
metrics层出不穷，log窗户上硬碟，trace也是无处不在，三绿豆金支撑点支撑起来的是坚不可摧，还是销售业务现铜地如日中天？
错错错
从艰难的统计数据设计与收集，共振频率监视系统到赋能操控性Listary、销售业务增长，metrics贡献几何，统计数据的价值在哪里？
莫莫莫
胜者为王，数十亿百亿元流量，智能，收获有效基本工资，升官减薪，得截叶几两，三餐有汤，无奈涛声依旧，网页依旧，
卡卡卡
操控性Listary不做建模，收集统计数据干啥？
假如把网站比作一架飞机，如果没有各式各样的航电统计数据和仪表盘，飞行员敢开吗？
作为网站，他们同样收集了很多的统计数据。何以谓之多，数十亿每日以G或是T为单位的metrics,logs，traces，不可小觑，至少成本不可小觑。上学时做论文，无奈总是没有统计数据或是成本有限，工作后面对这么多的统计数据，却也只能照部就班不主动不冒进取，我在之前文章也写过《网站操控性分项收集》[1]（大家点击链接就可以跳转到相应的文章），感兴趣的小伙伴可以查看。
什么叫做场景优化和建模
收集到操控性监控或是操控性分项后，就须要将统计数据建模展示出来，狭义上统计数据建模是将操控性的监控分项通过图象的形式展示出来，场景化能满足对统计数据观测的需求，其中就包含帮助人们发现统计数据中隐藏的内在规律。
操控性分项等统计数据建模的目的
统计数据建模主要旨在借助于图形化手段，清晰有效地传达与沟通信息。它的目的大体可分为三类：
1.0 懵懂阶段，展示统计数据：查看当前的状态
简单可以理解成poor/normal/high，或是说健康不健康。
2.0 进阶阶段，统计数据趋势：查看统计数据的走向
说的专业叫做同比、环比，简单也可以理解成变好，变坏，基本不变或是说走势是否健康
3.0 大神阶段，洞察统计数据，做决策。
监视系统（比如说针对http允诺错误率设定监控共振频率或是某个接口允诺设定水位进行监视系统）– 操控性Listary（设定slo)
赋能销售业务统计数据，探查提高建模图象有哪些
建模图象：包括 时序图、概览图、表格图、矩形树图、漏斗图、饼图、柱状图、直方图、SLO、排行榜、仪表盘、散点图、气泡图、中国地图、世界地图、蜂窝图、文本、图片、视频、命令面板、IFrame、日志流图、对象列表图、监视系统统计图 等，
这么多图，一篇文章可讲不完，今天先开个张，讲一下散点图、漏斗图、矩形树图以及时序图。
散点图
散点图定义散点图是常见的统计数据表达方式，通常表示因变量随自变量而变化的大致趋势，由此趋势可以选择合适的函数进行经验分布的拟合，进而找到变量之间的函数关系，可用来观察统计数据的分布和聚合情形，进而对帮助用户快速、准确的分析和预测统计数据具有重要意义。
白话讲散点图
散点图就是两个变量的值，看两个值之间的关系，通常这两个值是x，y。
上升趋势模式通常意味着正相关。一个标准的散点图如下所示。
下面我就从探究天然资源允诺数目的角度，来探寻网页读取时间（loading time）的相关情形，希望能给阅读文章的同学提供一点路子。
坐标轴查询公式
X轴：R::view:(AVG(view_resource_count)) { view_resource_count <= 60 } BY view_path_groupY轴：R::view:(PERCENTILE(loading_time, 75)) { loading_time <= 2000000000 } BY view_path_group坐标轴说明
用简单的语言来说:
x轴是网页读取时读取的天然资源个数，这儿为了更直观，他们仅仅取不超过60的统计数据，因为实际发现天然资源数目都没有超过60；y轴是loading time的时间，这儿之前图象也展示过该网站loading time大多在2s以下，所以他们只取2s以下的统计数据。12h内的统计数据y=17.505x+185.29y=17.505x+185.29y=17.505x+185.29
1d内的统计数据y=11.735x+214.19y=11.735x+214.19y=11.735x+214.19
3d内的统计数据y=12.263x+206.99y=12.263x+206.99y=12.263x+206.99
7d内的统计数据y=23.644x+341.01y=23.644x+341.01y=23.644x+341.01
，更加意味着，研发只须要在工程化的角度，对天然资源进行分拆就能达到操控性提升的效果。他们分别查看这几个公式
y=11.735x+214.19y=11.735x+214.19y=11.735x+214.19
y=12.263x+206.99y=12.263x+206.99y=12.263x+206.99
y=17.505x+185.29y=17.505x+185.29y=17.505x+185.29
y=23.644x+341.01y=23.644x+341.01y=23.644x+341.01
为什么x轴无限小的时候，y轴仍然有值呢，这是因为在网页读取的过程中，分为两种类型
intiial load,首次读取，可能是/，可能是一级或是二级网页route_change，路由切换，可能是/，可能是一级或是二级网页这也是spa应用中必须考虑的因素。如果他们只考虑route_change的情形，则会排除很多因素的影响，那样的图会是什么样子呢？
15分钟，趋势更明显了小总结
然并卵，上面的公式就一定代表天然资源和loading time的线性关系吗？笔者自己也不完全这样认为，但撇开线性公式，他们确实从这家公司的统计数据中能探查到：
只要保证x轴在10以内，则就能保证loading time在1.2s以内。如果x轴在6个以内，则能保证loading time在800ms以内。一旦x轴超过10个，则loading time会从1.2s攀升到1.5s，且有加速的趋势一旦x轴超过10个，则loading time没有低于900ms的情况出现。散点图使用场景：操控性优化我之前分享讲过LCP和提前建联有关系。其中有几个非常有意思的分项，今天我只以其中两个为例：
resource_tcp，天然资源读取 “TCP 连接时间，计算方式：connectEnd – connectStartresource_ssl：天然资源读取 SSL 连接时间，计算方式：connectEnd – secureConnectStart他们都在推测dns和lcp的关系，他们也能肯定前者对后者有提高的促进作用。但每家公司的场景有不一致，整理我司的resource_ssl和lcp的先测试一下。
坐标轴查询公式
X轴：R::resource:(PERCENTILE(resource_ssl, 75) AS ssl建联时间) { resource_ssl <= 200000000 } BY view_path_groupY轴：R::view:(PERCENTILE(largest_contentful_paint, 75) AS 读取时间) { largest_contentful_paint <= 2500000000 } BY view_path_group坐标轴说明
用简单的语言来说，x轴是ssl耗时，这儿为了更直观，他们仅仅取不超过200ms的统计数据；y轴是lcp的时间，这儿之前图象也展示过该网站lcp大多在2.5s以下。
效果图
简单解读
一般天然资源的读取都要进行dns的查找，如果一个网站有cdn，有后端接口，再使用了其他域名，那么一个网站读取的三四个域的天然资源的结论就是，在首次打开时，要做三四次的dns查找，这个时间对于网站读取来看是非常可观的，以上这部分文本从网络连接的角度，建议能提前建联。可以参照DNS预读取这个方法DNS预读取一般是使用link标签，其中rel属性需指明dns-prefetch，href属性应指明须要建联的网站。
注意：因为预读取dns是并行的，不会阻塞网页的渲染。所以不用担心写多个会有负面影响。一般文章到这儿就结束了，这儿他们须要有额外的福利。
福利1问：建联时间应该是多久？
答：他们暂且推测在0-90ms以下,而且较为正常情形下，他们应该更多的看到统计数据落在了0这个区间，不过占比多少，各个公司视情形而定。
福利2问：建联的建模图应该是什么样的？
答：首先他们要能看到命中0的网页占比，其次要看到在0-某一个时间点内loading time有增长的趋势，以及超过该时间点，loading time不再成相关性趋势。
时序图
定义时序图一般用于显示统计数据在相等时间间隔下的趋势变化，同时可以用来分析多组分项统计数据之间的促进作用及影响，为了让大家更明白，可以想一想平时看到的股票走势、气温图，他们都是时序图，从时序图中他们能更直观的看到一些统计数据。
股票图
天气温度
网站操控性分项很多，我之前有篇网站操控性分项的文章[2]以及网站操控性分析分项建设[3]对此做了详细列出（大家点击链接就可以跳转到相应的文章）其中比如说对于网站操控性非常重要的谷歌三绿豆金分项LCP、CLS、FID[4]，他们以LCP[5]为例，展示一周以内3个app的P75的LCP状态。展示之前，他们须要再熟悉一下LCP的分项范围
 fill=%23FFFFFF%3E%3Crect x=249 y=126 width=1 height=1%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E "深度前端性能调优的实际案例-小白都看的懂11")
image.png谷歌对于LCP分项做出了大概的水平划分。Good，小于2.5s之间Noral，2.5s-4s之间Poor，大于4s这里他们看一下这几个应用LCP的时序图。 解读
能清楚的看到，整体上3个app的绝大多数都在2.5s以下，这说明整体网站操控性LCP基本达标，其中深蓝色代表的app的LCP最短，也就是说这个app的LCP操控性最好。
将上图分项换成CLS，这次他们看三个app的情形，在此之前他们先复习一下CLS大概的情形。
image.png谷歌对于CLS分项做出了大概的水平划分Good，小于0.1之间Noral，0.1-0.25之间Poor，大于0.25这儿他们看一下这几个应用CLS的时序图。image.png解读
他们能清楚看到，整体分项绝大多数在0.2以下，这说明CLS基本达标。
注意
时序图甚至可以是某个按钮的报错、或是网页卡顿的时序图，进而可以针对针对特定的按钮进行Listary，以及针对特定的网页进行优化增加卡顿。
image.png矩形树图
矩形树图定义用于展示不同分组下分项统计数据的占比分布建模。
矩形树图使用场景网站网页很多，在读取过程用户是否出现卡顿，他们可以将所有网页进行统计，那么占比较多的就是网页读取卡顿次数较多的。
image.png然后就有同学可能好奇，为什么不用排行榜？可能是因为我正好先想到”矩形树图“吧。或是是排行榜上的数字对比不如矩形树图更直观。之前也有写过类似后端操控性周报草稿国内第一篇讲如何增加卡顿的标识符级别详细文章[7]，以及巧用 “ 火焰图 ” 快速分析链路[8]，文章都是呕心沥血。欢迎查阅，可以通过点击[9]进行查看。
漏斗图
简介漏斗图一般适用于具有规范性、周期长、环节多的流程分析，通过漏斗图比较各环节的统计数据，能直观地对比问题。另外漏斗图还适用于网站销售业务流程分析，展示用户从进入网站到实现购买的最终转化率，及每个步骤的转化率。
使用场景这儿举一个特别简单的例子，比如说网站访问量—注册网页访问量–商业版注册网页–点击注册，这儿我仅仅选取1天内的统计数据进行展示。
其他可以抄走的相关图象
比如说基础设施做成时序图、网页按钮点击等图象，只要能想到的场景，基本都能满足用户可观测的需求，但实际情形，需各自探索。这儿我把上面图象的json结构列了出来，将下面json解析，基本就能看到，大概20多张表格，有树形矩阵，时序图，漏斗图，排行榜。感兴趣的朋友可以解读一下，如果须要可以把variations的json进行解析，就能看到各种图象了。再不行可以私信我。
注意
json中统计数据已做脱敏处理。
image.pnglcp tcp
image.pngimage.pngimage.pngimage.pngimage.png lcp ssl
image.pngimage.pngimage.pngimage.pngimage.pngimage.pngimage.pngFCP ssl
image.pngimage.pngimage.pngimage.pngimage.pngimage.pngimage.pngloading time ssl 3 d
image.pngloading time tcp 3 d
image.png来自观测云高级技术专家刘刚https://juejin.cn/post/7163630871491117087
