性能优化总体思路
性能优化这件事我觉得应该是这样的思路，这篇就来讨论 step2~3，(＾－＾)V
定义需求
首先看看性能我们能关注到的都有哪些，其实广义的性能也包括了稳定性 ⚖ 和安全性 🔐 。
一般情况下，不同的网站类型关注的点不一样，这个要结合具体的业务去定。假设我们就是一个官网页面，我们就拿以下两个举例吧
监控方案技术选型
选型之前我们需要捋一捋我们关注点关联的原因，我们对这些原因也需要监控。这样，当表现不好时，我们才能基于监控平台的数据去做分析，要不然我们只是看个结果，啥都分析不出来更无法优化了。
- 首屏时间：监听前端静态资源加载的耗时、接口的耗时、节点无变化的时间点。
- 白屏率：我们关注的白屏是资源加载结束后，那也就是说我们关心的白屏情况是首屏的，并且由错误引起的，排除了网速过慢的原因。由此推断我们需要监听的是 JS 错误、接口错误。 所以最后我们需要平台具有至少以下5个内容的监控
服务链路啥意思？ 如果接口调用链路很长，不是浏览器-接口（直接读取数据库）-浏览器，这样简单的流程；而在接口这步骤里面又有xxx服务-xxx服务-xxx服务-数据库，甚至是树状的，只是浏览器端无感知，那么接口这部分的监控会更复杂，要对整个链路中每一个调用环节都具备失败率和耗时的监听。
一般来说接入监控了，我们不可能无时无刻盯着那么多细节吧，所以呢，监控平台得有这3种能力
让监控上一个level，一般QA都会配合去解锁这三个技术动作，不过这种需要贴近业务功能的，一般监控平台很难具备这样的能力。
ok，已经清楚需要啥了！到了货比三家了，比啥呢？
- 监控内容完备性：有些平台你想要的都自动采集，不用手动写代码，更方便咯
- 大盘&报警配置的灵活性：有些平台大盘没办法自定义，five！有的报警没办法配波动，只能是绝对值，不好用！
- 错误追踪&分析能力：有个JS报错，想找到源码哪个位置报错，好不好找呢。白屏率这么高想多维度看看分布情况，比如地区、设备类型、浏览器版本能不能看到呢。
- 社区支持性：感觉监控的数据和预期差太多，想知道是不是使用的姿势不对，没人理你，不能选！
- 费用：啥啥都满分，但是贵，性价比还是要考虑滴
Sentry VS 111 VS 222
说了这么多都是做事的方法，如果想直接看到底该选哪个，okok，给自己挖个坑，对比一下第三方的各类监控平台。不过一般公司基建有这个东西，都直接用公司的。毕竟在社区支持和费用上肯定是满分了。
接入监控
接入监控的方式通常取决于具体平台，平台样子大概是酱紫
Sentry 接入
假装第三方平台对比之后选了Sentry。待补充