首页 » 前端知识 » 正文

前端性能优化工程化进阶

网页性能对前端同学而言从来都是个熟悉的话题,隔三差五的听到某某页面性能提升,数据明显改善的消息并不足为奇,这反映的是前端同学对体验的执着和追求,一个不关心页面性能的前端一定不是个好前端。

可是前端在高速发展,思路在迅速转变,如果你提升页面性能的方式依然停留在对 N 年前雅虎 34 条黄金法则的人工套用,那么阅读这篇文章也许是一个好的开始。

对于前端性能优化,在不同的实践阶段会有不同的认识,两年前我曾总结过《web前端性能优化进阶路》,自认为当时对性能优化的理解已足够深刻,而今看来,还差着火候,那就新增两条对性能优化的新认识:

性能优化的目标很重要,但是实现目标的方法更重要!

前端性能优化要走向自动化、工程化。

既然聊到了工程化一词,那什么是工程化?我个人理解工程化是把经验技巧、个人知识流程化、规范化,建立一个可重复创造优秀产品的最优环境。

为什么工程化在前端领域会火起来?我想这与前端高速发展所导致的开发环境的不稳定、不成熟是分不开的。你如果与后端 java 同学谈什么工程化构建,他估计会觉得你是喵星人… 但是工程化的思维很重要,适用于各个领域,它会促使你去思考和沉淀,进而产出可复用的工程化成果。

回到性能优化的主题上,人家雅虎老大哥都给咱们前端总结出 34 条黄金优化法则了,那可都是实实在在的经验干货,如果我们一直停留在为优化而优化,优化效果保持不了几天又得重新优化的状态,那实在是作践了这些经验,为什么不固化成可持续保障前端性能的工程化产品呢?这才是令人激动、充满挑战的新方向!

— – – – – – – – – – – – – – 心灵鸡汤结束,进入技术广告时间 – – — – – – – – – – — – – – – – – –

令人欣慰的是,1688 前端在过去的一年多时间内,无论是在 PC 还是无线领域,都已结出了前端性能优化的工程化硕果。

一:PC 时代的性能优化工程化产品 — StyleCombine

StyleCombine 我们称其为服务端的模块加载器,这是一个为前端性能而生的极致化产品。以工程化的方式自动实现了雅虎 34 条守则中的 10 条,可轻松部署到 Nginx/Apache 服务器上,且无视你的应用类型( java、php、nodejs 通吃 )。

它的极致在于甚至可以在服务端解析 AMD/CMD 模块的依赖关系,将子模块的 url 自动进行请求合并。

  它的极致在于已发展为 1688 后台服务器的默认配置模块,经历过千亿次访问的反复考验,试问有几个前端产品可以如此深刻地影响到后端架构?

这是值得我们骄傲的前端工程化产品,也值得我们对其不断地优化和完善!

styleCombine 系统原理图:

二:无线时代的性能优化工程化产品 — H5增量包机制 & Style Diff Center

性能体验是无线产品的命根子,可经过 PC 端性能优化工程化的锤炼之后,我们已不满足于单个页面性能上的修修补补,而目标在于性能优化成果的框架下沉和工程复用。于是有了 H5 增量包机制,同时也有了 Style Diff Center,而工程化的思路也最终完全下沉到 1688 主客 Wing 框架中。

但是无线 H5 应用性能优化的工程化之路,我们只是刚刚开始,还远未到极致。 当你看过腾讯同学的这套字节级别的增量更新机制时,相信你在感叹极致的同时,也会意识到我们能做的事情还有许多…

附上 H5 增量更新机制工作原理图:

结束语:

  前端性能优化从来就该是技术活而非苦力活,但如果你把技术活做成了苦力活,那么就从现在起补充些工程化的思维吧,祝工程化之路硕果累累!

发表评论