来点实际的吧

说一下我的想法（吐槽），我们是否对过程太过痴迷，忘记了我们要什么？文末给出我认为的好的标准

比如：大家仿佛都在看框架、工具包和开发过程中的内容，这点可能是因为工期紧张，留给前端开发的时间不够，但996已经常态化的情况下，我们是不是该审查一下我们的结果：

1. 页面是否秒开？
2. 页面报错多少？
3. 页面事件多久响应？

举一个例子，有关微前端

举个例子：微前端，微前端到底要解决什么问题？ 一个网站，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，<5s
• good,小于2.5s

然而谷歌给出的非常宽泛，而且到现在，已经有很多年，所以推荐改为：

时序数据指标，基线在1.5s，波动不大（非量化指标），max不得超过1.8s，保持向下趋势

loading time

谷歌没有对这个指标做推荐，所以拍脑袋定了以下这个数据

时序数据指标，基线在500ms，波动不大（非量化指标），max不得超过800ms，保持向下趋势

页面交互相关指标

页面交互会出现很多事件，万事开头难，我这里从三个维度来考虑，这三个维度分别是

• 时间响应时间
• 卡顿次数
• 错误次数

action duration

每一个事件，从用户点击那一刻开始，到页面变化之间，用了多少时间？

时序数据指标，基线在500ms，波动不大（非量化指标），max不得超过1s，保持向下趋势

long task count

页面中是否有卡顿，也就是说是否存在代码执行时间过长的情况。

时序数据指标，基线在500ms，波动不大（非量化指标），max暂定，平稳或非向上趋势

errors

页面是否有错误，这个错误可能是网络、代码、甚至是设备情况，但一切都不是应该发生错误的借口。

时序数据指标，当前值即基线，始终保证下降趋势

评分思路