Size-performance api-性能优化不可不知的实践（一）

写在前面的话

前面内容枯燥，可以直接跳转到api内容

performance 下有navigation timing和resource timing两个较大重叠的api，前者用于衡量html的性能，后者用于衡量资源。

web performance 很大程度依赖对于静态的的获取和解析，即便随着网络、客户端等基础设施的巨大提高，客户端渲染和服务端渲染分一杯羹，SAP和MPA分庭抗礼，静态资源依旧是网站性能最为重要的一部分。

本文从这个大背景入手，主要讨论如何更好的利用 performance api来评价网站的加载性能，特别说明的是，因为在笔者的知识体系中，格外将路由切换排除在外，所以这里的加载性能特指首屏加载，即不包含页面切换或者跳转的情况。

performance中有关size的内容

通过使用api传入不同的参数，我们能够获取不同的性能参数：

// Get Navigation Timing entries:
performance.getEntriesByType('navigation');

// Get Resource Timing entries:
performance.getEntriesByType('resource');

这也是传统监控系统用来获取性能数据的底层原理。最最常见的就是下图：

其中每个阶段，都有其影响因素，对于网站性能来说，传统的优化措施，也基本针对以上的阶段进行。

performance api中size 的知识点

其实performance api中的内容很多，今天先随机介绍一下有关size的内容出来：

有关size

对于资源（item）来说，通过api能获取到decodedBodySize、encodedBodySize、transferSize：

const {decodedBodySize,encodedBodySize,transferSize}=performance.getEntriesByType("resource")[item]

encodedbodySize

根据这个encodedbodySize，我们能够得到传输过程的字节大小，拿三星商城shop.samung.com.cn举个例子，其网站首页不同资源的encodedBodySize的均值分别为：

这里能看到不同资源类型在网络传输过程的资源大小，其中

• js在100k左右，
• css在50k以下下，
• image在25k左右
• document在0.5k左右，
• xhr在0.5k

这里我随机找了百度、字节、京东等20多个网站（数据量小，随机每个网站仅使用一个网站的一次数据），将常见的资源按进行展示：

这里我们能到其中

• font大约在60k，
• document在30-40k之间
• js在40k
• xhr在1k一下

上面的数据样本太少，太缺少web行业的最佳实践值出来了。

decodedbodySize

根据这个decodedbodySize，我们能够得到解析后的字节大小，随机把三星商城的首页的decodedbodySize获取，使用排行榜就能得到下图：

在这里能看到不同资源类型解析后的资源大小，其中

• js在400kb左右，
• css在200kb左右，
• font在100kb左右，
• image在27kb左右
• document在1kb左右
• xhr在1k左右

随机找了百度、字节、京东等20多个网站（数据量小，随机每个网站仅使用一个网站的一次数据），将常见的资源按进行展示：

这里我们能到其中

• document超过200kb，
• js超过150kb
• css超过5kb
• xhr低于2kb

不过上面的数据样本太少，太缺少web行业的最佳实践值出来了。

压缩比

仅依靠这两个参数，就能够得到一个文件的压缩比，我们现在把这十几个网站的压缩比展示一下：

这里看到：

• js css document xhr 压缩比低于0.3
• image 与js css document等不一样
• font未压缩

不过上面的数据样本太少，太缺少web行业的最佳实践值出来了。

transferSize

resource timing 中有个特殊的key叫做，transferSize。

这里细心的小伙伴可能发现了，就是上面的encodeBODYsize和decodedBodysize中有个关键的内容，也就是BODY，这里也就是transersize的不同了，mdn中对transferSize这样解释：

The transferSize read-only property represents the size (in octets) of the fetched resource. The size includes the response header fields plus the response payload body

理论上来说，排除携带的cookies等信息

$t\; r\; a\; n\; s\; f\; e\; r\; s\; i\; z\; e\; =\; e\; n\; c\; o\; d\; e\; d\; b\; o\; d\; y\; S\; i\; z\; e\; o\; r\; d\; e\; c\; o\; d\; e\; d\; b\; o\; d\; y\; s\; i\; z\; e\; （取决于是否压缩）\; transfersize\; =\; encodedbodySize\; or\; decodedbodysize（取决于是否压缩）$transfersize=encodedbodySizeordecodedbodysize（取决于是否压缩）

但这里不是特意把他列出来的目的，真正的情况在于它的特殊用法：

If the resource is fetched from a local cache, or if it is a cross-origin resource, this property returns zero.

因为即便是缓存的情况下，encodedbodysize和decodedbodysize依然和首次下载一样，所以transfer就派上用场了，上面英文的意思：

如果资源来自本地缓存，或者是跨域资源，则该值为0；

所以我们可以利用这个字段来判断是否命中缓存。

理论上可以，然而实际，总有很多aha的moment

通过对十几个网站进行查看，发现在多次取自disk cache或者memeory cache的场景中，transfer的size明显不为0；

真让人不禁的感叹api真是个牛逼的东西，saying is always deceiving。

鉴于今天掘金书写时总是bug，所以今天文章先写到这里，希望这篇技术文对小伙伴有启发，有关缓存的场景我将在下一篇内容聊一聊。