HTTP设计。为什么服务器在收到GET请求后不立即发送所有文件？

Question

据我了解，典型的导航方式如下：

1. 浏览器向服务器发送请求
2. 服务器发回HTML文件
3. 浏览器解析HTML文件并找出需要的文件
4. 浏览器针对每个JS / CSS文件发送一个单独的请求
5. 服务器将JS / CSS文件发送回浏览器
6. 最后，浏览器具有显示网站的所有内容

步骤3和4是否真的必要？ 为什么我们没有站点所需的所有文件的服务器端列表？ 这样服务器可以发送所有文件，而无需等待浏览器。

这是我尽力解释这种设计的尝试：

说明1：HTML文件在早期阶段更为重要，因为浏览器首先会构建DOM树。

Okey。但是，我们可以为站点所需的所有文件提供优先服务器端列表。通过这种方式，浏览器可以构建DOM树并同时下载CSS。

说明2：搜索引擎除了HTML之外不想下载其他任何内容。

是的。但是我们可以为此添加立即获取所有文件 HTTP标头。

说明3：这是旧版内容。我们不想破坏旧站点。

是的，我们没有。但是立即获取所有文件标头也可以解决该问题。

说明4：此开销可以忽略不计。

是吗？ 让我们来看一下facebook.com的 Dev Tools-> Network ：：

第3步和第4步在A点和B点之间进行。这似乎是TTFP的很大一部分。我错了吗？

我很困惑，因为找不到这样的设计的单一理由。我想念什么？

Answer 1

浏览器需要HTML格式的文件列表。

如果服务器知道浏览器将来会通过HTTP / 2推送请求，则可以抢先从服务器向浏览器发送内容。

这确实可以减少总延迟。但这也带来了挑战。例如，服务器如何知道客户端还没有该文件？客户端通常会缓存CSS和图像之类的资产，因此，如果客户端再次访问服务器，则再次推送这些资产可能会很浪费。

现实是，对于大多数人来说，第一次获取HTML并不足以解决这个问题。