为什么您的网站大小应小于 14kb

网站规模较小，加载速度更快——这并不奇怪。

令人惊讶的是，页面的加载速度比页面14kB快得多15kB——可能更快——而和页面612ms之间的差异却微不足道。15kB16kB

这是因为TCP 慢启动算法。本文将介绍慢启动算法的含义、工作原理以及您应该关注它的原因。首先，我们将快速回顾一些基础知识。

什么是 TCP？

传输控制协议 (TCP)是一种使用互联网协议 (IP)可靠地发送数据包的方式— 有时也称为TCP/IP。

当浏览器请求您的网站（或图像或样式表）时，它会使用HTTP发出该请求。

HTTP 建立在 TCP 之上，单个 HTTP 请求通常由许多 TCP数据包组成。

IP 本身只是一个将数据包从互联网上的一个位置发送到另一个位置的系统。IP 无法检查数据包是否已成功到达目的地。

对于网站来说，确认所有数据已到达至关重要——否则我们可能会丢失网页中的部分内容。但对于其他网络应用来说，这一点并不那么重要——比如流媒体直播视频。

TCP 是 IP 的扩展，它允许浏览器和您网站的服务器相互告知哪些数据包已成功到达。

服务器发送一些数据包，然后等待浏览器的响应，表示它已经收到数据包（这称为确认或 ACK），然后它会发送更多数据包 - 或者如果它没有收到 ACK，它可以再次发送数据包。

什么是TCP慢启动？

TCP 慢启动是服务器用来查明一次可以发送多少个数据包的一种算法。

当浏览器首次连接到您的服务器时，服务器无法知道它们之间的带宽量。

带宽是指单位时间内网络上传输的数据量。通常以比特/秒 ( b/s) 为单位。管道是一个常见的类比——带宽就是每秒从管道中流出的水量。

您的服务器不知道连接可以处理多少数据 - 因此它首先向您发送少量且安全的数据 - 通常是 10 个 TCP 数据包。

如果这些数据包成功到达您网站的访问者，他们的计算机就会发回一个确认（ACK），表明数据包已被接收。

然后，您的服务器会发回更多数据，但这次数据包的数量会增加一倍。

此过程不断重复，直到数据包丢失且服务器未收到 ACK。（此时服务器会继续发送数据包，但速度会变慢）。

这就是 TCP 慢启动的要点——在现实生活中，算法会有所不同，但本质上这就是它的工作原理。

那么14kB从何而来？

大多数 Web 服务器 TCP 慢启动算法都是通过发送 10 个 TCP 数据包来启动的。

TCP 数据包的最大尺寸为1500 bytes。

此最大值不是由 TCP 规范设置的，而是来自以太网标准

每个 TCP 数据包在其报头中使用40 个字节- IP 为 16 个字节， TCP 为另外24 个字节

这样每个 TCP 数据包就有1460 个字节10 x 1460 = 14600 bytes，或者大约 14kB！

因此，如果您可以将您的网站（或其中的关键部分）缩小到 14kB，您就可以为访问者节省大量时间（访问者和您的网站服务器之间往返所需的时间）。

一次往返的旅程会有多糟糕？

人们非常缺乏耐心——一次往返可能会出奇地漫长。具体时间取决于延迟……

延迟是指数据包从源头传输到目的地所需的时间。如果说带宽是每秒通过管道的水量，那么延迟就是一滴水进入管道并从另一端流出所需的时间。

这是一个有趣的例子，说明延迟有多么糟糕：

卫星互联网

卫星互联网由绕地球轨道运行的卫星提供。它被人口稀少地区的人们、石油钻井平台、游轮以及航空公司的机上WiFi所使用。

为了说明这个严重延迟的例子，让我们想象一下一群石油钻井兄弟把骰子忘在家里了，需要使用优秀的（低于 14kB）missingdice.com来玩龙与地下城。

首先，他们使用手机向网页发出请求……

手机将该请求发送到钻机的WiFi 路由器 - 该路由器将数据发送到钻机上的卫星天线- 假设这需要1ms。

然后，卫星天线必须将数据发送到地球上空轨道运行的卫星。

通常，这是利用位于地球表面以上地球静止轨道的卫星实现的35786km。光速为299792458 m/s，因此从地球向卫星发送信息需要120ms。然后，卫星将信息发送回地面站，地面站又需要120ms。

然后，地面站必须将请求发送到地球上的服务器200000000 m/s（光在光纤电缆中会减慢速度）。如果地面站和服务器之间的距离与纽约和伦敦之间的距离相同，则需要大约28ms——但如果更接近纽约和悉尼之间的距离，则需要80ms——我们称之为60ms（一个方便我们计算的数字）

然后服务器需要处理该请求，这可能需要一些时间，10ms然后服务器会将其再次发回。

回到地面站，进入太空，回到卫星天线，然后到 wifi 路由器，再回到我们的油工电话。

phone -> WiFi router -> satellite dish -> satellite -> ground station -> server -> ground station -> satellite -> satellite dish -> WiFi router -> phone

如果我们算一下那就是10 + ( 1 + 120 + 120 + 60 ) x 2 = 612ms。

每次往返都需要额外花费612ms—— 也许这看起来不需要等待很长时间，但您的网站很容易进行多次往返才能获取其第一个资源。

此外，HTTPS 还需要另外两次往返才能完成第一次往返 — — 这让我们达到了1836ms！

对于生活在陆地上的人们来说延迟怎么样？

卫星互联网可能看起来像是一个故意设的坏例子——我选择它是因为它说明了这一点并且很奇怪——但对于陆地人来说，延迟可能会因多种原因而变得更糟：

2G 移动网络的延迟通常300ms介于1000ms
3G 网络的延迟可能介于100ms和之间500ms
嘈杂的移动网络——比如在音乐节等异常拥挤的地方。
处理大量流量的服务器
坏东西

不稳定的连接也可能导致数据包丢失 - 从而需要再次往返才能获取丢失的数据包。

现在您了解了 14kB 规则，您可以做什么？

当然，你应该尽可能地缩小你的网站——你爱你的访客，你希望他们感到快乐。将每个页面的大小控制在 14kB 以下是一个不错的目标。

这 14kB 包含压缩后的数据，所以实际上可能相当于约 50kB 的未压缩数据，这已经很慷慨了。毕竟，阿波罗 11 号制导计算机的内存只有 72kB。

一旦您丢失了自动播放的视频、弹出窗口、cookie、cookie 同意横幅、社交网络按钮、跟踪脚本、javascript 和 css 框架以及所有其他没人喜欢的垃圾，您可能就到了那里。

但是，假设您已经尽力将所有内容放入 14kB，但仍然无法做到 - 14kB 规则仍然有用。

如果您确保发送给访问者的前 14kB 数据可用于呈现一些有用的内容- 例如一些关键的 CSS、JS 和解释如何使用您的应用程序的前几段文字。

注意 - 14kB 规则包括 **HTTP 标头* - 这些标头未压缩（即使在第一个响应中使用 HTTP/2）- 它还包括图像，因此仅加载折叠上方的内容并使其保持很小，或者使用占位符，以便您的访问者知道他们正在等待一些好东西。*

规则的一些注意事项

14kB 规则更像是一条经验法则，而不是计算的基本定律：

一些服务器已将 TCP 慢启动初始窗口增加到 30 个数据包，而不是 10 个
有时服务器知道它可以以更大的数据包开始，因为它使用 TLS 握手来建立可以使用的更大窗口。
服务器可以缓存路由可以管理的数据包数量，并在下次连接时发送更多数据包。
还有其他注意事项—— 这里有一篇更深入的文章，解释了为什么 14kB 规则并不总是适用

HTTP/2 和 14kB 规则

有一种观点认为，在使用 HTTP/2 时，14kB 规则不再适用。我已经阅读了所有能找到的关于这方面的资料，虽然不太枯燥——但我还没有看到任何证据表明使用 HTTP/2 的服务器已经停止使用从 10 个数据包开始的 TCP 慢启动。

HTTP/3 和 QUIC

与 HTTP/2 类似，有人认为 HTTP/3 和 QUIC 将取消 14kB 规则——但这并非事实。QUIC建议采用相同的 14kB 规则。

进一步阅读

本文的大部分内容来自以下资源：

文章来源：https://dev.to/shadowfaxrodeo/why-your-website-should-be-under-14kb-in-size-398n