小型全栈式 App RealWorld Conduit 最近更新了其基准测试结果。这款 App 分别采用 18 个不同的前端框架构建,并对它们进行了比较。结果显示,18 个框架当中有 13 个获得了顶级的 LightHouse 的分数(也就是在总分 100 分的情况下获得 90 以上)。在这 18 个框架当中,Svelte、Stencil、AppRun、Dojo、HyperApp 和 Elm 的网络传输负载最低(低于 30KB)。
自称为”演示 App 之母“的 Conduit 是对 Medium.com 的全栈式克隆,采用了一组[API 规范](https://github.com/gothinkster/realworld/tree/master/spec),并带有具备真实世界复杂性的功能。[RealWorld 项目](https://github.com/gothinkster/realworld)核心维护者 Eric Simons 解释说:
> 它就像是[TodoMVC](http://todomvc.com/),只是使用全栈技术实现。RealWorld 向大家展示了如何使用 React/Angular 等框架在 Node/Django 等平台上构建真实的博客平台。开发者可以把它们混合起来,因为它们都遵循相同的 API 规范。
RealWorld 基准测试始于 2017 年,最近更新了针对使用 18 个不同前端框架实现的 Conduit 的评估结果。2019 年的基准测试排名主要关注这三个方面:性能、大小和代码量。
性能分数是通过[LightHouse](https://github.com/GoogleChrome/lighthouse)来评估的。LightHouse 是一个非常流行的用于改进 Web 质量的自动化工具。LightHouse 对性能、可访问性和渐进式 Web App 进行审计,并基于[六个加权指标](https://docs.google.com/spreadsheets/d/1Cxzhy5ecqJCucdf1M0iOzM8mIxNc7mmx107o5nj38Eo/edit#gid=0)给出性能评估分数。这六个指标按照重要程度排序如下:
* TTI([Time to Interactive](https://developers.google.com/web/tools/lighthouse/audits/time-to-interactive)):让一个页面变得可交互需要多长时间。
* 速度指数([Speed Index](https://developers.google.com/web/tools/lighthouse/audits/speed-index)):页面处理内容的速度,分数越低也好。
* FCP([First Contentful Paint](https://developers.google.com/web/tools/lighthouse/audits/first-contentful-paint)):从导航一个页面到浏览器开始渲染 DOM 第一个字节的时间。
* FCI([First CPU Idle](https://developers.google.com/web/tools/lighthouse/audits/first-cpu-idle)):页面达到最小化可交互的时间(不需要等到页面上的所有元素都可交互,只要可以对大部分用户输入做出响应即可)。
* FMP([First Meaningful Paint](https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint)):用户感知到页面主要内容可见的时间。
* 预估的输入延迟([Estimated Input Latency](https://developers.google.com/web/tools/lighthouse/audits/estimated-input-latency))。
LightHouse 将性能分数分为三组。90 到 100 分为顶级,表示性能最好的网站。在 RealWorld 基准测试中,大部分(18 个中有 13 个)Conduit 实现属于这一组。前 13 个框架中包括已经很成熟的框架(如 Elm、Dojo、Vue、Angular、Aurelia、Stencil、Svelte 和 React)、简约型框架(如 AppRun、Hyperapp)、较少被使用的框架(如 Crizmas 或 reframe)以及可编译成 JavaScript 的框架 Imba。
这 18 种 Conduit 实现也根据大小进行了排名。基准测试作者详细介绍了这一标准背后的原理及其计算方法:
> 传输大小是从 Chrome 开发者工具的 Network 页面获得的,包括 GZip 压缩的响应头和响应体……文件越小下载就越快,需要解析的东西就越少。
在性能最好的 13 个框架中,有 6 个(Svelte、Stencil、AppRun、Dojo、HyperApp 和 Elm)的传输大小小于 30KB:
![image](http://upload-images.jianshu.io/upload_images/16033076-baa29f7867af9ad3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
他们通过[k-means 聚类算法](https://en.wikipedia.org/wiki/K-means_clustering)将 18 个框架的传输大小分为 5 类。
框架的特点可以用来解释为什么它们的传输大小可以达到这么小:
* Svelte 自称为”神奇的即逝 UI 框架“,将 API 编译成最优化的 JavaScript。
* Stencil 的运行时只有 6KB,并可以编译成 Web 组件。
* AppRun 和 HyperApp 的体积非常小(分别为 3KB 和 1KB)。
* Dojo 最近推出了自动代码拆分特性,并针对 PRPL 性能模式进行了优化。
* Elm 0.19 针对资产文件进行了优化。
前端框架的繁荣促成了基准测试的流行,这些[基准测试](https://github.com/krausest/js-framework-benchmark)旨在通过各种有意义的方式对框架进行比较。基准测试涉及的框架可能是各种各样的,具体取决于要比较哪些方面的内容、基准测试的方法和相关性以及分数的算法。但是,在选择前端框架时,还是要进行全盘考虑,包括质量和数量方面的指标。