课程已经进入尾声，很多同学在留言区分享了自己的想法和经历，一些前端同学说自己好像在日复一日地陷入“开发，提测，上线”的循环中，尤其在做一些运营活动时，每次做的就是简单重复但占用时间的事儿。好不容易业务节奏放缓，有了一些时间去思考、沉淀自己的经验，却因为缺少方法论，不知道该怎么去帮助业务提高效率和质量，最后还是去加班消化一些业务需求……

相比后端同学要考虑整个 App 或者站点的架构来说，前端同学负责的业务复杂度低一些，很容易只关注页面，看不到业务的全貌，从而很难发现业务中的痛点问题。比如在交易业务中，前端同学负责的就是一个个下单购物车环节的页面（像交易正向逆向链路，状态机这些业务难题都是后端去解决的）很容易感觉自己没什么技术成长。

那你要怎么改变类似的局面呢？答案是寻求专业能力与业务产出的平衡。

专业能力和业务产出的平衡

从一些同学的经历中，我们可以简单总结出这样几个情况：没有时间思考；缺少方法论；只见树木不见森林，接下来我们来分析、解决这几个问题，实现专业能力与业务产出的平衡。

首先，没有时间去思考，是确实没有时间还是效率不高。

确实没有时间的话，你要看是不是长期缺人需要补人，还是短期借调解决一下？一般来说，我会看团队内 P0 需求（对业务来说，做了有收益，不做有损失的重要需求，我们称为“P0 需求”）是否有积压？如果有，要考虑补人。同时业界有一个后端和前端人数 2:1 的黄金比例；还有一个运营+产品和前后端研发人数 3:1 的比例。如果超过这些比例阈值，就需要补人。

如果效率不够高，先不要考虑补人，而是提高效率。比如和后端数据接口联调需要花费很长时间，那我更愿意从 3 个人中，抽调 2 个人做一套数据接口平台，解决 API 文档存放及数据MOCK 的问题。有了该平台后，前端和后端制定完接口后，就可以分别开发，并在后端开发完接口后，可以对接口做一些测试，从而大幅提升联调效率，原来 1 周的项目，需要一半的联调时间（ 2 天），现在半天就联调完了。

其次，缺少方法论的学习。

前端工程师做好业务交付的本职工作很重要，但是仅仅埋头苦干是不够的，需要我们还得能抬头看天，最好是能学习一些方法论，然后去实践它，这里我以借助业务周期去做完成一些规划来介绍。电商业务节奏方面会有一些规律，在每年1~2月，会有 2 周规划期，规划期间需求还没出来，前端同学的业务压力很小；规划期结束后会进入冲流量阶段，6 月中旬开始做 6.18 ，然后持续到 6月底，这期间会有 1 周左右的时间 review 目标完成的情况；7 月初业务会梳理下半年目标，随后又有 1 周时间节奏放缓；双十一前后，又要忙碌起来；年底节奏会放缓，有 2 周左右的时间做总结、评定绩效和评优等工作。

整体上看，一年间，5 周左右的时间节奏较缓，利用好这段时间，你可以去做一些偏长线的事情，比如建设脚手架技术体系、基础组件，提升性能体验等，这样一来，我们的效率和体验可以大幅提高。

最后，只见树木不见森林是在提醒你理清业务架构全貌。

作为前端工程师要界定好前后端的边界和职责，前端的职责很重要的一点是效率提升和质量提高，比如我们要解决项目延期导致的效率问题，通过对问题分析后发现是提测阶段质量不高，修复问题要占用很多时间，解决完问题后，Bug 还会往复。那么前端同学就需要提升代码和自测的质量，提测代码前要过一遍冒烟 CASE，冒烟通过才允许提测，这样一来，可以有效解决项目延期问题。

前端职责另外一个重要点是，解决业务中的痛点问题，比如我们有一个对手机做质量检测的业务，检测完可以生成一个质检报告，告诉用户这台手机值多少钱。

那么前端同学需要开发维护一个质检平台，平台上的数据有的来源于线上采集（比如小程序去检测机器摄像头是否好，质检工程师肉眼检查手机是否有划痕等）有的还要通过一些富士康机器人去检测苹果内部硬件有无问题。前前后后用户需要78步才能完成报告的输入。当前端同学结合用户质检情况，改造一些流程后（主要是减少质检工程师操作的步长），31步就可以完成质检，提升了50%的效率，为质检团队节省了40%的人力，给公司带来了巨大的商业价值。

这些业务痛点问题的解决，价值很大，但前提是你要对业务全貌有足够了解。

总的来说，解决上述三个问题，我们就可以保持专业能力和业务产出的平衡，在这种情况下，就有时间去做一些看不见，但是长期有价值的事情（如提升性能体验），这些正是搭建我们成长之路的石梯。

如何成为前端性能技术专家

我会从“专业能力、工程能力、做事方法”三个维度围绕“如何成为前端性能技术专家”去谈怎么搭建你的成长之路。

专业能力

这里我所强调的专业能力是指围绕“前端技术体系”下的技术能力。我们团队有些同学会漫无目的学习一些技术方案，比如 WebAssembly、WebGL等，可这些技术方案在电商业务背景下，暂时没有使用场景；有些技术方案我们经常会用到，比如做性能优化所需的首屏优化手段、离线包和骨架屏等，还有 webpack 打包等知识（这些就是技术体系内的能力）。

针对这些专业能力，你需要去思考它的原理，在什么场景下需要用到，为了解决什么目标，具体做了哪些技术方案，最终取得了什么结果，有什么注意事项，有什么演进。坚持做上述事情，只需要三年时间，就能看到你的明显成长。

工程能力

工程能力指：前端工程师需要具备“持续稳定交付某个产品”所需要的能力，想开发效率高，又想品质有保证，必须依赖工程能力。

这里我要强调的工程能力包含在以下9 个环节中：UI&需求评审、方案设计&评审、WBS分解排期、开发、单侧&自测、代码 reivew、提测、上线、项目总结文档整合。其中，方案设计&评审、WBS分解排期，项目总结及文档整合对成长很重要。

• 方案设计&评审

如果你的项目，每次都是自己出设计方案，没有和别人碰撞过思路，那这个设计能力（有别于UI设计能力，这里指的是前端技术方案设计能力）上限就是你自己。比如我们的前端团队有 70 多人，其中 15 人左右在 BAT 工作 5~10年，他们会在你给出技术方案后，提供建议。比如你遇到“图片上传时内容过大，上传速度慢”原本想通过 webp 图片的方案来解决，但其他同学提议通过 base64 encode 的方式，这样一来，可以把二进制的图片内容编码成文本信息，文本信息可以分组并行传输，大大提高了传输性能。

• WBS 分解排期

在该阶段，前端同学在开发时要预留一定的 buffer，原因如下：

1. 应对项目中的不确定性风险（UI出图慢、PM需求变更、RD接口延期）;

2. 做一些有高要求的事情，比如提升性能体验，秒开率做到 95%。往往这些高要求影响了个人成长速度，如果做每个项目你都对自己提更高要求，短短几年你会有很大提升。

记得某个 Leader 说过这样一句话：“长期做到上述高要求的工程师想不给他涨薪都难。”在开发阶段，我们前紧后松、拼尽全力，做这些高要求的事情，比如体验较好的页面效果。长此以往专业能力提升很快。

做事方法

做事方法更倾向于软素质，比如项目管理能力、规划能力、自控力和影响力等。

如果项目管理能力不好，你会陷入眼高手低的状态。想法很多也很好，但落地下去，不是要不到资源，就是争取不到别人的帮助，或者经常延期，达不成项目目标；规划能力我 03 讲提及过；自控力更多的指持续输出价值。我看过刘墉的一段话，觉得很好，在这里分享给你：

一棵枣树，只有在结枣子的时候，人们才认得它，一旦它不结枣子了，无论它以前结过多少枣子，人们都不会再承认它还是颗枣树。

这也就是说，某一刻输出价值很容易，但通过强大的自控力，源源不断输出价值很难。

针对影响力，我最初的理解是你对外界和别人的影响，其实这背后的本质是利他性，你帮助别人实现价值的过程中，也实现了自己的价值。比如当前业务的目标是转化率不够，那你如果能帮助他提升 3%的转化指标，这种影响力才 OK。

小结

总的来说，今天我结合自己的经验，带你了解了怎么寻求业务开发和专业性提升的平衡，以及工程师的成长之路。这个过程中，贯穿其中的就是“高要求”这三个字，而体验性能正是非常重要的一项。

之前蚂蚁金服的周玉伯说过一个守正出奇（这里是JI，多一点的意思），就很好概括了这一点。

• 业务为正： 业务交付的效率怎样？是按时交付、提前交付、还是延后交付，和业务方协作怎样？质量如何？

• 能力为奇： 包括专业能力、工程能力、做事方法等。

从专业能力来说，我一直把工程师比作搬砖工人，无论你搬砖能力如何，你都需要通过盖一栋房子，来体现你的专业水平，这栋房子就是业务，所以我们经常说业务是立足之本。而前端能力的差异在往大了说是效率和质量（包含体验），效率自不必说，质量中很重要的就是线上运行质量，其中性能体验是我们能够给用户提供的一个重要价值点。

下面给你留一个问题？

这一讲你读完会有哪些感触？

欢迎在评论区和我沟通，时间过得很快，马上我们就进入结束语——性能优化实践之路。

---

你好，我是溪风，时间过得很快，一晃 2 个多月就过去了。

总的来说，这段磨稿经历让我印象十分深刻，我几乎是每天晚上 10 点到家后，开始写稿、改稿、录音。记得有一次要录 06 讲，那时我正好出差到深圳，录音的时候已经到了凌晨，又因为赶上外面施工，总是有噪音，顺利录完以后天都快亮了。

还有一件印象比较深的事儿，那就是课程上线之后，很多同学积极地在留言区互动，有的问题很有意思，比如 SDK 在弱网下的上报策略，还有离线包解压失败这么小概率的问题，竟然也有人遇到。当然了，我最感动的是很多同学给了我鼓励，肯定了课程的内容，正是这种声音，让我一直坚持持续输出内容。

今天是专栏的最后一讲，为了让你更系统地了解前端性能优化的全貌，我想和你一起回顾一下前面的内容，并分享一下性能实战过程中的注意事项。

前面我带你学习了“性能优化方法论（01~03）”“性能优化指标采集及上报（04~06）”“性能诊断与优化手段（07~11）”“Hybrid 下的进阶优化手段（12~16）”“一线大厂性能优化体系演进（17～19）”等内容。

这部分内容通过发现问题、立项、项目实施、专项测试、收益评估等过程，形成了一条横轴（ X轴），又通过一线大厂性能方案对比，形成了一条纵轴（Y轴），加入时间因素后，前端未来在 RN、Flutter上 的演进形成了一条时间轴（Z轴）。

之前，你一直是一步一步跟着课程来形成前端性能体系，但现在你就要通过实践来夯实自己之前梳理的前端性能体系了。那么在这个实战过程中，**你会遇到哪些问题呢？又该怎么解决呢？**这里我提供一些经验，希望你能有所收获。

性能优化实践过程中最难的点，还是发现问题，我们之所以觉得问题难以解决，就是因为没有发现问题的真正所在。所以性能监控预警平台至关重要，你要知道怎么搭建该平台，怎么设定、采集和上报性能指标，性能监控预警平台上的数据指标对应的标准是什么，学会从性能指标异常推导出性能问题。

这很像医生看病，当一个发烧病人来到诊室，医生通过验血等手段了解你白细胞、中性离细胞等指标，然后和标准进行对比，诊断是病毒性感冒还是细菌性感冒，并开对应对药方治疗。当然，如果你目前还没有能力去开发平台，可以使用第三方，比如阿里云的性能平台或者听云 APM。

无论是否需要自研平台，性能诊断都是一个难点，值得你一遍一遍反复学习。我们会在性能平台上看到各种各样的问题，那怎么去诊断、发现代码修改点就非常重要。这时如果你比较了解团队过往出现的性能问题，那你定位性能问题的速度也就越快；如果你能多了解工程化链路和浏览器渲染原理等瓶颈点，就越有助你定位到问题。

通过一遍一遍练习对性能问题的定位与诊断，你要努力达到：利用性能体系建立强大的心理表征（心理表征是一种与我们大脑正在思考的某个事物、某个观点、某些信息或者其他任何事物相对应的心理结构，棋手的心理表征是过往的一盘盘棋局），吸收和考虑更多性能相关的信息，把 webview、浏览器、App，前端代码当作一个整体来思考，快速定位到性能问题。

当你发现问题，并成功定位问题之后，接下来的重点就是掌握优化手段。 很多同学会因为缺乏对节奏的把握，影响优化结果，比如明明时间很紧，要快点拿到结果，你却选择了一个长期的方案，导致迟迟看不到结果，项目被 cancel 掉。所以我重点讲一下这块儿。

一般来说，业务报出性能问题时，比如手机首页访问慢的问题，需要一个短平快的解决方案（比如一周内需要完成上线），快速上线。

因为时间的原因，这个性能优化方案过程中肯定是要有取舍的，比如在最终效果方面，性能指标定到首屏平均 1s 就可以了，更多是短期方案，也就是前端工程师可以独立完成的优化手段，如懒加载、离线化、异步化、骨架屏和缓存等手段，做完上述优化后，一般可以做到性能大幅提升，极限秒开。那为了进一步提升性能水平，让秒开率也达标，你可以同时准备一些中期需要的基础建设，比如离线包方案和 SSR 相关的 Node 生态内容等。

接下来就要定一个中期目标（比如 半个月周期的项目），效果方面，秒开率提升到 80%。此时就可以用一些中期优化方案，比如首屏内容做到稳定秒开，优化手段就是性能的稳定治理，需要利用一些横向资源，比如客户端资源，接入前期准备的离线包、SSR 等方案。与此同时，也要开始做一些长期的准备，比如webview 层的优化，又比如预请求、预加载、预渲染的方案。

如果你可以再提高对自己的要求，比如二次做到闪开、首次秒开、且白屏时间缩短，需要使用一些长期方案，比如引入 QA 团队做好专项测试，保证性能长期稳定，建立起性能预警问题的解决机制。一般来说，要实现上述的要求，需要跨团队的深度合作，长期方案实施时，就需要我们设定好预期收益目标，说服业务投入资源到项目中去。

以上就是优化整体体系以及实战过程中的注意事项，我简单将整个课程的内容进行了梳理，希望能让你明确性能优化的重难点，以及今后努力的方向。

或许你觉得在互联网时代知识很容易学习，实际上性能知识比较海量，如果你单纯依赖碎片化的学习，就会越来越无法将知识体系化，更别提提升性能优化的技能了。就像我刚开始做性能优化时，因为缺乏体系化的知识，看了很多公众号和零星的课程，最终还是不知道性能优化整体上该怎么做。

---

精选评论

*鲲：

完结撒花

**6448：

完结撒花

**坤：

前面1元买了很多拉勾专栏，这是第一个看完的，感觉收获很多，打算据此写个方案进行实践。感谢🙏