思考性能优化
其实最近也是受到了一些文章的启发，所以文章的标题会取这个，也比较怪异吧。
说起来前端的性能优化其实就是从资源入手，从浏览器运行时入手。
当然了，如果网络层面也算的话，也可以从网络层面入手。
资源优化
比如对从项目业务的角度出发，分析编译代码，拆分业务场景时需要用到的代码，移除不必要的模块，本质是分析无用代码，并剔除。
同样的，可以抽离减少各模块中的公共依赖模块。
比如对用户上传的资源进行相应的压缩缓存，用户读取时加快页面的加载速度，减轻服务器的负担。
比如服务端接口的必要合并、网络请求的缓存以及服务间通信使用 gRPC 。
运行时优化
比如将一些包含大量计算的逻辑交由 WebWorker 来执行，虽然说线程通信也同样存在着性能的开销，但是比起大量计算的逻辑来说，这些开销似乎也不算什么。
比如通过对页面渲染任务进行拆分，以保证重要的内容优先渲染的优化逻辑，从用户体验的角度来说会是一个不错的选择，但是会产生额外的渲染任务调度拆分的开销。
从火焰图其实也可以排查出业务中存在的不必要的 JS 执行时间，对应的将其进行优化，并且可以减少不必要的重新渲染页面逻辑。
在一些交互高频的操作场景下，可以考虑使用原生语法代替框架带来的性能损耗。
无止境的优化
其实让我比较纠结的就是，优化这件事件总是针对当下，而代码设计也总是针对未来，但是在团队开发的环境中，怎样可以避免因为业务迭代产生的优化失效？
如果说是需要通过人工的方式来持续的做这件事情的话，未免也太无止境了，会让人崩溃。
就算掌握了这些技巧，针对当前的版本来说是最优解，但是产品肯定会一直的迭代，而优化如何能够轻松的跟上迭代的步伐呢？
这是一个引人思考的问题，我也暂时还没解出来……
- 本文链接: https://zongzi531.com/2023/09/01/%E6%80%9D%E8%80%83%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96/
- 版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 3.0 许可协议。转载请注明出处！