不同脚本位置和 link 标签的浏览器呈现行为不同

Question

我正在尝试了解 HTML 在浏览器屏幕上呈现的确切时间。

我阅读了 this S.O. 答案并尝试了一些用例，我观察到一些不适合 link、
中共享的模型的内容 我似乎也找不到一个一致的观察模型。

适合所讨论案例的浏览器呈现顺序是什么？

---

案例A： Image-A

1. 当HTML解析器到达M1时，显示M1。
2. 然后解析器到达脚本标记，它等待 js 文件下载和解析。
3. 然后解析器到达M3，显示M3。

案例 A 与大多数答案中描述的顺序不一致。 哇！让我们继续。

案例 B: 图片-B

1. HTML 解析器到达 M1，M1 未显示为案例 A
2. HTML 解析器到达 link 标记，它等待 css 下载和解析。
3. 显示M1和M2，所以在渲染M1之前等待样式表下载。
4. 然后解析器到达脚本标记，它等待 js 文件下载和解析。
5. 然后解析器到达M3，显示M3。

所以 Case-B 显示它没有渲染 M1，它在渲染之前等待 CSS 下载。 所以可能渲染器在渲染之前需要知道CSS。

案例：C 图片 C

所以从案例 B 中，我们假设渲染器可能需要知道 CSS。
让我们看看案例 C：

1. HTML解析器到达M1，显示M1。 它不应该显示，因为正如我们在案例 B 中看到的那样，它应该等待 css 加载 。
2. 现在解析器到达脚本，它等待 js 下载和解析。
3. 显示M2、M3

---

编辑： 提出的解释上述行为的思维模型..（但需要 review/refinement）

1. Script 不是呈现器阻止标记
2. link 是渲染器阻塞标签
3. 考虑到 renderer 和 HTML parser 是两个线程。
4. HTML 解析器可以将内容发送到渲染器进行渲染。
5. HTML 解析器可以向渲染器发送块信号.. 以阻止渲染器渲染任何 html 至少没有被渲染过一次。
6. HTML 解析器可以向渲染器发送取消阻止信号.. 以取消阻止渲染器渲染任何未渲染过的 html。

利用上述模型，我们可以解释案例 B 和案例 C：
案例 B 解释：

1. HTML 解析器到达 M1，M1 被发送到渲染器。
2. HTML 解析器到达 Link 标记，解析器向渲染器发送阻塞信号。
3. 渲染器在渲染 M1 之前，它收到了一个阻塞信号，因此 M1 没有显示。
4. HTML解析器完成link标签解析（下载）并向渲染器发送解锁信号，在接收到解锁信号后渲染M1。
5. HTML 解析器到达 M2，M2 被发送到渲染器。
6. HTML解析器到达Script标签，由于script标签不是渲染器阻塞标签，渲染器可以自由渲染html。
7. HTML解析器完成脚本标签的解析（下载）。
8. HTML 解析器到达 M3，M3 被发送到渲染器。

同样我们可以晒运行CASE C，完全符合上面的模型

我的模型是正确的还是有问题？

Answer 1

你几乎是对的。 除了它更简单 - 渲染器是被动的并且不接收 "blocking signal"。 它不会呈现（更新显示以反映 dom 树）直到有人要求它。

1. 您的 HTML 无效 - 您不能将 <link rel=...> 放入正文。 (生活HTML4.2.4)

2. 如您所想，样式表是一种 render-blocking 资源 - 它会阻止呈现内容， 与将暂停并呈现已解析内容的脚本相反。

以下是我的解释：

案例 B：M1 - stylesheet - M2 - script - M3

1. 浏览器获取 HTML。 M1 进入 DOM 树。 M1还没有显示，renderer还没被要求工作
2. 样式表加载。 （实际上它阻止了 M1 渲染）
3. 样式表完成。 M1 仍然没有显示。 （还有两步）
4. M2 进入 DOM 树。 M1和M2还没有显示。
5. 脚本触发渲染，从而显示 M1 和 M2，然后加载。
6. 脚本完成。没有任何变化（就本例而言）。
7. M3进入DOM树，尚未显示。
8. 文档完成，页面渲染完成，显示M3。

These behaviours are intentional. Once upon a time, js was slow and scripts took long time to run, whereas stylesheets was (and still is) important for hiding elements by default. Time may have changed, but these behaviours are unlikely to change.

案例 C：M1 - script - M2 - link - M3

1. 浏览器获取 HTML。 M1 进入 DOM 树。 M1暂未显示
2. 脚本触发渲染，从而显示 M1，然后加载。
3. 脚本完成。没有任何变化。
4. M2 进入 DOM 树。还没有显示。
5. 加载样式表，实际上阻止了 M2。
6. 样式表完成。 M2还是没有显示。
7. M3进入DOM树，尚未显示。
8. 文档已完成，页面已呈现，M2 和 M3 已显示。

The actual display process, in term of threads, is very complicated, and in some sense greatly varies by browser. For example, DOM is not thread safe. Think about what that means.

To keep it simple, you can imagine browser processing as data and event flowing between the various modules. Here are some Firefox rendering subsystems: