话说，我在面试的时候，80%的情况下，都会被问到首屏优化问题，烦，恨~
所以，看到这里的前端佬就有福了，如题，藏着个小小的知识点，大家如果遇到同样情况，说不定有作用哦！
TCP Slow Start（慢启动）概念
咱先不说标题的数字哪里来的，先说一个概念，就是TCP的慢启动。
你们想哈，在浏览器和服务器开始建立连接的时候，服务器是并不知道浏览端网络的带宽、拥塞状况。假设你本地的带宽是1M，如果一开始服务器就发送2M的文件，那浏览器压根就不是人类，忍忍或者挤挤就能接收到的，这样就可能会引发丢包和重传。
想想，这个该有什么办法解决这个问题呢？
不管大佬咋样解决问题，TCP的解决方案就是慢启动 。大概概念就是小步试错,翻倍迭代 。比如第一轮次发送1捆（MSS），连续的 ACK 正常回来，第二轮会原有基础上x2，如下表：
| RTT 次数 | CWND 值 | 可发数据总量 |
|---|---|---|
| 第1轮 | 1 | 1 捆 |
| 第2轮 | 2 | 2 捆 |
| 第3轮 | 4 | 4 捆 |
| 第4轮 | 8 | 8 捆 |
| 第5轮 | 16 | 16 捆 |
如果遇到丢包（比如 3 个重复 ACK 或超时），那么发送的会在现有的CWND/2，。
14KB的由来
好了，有了上面的概念。现在就说说这个数值是怎么来的。
众所周知，web中的HTTP(s)的传输，就是基于TCP的。那就是一样的尿性了。
TCP 包最大约 1500 B，去掉 IP/TCP 等header信息后，实际载荷大约在1460 B。然后目前所有主流服务器配置，试探性的1捆 = 10个TCP包。总体大概就是在14 KB。数字就是这么来的。
假设总体资源就在14KB内，基本就第一波能发完，直接渲染。
14KB够用吗？
我知道看到这里的前端佬会想。"扯啥玩意啊，这14KB够用吗？"
是的，是的，但这个没有办法，整个互联网就是这个机制，想要快，对不起，就得按照这个规矩来。
但，前端佬别忘了一个东西，叫做GZIP。
我们这里的14KB是传送时的数据大小，有了这个GZIP压缩，理论上是可以把原有的文件缩小3到10倍，按照最低的算，那么源文件应该在42KB之上。
嗯，富余了一些。
当然，也可以在服务器中，将慢启动初次的包提高一些，比如30包，那样就能更多初始资源了~
需要注意，这里提到的14KB就是一个标准值，在实际应用中，一定要贴合自己项目里的情况！！！
我就不要14KB，咋的？
会咋的？ 下面是多一个延迟的数据，你看会延迟多少ms。
| 网络类型 | 单个 RTT（往返） | 多一轮的延迟成本 |
|---|---|---|
| 光纤宽带 | 10~50ms | +10~50ms |
| 蜂窝/4G | 50~150ms | +50~150ms |
| 卫星网络（星链） | 600ms+ | +600ms |
老掉牙的标准，在新技术中是怎么样的呢？
老归老，但是升级的协议中，一个突破都没有。
以现有新技术的HTTP2/3，或者QUIC，都逃不过这套方案。
一些小的建议
下面这些建议，眼熟吧？嘿嘿，我Q来的。凑合看了。
- 首屏 HTML（含内联 CSS/JS）尽量压缩后小于 14kB
- 使用 Brotli 压缩
- 延迟非关键资源（如 JS chunk、字体、动画）
- 服务端渲染时采用 SSR + HTML skeleton（骨架屏）
- 删框架：Bootstrap/React 这些，1 个就超预算，尽量原生/轻量库。
- 图片占位替代：先加载一个 tiny placeholder，再懒加载大图。
好了，就是这些。下次再聊了，各位~
