来点实际的吧
说一下我的想法（吐槽），我们是否对过程太过痴迷，忘记了我们要什么？文末给出我认为的好的标准
比如：大家仿佛都在看框架、工具包和开发过程中的内容，这点可能是因为工期紧张，留给前端开发的时间不够，但996已经常态化的情况下，我们是不是该审查一下我们的结果：
- 页面是否秒开？
- 页面报错多少？
- 页面事件多久响应？
举一个例子，有关微前端
举个例子：微前端，微前端到底要解决什么问题？
一个网站，10人开发的小团队，搞微前端做什么？
但也没有定论，pv百万以下，就不能要搞微前端了？
这里的例子是想说明，我们究竟想要什么？
前端同学应该更多的把精力放在产品上，而不只是过程中，并不是过程不重要，但是
- 是否webpack或者rollup，
- 是否ssr还是csr
- 虚拟dom，或者是否diff算法
这些是最重要的吗？
很多环节都很重要，但最重要的是什么？不应该是最后的产品吗?
前端文化圈应该谈论的是什么？
我认为打招呼，至少不是问：
- 上微前端了吗？
- 上node了吗？
页面指标可观测
除了吐槽，还是要讲讲那些很重要的东西，不是要内卷，或者创造新名词，是希望能有一种思维方式，能够从其他角度，看一下当前到底是什么情况。
这里估计可观测性这个词，已经从很多方面，大家都看到或者听说过，我认为网站性能可观测需要考虑的两个维度：
- 页面加载
- 页面交互
今天就从这两个维度来看，定性、定量给出一个应该有的标准。
页面加载
以前常用白屏这个词，但是这个其实一直没有准确的定义，而且白屏和用户能感知到的体验，差别太大；
现在基本会用FP，FCP，LCP，loading time来量化页面加载的时间。
对于需要从数据库读取大部分业务数据来到前台渲染的页面来说，fp、loading time以fcp都不是非常推荐了。
谷歌现在推荐使用最大内容渲染（LCP），虽然这个指标值和实际用户体验仍有差距，但已经非常接近实际网站加载的速度了。
LCP
谷歌推荐lcp的数值
- bad, >5s
- normal,大于2.5s，
- good,小于2.5s
然而谷歌给出的非常宽泛，而且到现在，已经有很多年，所以推荐改为：
时序数据指标，基线在1.5s，波动不大（非量化指标），max不得超过1.8s，保持向下趋势
loading time
谷歌没有对这个指标做推荐，所以拍脑袋定了以下这个数据
时序数据指标，基线在500ms，波动不大（非量化指标），max不得超过80服务器托管网0ms，保持向下趋势
页面交互相关指标
页面交互会出现很多事件，万事开头难，我这里从三个维度来考虑，这三个维度分别是
- 时间响应时间
- 卡顿次数
- 错误次数
action duration
每一个事件，从用户点击那一刻开始，到页面变化之间，用了多少时间？
时序数据指标，基线在500ms，波动不大（非量化指标），max不得超过1s，保持向下趋势
long task count
页面中是否有卡顿，也就服务器托管网是说是否存在代码执行时间过长的情况。
时序数据指标，基线在500ms，波动不大（非量化指标），max暂定，平稳或非向上趋势
errors
页面是否有错误，这个错误可能是网络、代码、甚至是设备情况，但一切都不是应该发生错误的借口。
时序数据指标，当前值即基线，始终保证下降趋势
计算器
以下是我自己写着玩的计算器，不只是关注当前指标，还要看指标的趋势。
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
