前端首屏优化

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

#TCP Slow Start（慢启动）概念

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

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

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

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

如果遇到丢包（比如 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。

#老掉牙的标准，在新技术中是怎么样的呢？

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

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

#一些小的建议

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

• 首屏 HTML（含内联 CSS/JS）尽量压缩后小于 14kB
• 使用 Brotli 压缩
• 延迟非关键资源（如 JS chunk、字体、动画）
• 服务端渲染时采用 SSR + HTML skeleton（骨架屏）
• 删框架：Bootstrap/React 这些，1 个就超预算，尽量原生/轻量库。
• 图片占位替代：先加载一个 tiny placeholder，再懒加载大图。