前言

性能对于开发人员来说是一个经久不衰的话题,也是用户体验的重要因素。当打开一个页面或App时,无论你是在寻找商品、阅读高质量的新闻,还是在看有趣的短视频,都不愿意等待。

很多人可能有耐心花费一两个小时在一家火锅店门口排队,但几乎没有人愿意等30s去加载一个短视频。事实上,对于大多数的App或网站来说,别说是30s,即使是3s也足以让大量用户放弃等待转而去做其他的事情。

Google发现,如果页面加载时间超过3s,53%的移动网站访问活动将难以为继。

安迪-比尔定律

有人可能会问,如今计算机和手机的性能都在飞速发展,性能优化还重要吗?5G时代已经来临,无处不在的高速网络是否已经让我们不需要再那么在意性能问题?

其实,在Web领域,安迪-比尔定律仍然成立。

安迪-比尔定律源于“Andy gives, Bill takes away.”。Andy指的是Intel原CEO安迪·格鲁夫,Bill则是Microsoft原CEO比尔·盖茨。这句话的意思是,Intel一旦向市场推广了一种新型芯片,Microsoft就会及时升级自己的软件产品,以匹配新型芯片的高性能。硬件提高的性能,很快就被软件消耗掉了。

对于Web领域来说,网络和终端设备的性能确实在飞速发展。然而,几十年来Web技术也变得越来越复杂,在网络上传输的不再是一个简单的页面。Web技术本身也在不停地更新换代,传输页面的体积、执行脚本的复杂度等都在不断增加。

让我们回到万维网(World Wide Web)诞生的20世纪90年代,第一个网页浏览器WorldWideWeb仅支持HTML格式的图片、文字和超链接(见图0-1)。

经过几十年的发展,在网络上传输的内容越来越丰富,使用浏览器打开的不再是一个仅包含图片、文字和超链接的页面,而是高清流媒体、实时网络直播,甚至是直接在浏览器中运行的专业协同应用。

图0-1 第一个浏览器WorldWideWeb

可以预见的是,这种复杂度会日益增加,越来越多原来只能在桌面平台上运行的大型软件也出现在了Web平台上,以借助Web平台易于传播、跨平台等特性,充分发挥协作互通的优势。例如,如图0-2所示的设计协同工具Figma,就可以完全运行在浏览器中,而以往这种专业的设计工具只能作为桌面软件使用。

如图0-3所示,从2011年到2020年,桌面端和移动端的页面传输字节数(加载完成一个页面需要传输的数据量)逐年上涨,分别约增加了329%和1178%。

同时,随着网络基础建设的不断更新换代,更多原来受限于基础设施无法广泛满足的需求大量涌现。例如,近几年短视频的兴起,很大程度上就是因为大多数用户的网络能够在可以接受的时间内加载完视频。用户随时看新鲜且有趣视频的需求一直存在,只是之前的硬件条件难以满足用户的需求。

图0-2 运行在浏览器中的设计协同工具Figma

图0-3 HTTP Archive关于页面传输字节数的变化趋势

这就是安迪-比尔定律在Web领域没有失效的原因。可以想象,随着未来网络状况的进一步改善,又会有新的媒体和应用形式消耗提升的网络传输能力。它既可能是基于AR、VR的视频会议、协作办公,也可能是更加复杂、支持更多人参与协作的办公协同工具。尽管提供硬件和软件的可能不再是Intel和Microsoft,但只要人们对于新功能和体验的追求一直存在,性能优化就是经久不衰的话题。

性能优化的魅力

上面从现实的角度出发解释了性能优化的重要性,可见重视性能优化是有客观基础的。其实,性能优化本身就具备无可比拟的魅力。

很多人都听过斯坦门茨画一条线1万美元的故事,有些人说这个故事反映了知识就是财富,有些人说这个故事反映了细节决定成败。故事的真实性已经无法考证,但是笔者非常喜欢这个故事。

故事是下面这样的。美国福特公司曾经有一台电机出现故障,导致整个车间都不能运转。福特公司请来很多专家检查,就是找不到问题在哪里。于是请来斯坦门茨,斯坦门茨在电机旁聚精会神地听了3天,又要了梯子,爬上爬下忙了很久。最后他在电机的一个部位用粉笔画了一条线,写下了“这里的线圈多绕了16圈”。福特公司按图索骥解决了故障。

在平均月薪为5美元的当时,斯坦门茨索要了1万美元的酬劳:画一条线,1美元;知道在哪儿画线,9999美元。

如果说工程师最大的快乐来自创造,那么笔者认为第二大的快乐来自对精密系统的理解。从中不仅可以领略前人解决问题的设计方案所蕴含的智慧,还能享受抽丝剥茧最终精准找到问题的成就感。

性能优化就是一个典型场景,我们要做的是理解复杂系统并从中找到性能问题的关键所在。有时我们甚至能根据问题的表现和对系统的理解,在没有直接发现具体问题时就推测出出现问题的真正原因。例如,海王星先通过数学推算被发现再被人们实际观测到的过程就充满了预言的魔力。

海王星的发现史如下。

● 1821年天王星(不是海王星)的轨道表发布,但是观测表明轨道存在偏差,于是有人猜测其受到附近一个巨大天体的扰动。

● 1846年,通过数学方法推导出了海王星的轨道,之后开始搜寻,并于当年9月23日发现海王星。

性能优化=分析方法+技术原理

自工作以来,笔者有幸接触过不同场景的性能优化,包括面向计算机的和面向手机的、纯Web技术的和Weex/React Native等技术的,以及国内的和海外的。

每次接触到一个新场景,笔者都发现上一个场景的经验很难直接发挥作用,了解性能优化的读者大多听说过“雅虎三十五条优化军规”,里面总结了性能优化需要遵循的一些规则,如合并请求等。在大多数情况下,直接套用这些规则并不会为页面带来非常明显的性能收益。

但是,其背后的分析思路总是相似的,能够用来找到一套行之有效的方法帮助我们一步步接近性能目标。相比于记住正确但未必有效的具体规则,掌握这些通用的方法能让我们在复杂的生产环境中找到正确的道路。

因此,本书把“度量”、“分析”和“实验”部分放在开头部分,把方法放在具体的技术细节之前,用案例和思考相结合的方式建立面对性能问题时的解决思路,有了方法的指导,我们在遇到具体问题的时候才能进行具体分析。

如果说分析方法是解决性能问题的指南针,那么对技术原理和系统的理解就是照明灯,只有方向但看不到脚下的路是无法前行的。优化一个系统的性能也一样,即使分析出这个系统在某个阶段的性能存在问题,如果不理解系统背后的运行原理,就好像知道方向却看不见路,只能摸黑前进。

笔者在优化过程中常常根据一些有趣的知识来梳理思路,所以在介绍如何做性能优化的同时,也以性能为引子来介绍网络、浏览器、前端技术栈等的技术原理。其中的很多原理读者可能从其他地方了解过,但是带着对性能的疑问阅读本书,可以帮助读者了解更多前人为了更好的体验和性能在这些复杂系统中付出的心血。

关于本书

比较幸运的是,自工作以来笔者在不同的场景一直面临各种性能挑战。刚开始只是打地鼠式地逐个解决问题,在凭着猜测和主观感受进行简单的优化后就认为已经解决了性能问题。随着面临的挑战越来越多,笔者不得不思考如何科学地衡量当前的性能状况、如何科学地分析性能存在的问题和优化方向,以及如何科学地验证优化的效果。

在优化过程中,性能作为一个引子贯穿整个与Web开发相关的各种系统及这些系统的原理,笔者认为这些平时看起来并没有直接作用的理论知识其实可以切实帮助我们改善用户体验,并且改善的效果直接反映为数字指标。

笔者撰写本书一方面是对过去几年的工作进行总结,另一方面也希望能给想要提高用户端性能、改善用户体验但是不知道应该从哪里开始的读者一些启发。对于想在Web技术上更进一步的读者来说,性能也是一个非常有趣的话题和线索。

性能是一个涉及甚广且技术细节较多的话题,笔者在写作过程中尽可能搜集相关标准、资料来验证书中的细节。由于笔者的经验和视野有限,加上部分技术细节存在时效性问题,因此书中难免存在局限和疏漏,如有可改进之处欢迎各位读者批评斧正。