思考性能优化 2023-09-01 08:52 folder 优化 label 性能优化, 优化, 性能

其实最近也是受到了一些文章的启发，所以文章的标题会取这个，也比较怪异吧。

说起来前端的性能优化其实就是从资源入手，从浏览器运行时入手。

当然了，如果网络层面也算的话，也可以从网络层面入手。

资源优化

比如对从项目业务的角度出发，分析编译代码，拆分业务场景时需要用到的代码，移除不必要的模块，本质是分析无用代码，并剔除。

同样的，可以抽离减少各模块中的公共依赖模块。

比如对用户上传的资源进行相应的压缩缓存，用户读取时加快页面的加载速度，减轻服务器的负担。

比如服务端接口的必要合并、网络请求的缓存以及服务间通信使用 gRPC 。

运行时优化

比如将一些包含大量计算的逻辑交由 WebWorker 来执行，虽然说线程通信也同样存在着性能的开销，但是比起大量计算的逻辑来说，这些开销似乎也不算什么。

比如通过对页面渲染任务进行拆分，以保证重要的内容优先渲染的优化逻辑，从用户体验的角度来说会是一个不错的选择，但是会产生额外的渲染任务调度拆分的开销。

从火焰图其实也可以排查出业务中存在的不必要的 JS 执行时间，对应的将其进行优化，并且可以减少不必要的重新渲染页面逻辑。

在一些交互高频的操作场景下，可以考虑使用原生语法代替框架带来的性能损耗。

无止境的优化

其实让我比较纠结的就是，优化这件事件总是针对当下，而代码设计也总是针对未来，但是在团队开发的环境中，怎样可以避免因为业务迭代产生的优化失效？

如果说是需要通过人工的方式来持续的做这件事情的话，未免也太无止境了，会让人崩溃。

就算掌握了这些技巧，针对当前的版本来说是最优解，但是产品肯定会一直的迭代，而优化如何能够轻松的跟上迭代的步伐呢？

这是一个引人思考的问题，我也暂时还没解出来……