低成本的前端性能优化

说到前端优化总让我想起很多灵感,这些灵感来源于对数据提升的“感性”预测,举个例子:我总是幻想把 Javascript 都重构了,网站的 TTI 可以提升个 10% +,但是除非你的代码中有严重的逻辑问题,这样的想法总只是幻想,因为重构代码而带来初始化性能提升的实在是太有限了,远远低于 5%,所以做重构这样的事情更重要的目标是让应用更易维护,以及有良好的架构能支撑 2 年左右无需再次重构。

还有一个迷思是,把大块的 javascript 文件分割成若干粒度适中的小块,使用异步并行加载,似乎并行处理总能带来  n 倍的 javascript 加载性能提升,实际上也没有,如果纯粹是提升脚本的载入速度的话,这样做还不是最佳实践,我想对于 TTI 特别重要的产品才需要这样调整顺序和时机去并行异步加载脚本。

所以反过来想的话,可以把网页上的功能按体验上的重要程度列出来,然后做优化,而不是从脚本本身入手,Facebook 早就已经做过这样的事情了,还有更激进的方式是如果用户根本就使用不到、看不到的内容,其实是不需要初始化的。优化这一部分内容就是投入产出比会比较高的优化。

我做过类似的优化例子:

豌豆荚的应用导航页面(app3.wandou.in),优化前的页面会默认加载 100+ app 的图标,这些是导致用户长时间等待功能可用的罪魁祸首,经统计,这些页面在实际用户端的首次访问平均加载时间(window onload)达到 4600ms +,因此按照上面的思路,优化的方案是把第一屏用户能看到的 app 以后的其他内容延迟初始化,假如页面上有 6 个模块,其中有两个是需要随着页面初始化的,则这两个模块的内容使用正常的 html 标签加载,其余的四个模块的 html 源码使用 textarea 包起来,如果用户滚动到一定位置就把需要展示的模块初始化,这些图片和 app 的其他信息才会展示。

一眼看上去像是图片的 lazyload,其实是把图片扩大到网页的其他内容,选用 textarea 而不用其他标签是因为计算滚动触发时这个标签最省力气。

这种方案上线之后用户首次访问的平均加载时间只有 2300ms 。

这样的反向优化不能算网络优化,也不算代码优化,是对产品逻辑的优化,这样的优化往往容易成为性价比极高的方案。

Published by

Z.J.T

Product Designer from Wandou Labs

  • milo

    受益了~拜读