Chrome H5性能分析初探(1)

序言

很多时候，或忙于业务实现，或者忙于其他各个不同的事情
系统上线了，我们更多的关心功能上面一些东西
系统性能和前端监控，常常会被我们忽略

在要求不高的程序员（说的就是自己），前端报错没啥大不了了
因为很多 api promisify 之后，又使用 async/await 去处理
只要里面 reject, 那 await 就会直接 throw 了
假如每个都去 try/catch 感觉就会很麻烦
所以自然而然，对错误处理监控不怎么在意了

不怎么在意的前端性能

至于性能方面，更是不会在意，原因在于，
一方面 spa 本身性能就好 (有误：取决于浏览器),
另一方面，大部分中小型公司对于前端的考核，往往是以完成的功能去算，而不是监控啊性能上的

大部分的线上错误也往往出现在后端，这使得后端必须有监控，
而前端是测试最容易看到，测到，反复跑的，这一定程度上降低了发现前端 bug 的难度

当然前端在很多场景是需要性能和日志监控的，用于不断优化迭代自己的产品和代码。

不过对于一般的中小型创业公司来说

过早的优化是万恶之源

创业公司还是要更多的在自己的产品内容上下大量的工时

等到业务逐渐稳定，或者发现 耦合度越来越高，系统难以修改的时候
去下刀子，不过这时候可能也有点晚，成本也高

所以啊！还是要有厉害的架构师，在一开始就把握全局，来规避大量可能出现的问题

优化和监控

我这方面也找了一些相关的资料

监控方面：找了鼎鼎大名的 @sentry

优化方面：我打算先从基础学起，即 chrome 调试控制台里的 Performance (这个需要录制的玩意), 和浏览器的全局对象 window.performance 里的 api 入手

后续也会写一些文章，来记录一些学习的过程

刚刚也试了一下调试自己网站的性能

花花绿绿的，完全看不懂
没事，以后逐渐会看懂的