前端CategorySubscribe

前言 趁空闲时间又开了个新坑，记录下目前自己遇到过的一些前端性能优化相关经验总结 希望有朝一日我能把所有还在 draft 阶段的坑都填了 这次准备发一系列文档，预计在6月前完工。 因写内存泄漏文档时发现坑挖太大了不好填，于是这次改进为挖多个小坑一个个填 内存泄漏文档的坑也准备拆一下，不然填不动了，希望有朝一日能完工 何时应该考虑优化性能 性能优化的目标 先考虑这样的例子：玩游戏的时候掉帧，会让玩家很难受，而当开启显卡的帧生成功能时，尽管它实际上增加了输入和画面延迟，但玩家几乎感知不到，反而会感觉游戏的体验更流畅了。而帧生成做的事情，其实是将帧数提升到玩家的舒适范围内，并且保证玩家尽可能感知不到额外的输入延迟，对玩家而言就是游戏性能变得更优了。 类似地，当我们自己使用软件时，一般只有在出现明显卡顿或者延迟的时候才会感知到。 故性能优化的目标可以概括为：将延迟和卡顿降低到用户的可接受范围内。 优化的时机 先上结论：绝大部分情况下，只有出现性能瓶颈的时候才应该考虑优化性能。 性能优化的投入与回报类似一个对数曲线，越往后，付出的成本和回报就越不成正比。因此，如何平衡软件性能与开发成本通常是我们每个开发者都要面临的问题。当然，如果你是个人开发者 or 技术爱好者，那么保证自己的产品在每个细节上都做到性能优秀可能更加适合，但如果是一个全职开发者，并且公司是业务驱动而非技术驱动，那么保证自己可以快速实现功能可能是更重要的。 大部分情况下公司都是业务驱动，即使有些公司声称自己是技术驱动的，个人认为真正的技术驱动公司只会在老板不在乎利润的情况下出现，almost impossible 🙁 因此，在出现性能瓶颈，也就是用户能感知到卡顿或者延迟的时候再去考虑性能优化，是实际开发工作中的性价比之选。 常见前端性能指标 指标概览 让我们先来看一下目前在前端领域都有哪些常见的指标（留下印象即可）： First Contentful Paint (FCP)：首次内容绘制，衡量从网页开始加载到网页任何部分呈现在屏幕上所用的时间 Largest Contentful Paint (LCP)：最大内容绘制，衡量从网页开始加载到屏幕上渲染最大的文本块或图片/视频元素所用的时间 First Input Delay (FID)：首次输入延迟，衡量从用户首次与页面互动（点击链接、点按按钮或使用由 JavaScript 提供支持的自定义控件）到浏览器实际能够响应该互动的时间 Interaction to Next Paint (INP)：衡量与网页进行每次点按、点击或键盘交互的延迟时间，并根据互动次数选择该网页最差的互动延迟时间（或接近最高延迟时间）作为单个代表性值，以描述网页的整体响应速度 Time to Interactive (TTI)：可交互时间，衡量的是从网页开始加载到视觉呈现、其初始脚本（若有）已加载且能够快速可靠地响应用户输入的时间 Total Blocking… Continue Reading 前端性能优化之——预备篇