14KB！前端首屏优化的生死界限💀💀💀

话说，我在面试的时候，80%的情况下，都会被问到首屏优化问题，烦，恨~

所以，看到这里的前端佬就有福了，如题，藏着个小小的知识点，大家如果遇到同样情况，说不定有作用哦！

TCP Slow Start（慢启动）概念

咱先不说标题的数字哪里来的，先说一个概念，就是TCP的慢启动。

你们想哈，在浏览器和服务器开始建立连接的时候，服务器是并不知道浏览端网络的带宽、拥塞状况。假设你本地的带宽是1M，如果一开始服务器就发送2M的文件，那浏览器压根就不是人类，忍忍或者挤挤就能接收到的，这样就可能会引发丢包和重传。

想想，这个该有什么办法解决这个问题呢？

不管大佬咋样解决问题，TCP的解决方案就是慢启动 。大概概念就是小步试错,翻倍迭代 。比如第一轮次发送1捆（MSS），连续的 ACK 正常回来，第二轮会原有基础上x2，如下表：

如果遇到丢包（比如 3 个重复 ACK 或超时），那么发送的会在现有的CWND/2，。

好了，有了上面的概念。现在就说说这个数值是怎么来的。

众所周知，web中的HTTP(s)的传输，就是基于TCP的。那就是一样的尿性了。

TCP 包最大约 1500 B，去掉 IP/TCP 等header信息后，实际载荷大约在1460 B。然后目前所有主流服务器配置，试探性的1捆 = 10个TCP包。总体大概就是在14 KB。数字就是这么来的。

假设总体资源就在14KB内，基本就第一波能发完，直接渲染。

我知道看到这里的前端佬会想。"扯啥玩意啊，这14KB够用吗？"

是的，是的，但这个没有办法，整个互联网就是这个机制，想要快，对不起，就得按照这个规矩来。

但，前端佬别忘了一个东西，叫做GZIP。

我们这里的14KB是传送时的数据大小，有了这个GZIP压缩，理论上是可以把原有的文件缩小3到10倍，按照最低的算，那么源文件应该在42KB之上。

嗯，富余了一些。

当然，也可以在服务器中，将慢启动初次的包提高一些，比如30包，那样就能更多初始资源了~

需要注意，这里提到的14KB就是一个标准值，在实际应用中，一定要贴合自己项目里的情况！！！

会咋的？下面是多一个延迟的数据，你看会延迟多少ms。

老归老，但是升级的协议中，一个突破都没有。

以现有新技术的HTTP2/3，或者QUIC，都逃不过这套方案。

下面这些建议，眼熟吧？嘿嘿，我Q来的。凑合看了。

好了，就是这些。下次再聊了，各位~